So my initial discoveries in using this:
1.) Packets are not sent in order
2.) Packets are also sent to yourself
3.) Packets are sent to everyone, even players you don't care about
4.) The max packet size seems to be ~ default MTU, which is ~1500 bytes, but probably a bit less to be safe. I use 1250 and it seems to work ok.
5.) You can't send thousands of packets per turn slice, the clients will drop. (Probably this blocks some internal EXE heartbeat packet not exposed to the DLL)
6.) The resync process takes 10000-50000 packets to send, naively.
So on the 5th point. I added a std::vector queue to the CvGame object and send 25 packets per turnslice. Sending more begins to make the UI visibly lag. This is on a local network game.
The receiving player stores the incoming packets in a stdext::hashmap, so that when they all arrive, they can be consumed in order. The hashmap key is the packet order number. The value is the packet.
On the 6th point, we can lower the number of packets dramatically, I think. First off, compression. That likely will cut the size in half. That's good, but still if we are sending 5000 packets, 25 packets per turn slice, and 1 turn slice per second (ish), that is 3 minutes to wait to resync a game. Not exactly fast.
The biggest component of the data is the map, and more specifically, the CvPlot objects in the map. I think a checksum system for each player, each team, the game, the map (without tiles), and the tiles, would make it possible to skip resending a large majority of the information. Possibly we could further subdivide the tiles into groups and checksum these groups to avoid resending all tile information as well. This should dramatically decrease the data needed to be sent.
To subdivide tiles into groups my initial thought was simply to use the modulus operator over the tile id. Each tile is given an index id, 0 - NumTiles, so if I used % 100 on that id, and examined the remainder, I would subdivide the tiles into 100 groups. My initial concern is that this naive approach places tiles that are far apart in the same group, possibly increasing the number of groups that will have inconsistent checksums, in a case where a game is out of sync in a relatively local area.