i read quite often that UDP packets may not arrive in order or even not arrive at all. now i wonder, why this happens, how often it happens and what is it depending on? (packetloss) also, some network libraries (torque, raknet) provide "reliable" UDP. how exactly can they make sure that packets are delivered for sure? if this question is too technical, i would also be happy about links to good articles, that one with only little network experience can understand. :) thank you!

Quote:

Original post by ehmdjii i read quite often that UDP packets may not arrive in order or even not arrive at all. now i wonder, why this happens, how often it happens and what is it depending on? (packetloss)

If a router on the Internet starts getting overloaded, or a packet gets corrupted due to interference or anything, the packet will be dropped. TCP will resend the packet if it hasn't been acknowledged in a certain time, and will keep trying to resend it. UDP won't - if the packet is dropped, it's gone.
As for how often it happens; no idea, sorry. Someone else will hopefult know.

Quote:

Original post by ehmdjii also, some network libraries (torque, raknet) provide "reliable" UDP. how exactly can they make sure that packets are delivered for sure?

They make a UDP wrapper a bit like TCP. Each UDP packet is acknowledged by the API just like TCP. If the packet isn't acknowledged within the timeout period, then the packet is resent by the API.
Basically, it's another layer built on top of UDP.

Reliable UDP is usually based on sending ACK's for received packets, and resending packets until they are ACK'd. There are various methods of identifying and sequencing packets (and sequencing is important or you can receive crossovers, where an ack is delayed or fails so the same packet is resent and received twice).

Sometimes this method is reversed, and packets are resent if a whole message fails - for example some packets are received for message ID 7. Non-ack (NACKs) (completion requests) are sent with a message ID 7 and list of non-received packets if the message isn't constructed within a certain time (all packets for it received).

Protocols like UDP or TCP typically rely on the IP protocol, and the IP protocol is unreliable. Differents IP packets ca take different routes between two computers, thus IP does not garantee packets will arrive in order, if they ever arrive. Packetlost will will occur, depending on network congestion.

Reliable protocols (you should search "TCP" in google) use different mechanisms to compensate for the unreliability of the IP protocol. typically, each packet is given a number, wich will be used to reorder the packets and see if packets where lost. The receiver can then tell the sender to send those lost packets again.

On the other and, UDP does not use such mechanisms, and is unreliable.

thank you all.

so basically this reliable UDP, works by waiting for an ACK (like in TCP) and if it is not received it is resent after some time, right?

Yeah. Because the information needed to make UDP reliable adds overhead to the packet size, and time to handling, especially if messages are required to be sequential, using TCP can sometimes be a better solution. However, UDP doesn't require a separate socket for each connection, you just need to track by destination IP and port. This is good if you're writing a game that needs to send data to a lot of clients, especially on Windows platforms.

As an example, I use TCP for internal communication in my cluster architecture (where there aren't that many connections, they're robust (LAN) and sequential messaging is important (for event synchronisation), and I use UDP for cluster-to-client communication. It's really a case of picking the protocol that fits the task in hand.

With UDP you have to remember that *you* are responsible for all data sent in the packet, so any reliability layer is something that you will have to build and make efficient for whatever task you need it for.

thank you!

one final question about the reliable UDP version.
if it extends UDP so that each message waits for an ACK, what about the situation where the ACK message itself gets lost? wouldnt that result in an infinite loop where the sender keeps sending his message over and over again until the ACK finally arrives?

For that type of situation, you might have to place in a timeout for clients as well, such as if they have not ACK'ed in a certain amount of time, simply disconnect them (because they might have just shut off their machine on you or the such)

you mean, that the client should believe he is disconnected if the ACK does not arrive for a certain time?

but what if the ACK message is just lost? the server believes he has sent it, but the client just never got it which would result in the client being disconnected, just because one little ACK message got lost?

thanks.

Quote:

Original post by ehmdjii thank you! one final question about the reliable UDP version. if it extends UDP so that each message waits for an ACK, what about the situation where the ACK message itself gets lost? wouldnt that result in an infinite loop where the sender keeps sending his message over and over again until the ACK finally arrives?

If no ack is received then the sender is in the same case as if the original packet was lost - eventually you time out and resend the packet. The receiver may receive the same packet again, but they just send the ack again. Eventually a complete, uninterupted, round trip is managed and you progress to the next packet.

This is all oversimplified though, TCP is more complicated than it first seems - including piggybacking acks onto existing packets and using sliding windows to ack whole groups at a time. This is one of the reasons that most peoples 'reliable UDP' suck - they do a naive implementation which ends up worse than just using TCP.

Typically you'd only disconnect someone after you've received no communication at all for a relatively large amount of time - usually 30 or 60 seconds (which could translate into hundreds of lost packets without a single one getting through).