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?

With UDP, what you send is what you get; but you might get it out of order or not at all. At the layer we're working at, you won't be seeing any damaged packets. I think you can disable checksumming to allow damaged packets but luckily it's not disabled by default.

<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>

<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.

Wait? Why can’t I use both UDP and TCP?For realtime game data like player input and state, only the most recent data is relevant, but for other types of data, say perhaps a sequence of commands sent from one machine to another, reliability and ordering can be very important.

The temptation then is to use UDP for player input and state, and TCP for the reliable ordered data. If you’re sharp you’ve probably even worked out that you may have multiple “streams” of reliable ordered commands, maybe one about level loading, and another about AI. Perhaps you think to yourself, “Well, I’d really not want AI commands to stall out if a packet is lost containing a level loading command – they are completely unrelated!”. You are right, so you may be tempted to create one TCP socket for each stream of commands.

On the surface, this seems like a great idea. The problem is that since TCP and UDP are both built on top of IP, the underlying packets sent by each protocol will affect each other. Exactly how they affect each other is quite complicated and relates to how TCP performs reliability and flow control, but fundamentally you should remember that TCP tends to induce packet loss in UDP packets. For more information, read this paper on the subject.

But I totally agree that the current setup sounds broken: it sounds trivial for a hacker to send false packets and teleport, etc. wherever they want. Reading all the Gaffer's networking articles is probably your best bet.

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?

In C++, friends have access to your privates.
In ObjAsm, your members are exposed!

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.

Wisdom is knowing when to shut up, so try it.--Game Development http://nolimitsdesigns.com: Reliable UDP library, Threading library, Math Library, UI Library. Take a look, its all free.