Using Udp as network connection service

Coordinator
Jun 8, 2008 at 11:02 AM
Edited Jun 9, 2008 at 11:31 AM
We're about to decide which network service to use, UDP or TCP. As anybody knows, UDP does  not provide a reliable service but it is fast and as far as I know, it is more suitable for real time applications which do not require much reliability as TCP offers.

We think about serializing the game  objects like ClientInfo, Tank, Bullet, which hold information about connecting clients(nickname, id, etc) and the real time game information, when sending those objects between client and server. The serialization process goes like this: First serialize the object to MemoryStream then write the length of serialized data bytes as 4 bytes integer to the socket, at the end write the serialized object bytes to the socket.

Her comes the question: Since UDP is not reliable and may f.ck up when ordering the bytes or even lose or duplicate the bytes at receiver site, how are gonna we be sure that we are correctly deserializing the objects. What are gonna we do when we lost the syncronization.

We are open to any ideas, Thank You
Jun 9, 2008 at 12:27 PM
a cut from wikipedia's "Quake3" article:

Quake 3 uses a "snapshot" system to relay information about game "frames" to the client over UDP. The server updates object interaction at a fixed rate independent of the rate clients update the server with their actions, and then attempts to send the state of all objects at that point in time (the current frame) to each client. The server attempts to omit as much information as possible about each frame, relaying only differences from the last frame the client confirmed as received. Almost all data packets are compressed using Huffman coding using static pre-calculated frequency data, to reduce bandwidth even further.

in my humble opinion, quake 3 done best method for udp messaging in games. it's balanced. but you can move the load to server instead of client.

alternative methodology for snapshot system:
  • server prepares serialiazed data, and enumerates it with a snapshot id.
  • server sends data to client through udp.
  • server waits a reply from client, after 5 seconds timeout server sends another data.
  • [if server doesn't receive another packet]: while server preparing a new data, it includes previous one like source-control systems' "merge" method.
  • when client receives data, sends back snapshot id to inform server. if client receives multiple data causing network problems or delays,
    it applies latest one. snapshot id should prevent data losses of udp.