Hi.

Im creating a multiplayer FPS. The multiplayer allready works but it uses TCP/IP. I want to move to UDP but theres one thing i want to understand first. Firstly il briefly explain how my current simple protocal works. (Its most likely very naive. I dont realy have any experience with network programming).

the first 2 bytes in every message indicates the length of the message. the next byte indicates the message type and the rest of the bytes is the actual message. dead simple.
so for example if the client sends its position and direction to the server (wich is 5 32 bit floats. 3 for position and 2 for rotation) the integer value of the first 2 bytes together would be (2 + 1 + 5*4) = 23. the next byte (wich is the message type indicator) would be 2 (message type 2 means its a position and direction update from client to server) and the remaining 20 bytes would be the 5 floating point values.

Another example would be the server sending the position and direction of another client to a client. Its similar to the above example except that the message also includes a byte that contains a client ID. So the integer value of the first 2 bytes together would be (2 + 1 + 1 + 5*4) = 24. the next byte (wich is the message type indicator) would be 3 (message type 3 means its a position and direction update from server to client). the next byte would be the ID of client wich position and direction is being updated and the remaining 20 bytes would be the 5 floating point values.

The logic behind using UDP (as i understand it) is that if data (like the data in the above examples) gets lost its better to just wait for the next update than it is to resend the lost data since by the time its resent it will most likely be outdated but how do i know if a message got damaged by data lost? lets take my last example. its a message that consists of 24 bytes. Lets say one of those bytes goes missing. It will still read 24 bytes. Meaning that its going to read the first byte of the next next message...

How do you get around this? is there a way to find out if bytes goes missing so i can discard the whole message? Or should redesign my protocal?

Thnx in Advance!

<P>Thnx I didnt know UDP works like that. i thought it was also just one continious stream of data. Didnt know you got split into packets and each packet gets checksummed. <BR><BR>I have one more question then. using udp for updating position and rotation is fine but what about shooting? if one client shoots his gun and the packet containing that information gets lost that would be bad seeing as the "shoot" data would only be sent once. Should i use a TCP/IP connection alongside my UDP connection for data that may not get lost.</P>

so for example if the client sends its position and direction to the server ....
I have one more question then. using udp for updating position and rotation is fine but what about shooting? if one client shoots his gun and the packet containing that information gets lost that would be bad seeing as the "shoot" data would only be sent once.
Should i use a TCP/IP connection alongside my UDP connection for data that may not get lost.

You can use TCP alongside for must-be-reliable data, or you can use a reliable-UDP wrapper library for this data.

However, backing up for a moment, your design sounds very fragile for an FPS -- ideally shooting wouldn't need to be a reliable message at all, and the client should not be sending their position to the server (it should be the other way around). Some links on other designs below.

Quake3:
http://trac.bookofho...uake3Networking
Source:
http://developer.val...ayer_Networking
Unreal:
http://udn.epicgames...ngOverview.html
http://web.archive.o...com/Network.htm
Gaffer:
http://www.gafferong...worked-physics/

Thnx for the replies. I will read through those articles and improve my desighn. For the time being though (just to get the game up and running) I will use TCP alongside UDP for data that should be reliable data.

There is also reliable udp to look into ;)
There are some simple technical reasons why UDP is preferable to TCP, my argument would be based on the IP carrier's collision avoidance mechanism.
Imagine a network as a busy highway, and now imagine a TCP packet with its typical MTU window of around 1500 bytes, and a UDP packet with its typical MTU window of about 500 bytes, as being a greyhound bus, and a volkswagen beetle, the only two kinds of vehicles on the road.
Guess who has to wait longer to fit into a suitable gap in the traffic?

You cant really use TCP for reliable data in First Person Shooters. There are different types of data that are reliable which if sent over TCP would cause your game to be unplayable. Simply put, FPS must be over UDP, anything else will cause problems.

There is no reason to use TCP when there are simple alternatives, like ENet, which support both reliable and unreliable data sending over UDP.