How TTD multiplayer works: Common in both versions: The game sends data in packets. A packet generated by DoAction is 52 bytes long. Every sent packet generates an acknowledgement(ACK) packet on the other side. IPX games(DOS version) and Windows version: The Windows version uses the DirectPlay Send and Receive methods to communicate. It sends packets guaranteed, meaning that DirectPlay guarantees that the other machine sees the packet uncorrupted (for example, it uses TCP instead of IP). The DOS version uses an IPX driver, which doesn't contain such error checking, so TTD "encrypts" packets and generates a checksum for them to avoid corrupt packets. Every packet gets a two byte header before sending. The first byte is the packet type, the second is the packet number. The packet number is kept in synch between the two machines, meaning it's increased at every send and receive. There are four packet types: 1,2 - On connection, the host broadcasts empty type 1 packets until it gets a type 2 packet from a client (DOS only) 3 - normal data packet (the header is followed by 52 bytes of data) 4 - ACK packet (indicating that the data packet with the given number is received successfuly). This packet has no data part, just the header. The sending function first sends a normal data packet, then listens continually for incoming packets for up to a second, ignoring every incoming packet that isn't the ACK of the sent packet. If no ACK arrives for a second, it sends an ACK of the previous packet, then tries again from the beginning. The function doesn't return until the success is sure, meaning a hang if the other side died for some reason. The receive function starts with listening to incoming packets for up to a second, ignoring everything that isn't the data packet with the number it wants. If no such packet arrives for a second, it sends an acknowledge of the previous packet, then tries again from the beginning, just like the send function. When the correct packet arrives, the function sends an ACK packet before returning. This function doesn't return unsuccessfully, either. Serial port games (DOS version only): Incoming data is put in a buffer by the interrupt that handles COM ports, and can be read later on. Outgoing data isn't buffered. There are two packet number counters, one for incoming and one for outgoing packets. The send function starts with removing anything waiting to be received. After this, the first byte it sends is the size of the packet (this is usually 52, but can be 1 to indicate end of packets), then it sends the packet itself, and finally a checksum byte. It waits for a while after this, listening to incoming data. If it gets a zero byte, it assumes an ACK and exits. If it gets anything else, it assumes a negative acknowledge(NAK) and starts from the beginning. However, if it doesn't get anything until the time-out interval elapses, it returns without indicating the error in any way. The receive function first reads a byte from the port, assuming it'll be the packet size. Any packet size except 52 and 1 results in sending a NAK byte (-1) immediately. If the size is correct, it receives the packet (sending a NAK if the full packet doesn't arrive for a while), calculates a checksum, then compares the received and the local checksum, and sends a NAK byte if the two differ. If the incoming data is longer than it should be (extra data after the checksum), it sends a NAK as well. If the data was received successfully, it sends an ACK (0) byte. However, it doesn't give up until this, meaning it'll wait forever if the other side died.