Hi guys, someone can tell me how can I implement a simple system that makes me sure that an important packet arrive to the destination correctly? I thought something like this: I use an incremental flag inside may packets to make the server able to understand if the packet that arrives is correct or not. If the packet arrives correclty, the server informs the client, and the client stops sending the buffered packet, instead the client continues sending until it reaches a predefined tentatives number. In this way I should make the server able to understand if the right packet arrives and I make it able to reorder packets if they arrives not ordered. can it work or there are better ways to do it? some code will be apreciated ... bye

is TCP not an option?

Like the previous poster effectively suggested, just use TCP because it automatically does and guarantees everything you wanted.

TCP is too slow for my project: it uses too much band and too much resources.

Anyone can help me?

Reliability is the tradeoff with using UDP. If your game requires that much speed then you should put time into handling packet loss rather then preventing it.

[edit] You will eventually have to do sync messages, but do them sparingly (every few seconds).

also - Spending bandwidth to constantly send verification messages will remove your gain in speed with UDP right quick.

The problem with TCP is that, if you lose a packet, and then receive a bunch of other packets, you won't actually GET those packets until the lost packet can first be re-transmitted, which will take a while. This is why TCP is very jittery.

With UDP, each packet you receive, you will get. That's why it's better for real-time applications; it doesn't withhold data that's arrived at your interface.

If you want a shallow wrapper on top of UDP that can send packets reliably if necessary, I recommend looking at ENet.

Pilu,

I have just recently implemented a reliability layer for TCP and when I look back on it, it wasn't really all that difficult at all...it was just getting my head wrapped around it in the first place that was. I'll try to keep this short yet explain as much of what I did as possible.

First of all, in regards to the message buffers themselves, each client that joins my server has a stored reliable buffer (for retransmission until it's acked), a current reliable buffer (which is built up over frames until an ack is received for the previous message) and an unreliable buffer which will only be attached to the final message if there is space and this is not acked.

I also keep track of a number of sequence counters, though I'm sure this could be cut down quite a bit but it's still in it's early stages. I have an incoming sequence (to keep track of old/dup packets), incoming reliable sequence (this is the value that the client application holds locally and sends to the server, it will always be increased by one so I can easily keep track of it). Should the incoming reliable sequence be = to old incoming reliable + 1 I know this message contains a reliable buffer that I have to ack. I also keep track of an outgoing sequence for sequencing outgoing packets and an outgoing reliable for sending reliable messages to the client for which I'm expecting an ack.

Previous posters have mentioned that attaching acks etc. to outgoing packets and what not will burn the increase in speed you gain from UDP are correct if you simply send out an acknowledgement with nothing attached to the packet. I have embedded my acks etc within an update message or event such as weapon fire and simply use binary shift operators on them therefore only using 2 bytes max for a seq. and another 2 for an ack, a whole 4 bytes is not going to kill the speed increase you'll see....you just have to be smart about how you handle reliability.

Hope this has helped you out a little, I'll check back later if you have any more questions.

Permafried-

It sounds like the original poster wants only reliable and ordered packets; in which case I see no reason to use UDP.
UDP is great, i'm using my own reliability layered library, but it's only useful if you want some packets to be reliable but not ordered.

Would you consider using DirectPlay? It uses UDP under the hood, but has the ability to send sequential, gauranteed packets.

Granted DirectPlay code is dog-ugly if you're using C++, it could still probably save you some time over writing your own library. If on the other hand, you are using a .Net language, DPlay is really easy to setup and use. You might want to try it.

Of course if you care about being cross-platform, just ignore me.

I've got quite an elaborate scheme for ensuring packet reception. One of the techniques I use is sending redundant data on the top of newer packets.

So say I send packets 1, 2, and 3. 2 will also contain all the data from 1, 3 will also contain 2, etc.

There are various other techniques, and I believe there are sites out there that discuss UDP in-depth.

~phil