If you're interested in some technical discussion, let's talk about sharing images over TCP!

Right now there's a problem in Isocon, which is that sharing images between clients, especially large clients, gets dicey. The networking code uses TCP and is limited in how much data it can send in a single request. So for images, you can't simply send an entire 2MB png in a single request. What you can do is break it into 512 byte chunks and send those, one after the other. I didn't encounter any issues while testing this, even when simulating multiple connections, even with simulated latency. But in real world scenarios, it's entirely possible, nay inevitable that packet loss will occur, causing a piece to be missing, and the token-receiver client to flood the token-sender client with requests, which spikes the memory use of the token-sender, causing a disconnect, or the app to freeze, or even crash.

So I've been rebuilding this system, because if you can't share tokens, the VTT isn't very useful.

In the new version, a client who is missing a token will notify the host, who will pass a list of the missing chunks to the other clients. Any client who has the token will then send up to 10 random chunks to the host, who will then pass those chunks to all clients.

Why all clients? Because a very common real-world scenario is that one player will create a new token, which all other players, including the host, will then all need to sync at the same time. So consider: a player (A) connected as a client creates a token with 100 chunks (ie, a 5kb image), which needs to be shared with 2 other players (B and C), while a fourth player already has the image from a previous session with A. All players receive the token's meta information right away, including number of chunks and image height/width/etc.

1. BC notify the host which chunks they're missing (at the outset, 1-100)
2. Host tells ABCD to send up to 10 tokens
3. A sends chunks 3, 45, 82, and 77 to host
4. BC send nothing
5. D sends chunks 5, 65, 23, 90 to host
6. Host sends chunks 3, 45, 82, 77, 5, 65, 23, 90 to all clients
7. AD ignore the chunks, BC receive chunks
8. After a timed interval, the process repeats until all chunks are received

I only got this process working right before I stopped working last night, so it still needs some testing. For one, the likelihood of sending repeat data increases as the number of missing chunks decreases. It might be possible at step 2 to specify certain clients to send certain chunks, but the host doesn't know without making additional requests whether a client has the image. An additional persistent data layer could solve this, but it might introduce unwarranted complexity.

Testing happens tonight!