TG:Networking

We'll keep networking design for the game in here.

Basics

 * Using TCP for cheap reliability and guarantee of ordered packets.
 * Need to twiddle the knobs to keep the timeouts short and the Nagle off.
 * UDP was considered, but dropped because of the need to build reliability and ordering on top of it anyway, and hey, there's this nice protocol that already provides them, isn't that nice?
 * Clients will run the game simulation in parallel with each other, and the server will be providing only packet forwarding and conflict resolution -- which leaves the question of map downloads for new clients open.
 * A thought on the matter would be to use a pseudo-P2P method wherein a newly connecting client checks if any of the other clients is behind a sufficiently open connection that it can download directly from them, or else uses the server as an intermediary for same. If two of the clients happen to be on the same LAN, the second connecting client could get a significant speed boost in these cases (with a correctly configured NAT).
 * For conflict resolution, one of the clients (determined by the server) will be a tie-breaker. More on this in a bit.
 * Sync detection: every few (TODO: how many?) game ticks, an extra random number is generated by all clients, unrelated to the other random numbers used for handling game events and normal map behaviour. Each client then sends the number to the server and the server will then compare.
 * Now back to conflict resolution: if there is a clear minority of clients who did not generate the same heartbeat number (see above), those clients are determined out of sync and the resync algorithm goes into effect (see below). If there is not a clear minority (e.g. a two-player game), the tie-breaker (see above) is considered authoritative.
 * This leaves open the question of what to do in a two-player game where the tie-breaker is a hacked client. May be a problem to be resolved as a social issue, i.e. "If you're gonna cheat, I'm not going to play with you".
 * Resync algorithm will pick an authoritative client and request its map checksums (see below). All out of sync clients will also provide their map checksums, and will then receive the map chunks for which they have wrong checksums. If a majority of checksums is wrong, the clients are kicked and asked to reconnect for full map download (though they probably have a different version of the game and bypassed version checking, so they shouldn't do that).
 * Map checksums: the map is divided into chunks (TODO: what size?), and each chunk keeps a checksum of all items in it (perhaps excluding moving trains?). See above for the use of these checksums in conflict resolution/resync. Ideally, this should reduce the required download for a resync to minimum without making the chunks too fine-grained.