What should i know about UDP programming?

Question

I don't mean how to connect to a socket. What should I know about UDP programming?

• Do I need to worry about bad data in my socket?
• I should assume if I send 200bytes I may get 120 and 60 bytes separately?
• Should I worry about another connection sending me bad data on the same port?
• If data doesnt arrive typically how long may I (typically) not see data for (250ms? 1 second? 1.75sec?)

What do I really need to know?

Answer 1

If there is a packet size limitation imposed by some router along the way, your UDP packets could be silently truncated to that size.

Answer 2

Your packet may not get there.

Your packet may get there twice or even more often.

Your packets may not be in order.

You have a size limitation on your packets imposed by the underlying network layers. The packet size may be quite small (possibly 576 bytes).

None of this says "don't use UDP". However you should be aware of all the above and think about what recovery options you may want to take.

Answer 3

UDP is a connectionless protocol. Sending data over UDP can get to the receiver, but can also get lost during transmission. UDP is ideal for things like broadcasting and streaming audio or video (i.e. a dropped packet is never a problem in those situations.) So if you need to ensure your data gets to the other side, stick with TCP.

UDP has less overhead than TCP and is therefore faster. (TCP needs to build a connection first and also checks data packets for data corruption which takes time.)

Fragmented UDP packets (i.e. packets bigger than about half a Kb) will probably be dropped by routers, so split your data into small chuncks before sending it over. (In some cases, the OS can take care of that.) Note that it is allways a packet that might make it, or not. Half packets aren't processed.

Latency over long distances can be quite big. If you want to do retransmission of data, I would go with something like 5 to 10 times the agerage latency time over the current connection. (You can measure the latency by sending and receiving a few packets.)

Hope this helps.

Answer 4

I won't follow suit with the other people who answered this, they all seem to push you toward TCP, and that's not for gaming at all, except maybe for login/chat info. Let's go in order:

Do I need to worry about bad data in my socket?

Yes. Even though UDP contains an extremely simple checksum for routers and such, it is not 100% efficient. You can add your own checksum device, but most of the time UDP is used when reliability is already not an issue, so data that doesn't conform should just be dropped.

I should assume if I send 200bytes I may get 120 and 60 bytes separately?

No, UDP is direct data write and read. However, if the data is too large, some routers will truncate and you lose part of the data permanently. Some have said roughly 576 bytes with header, I personally wouldn't use more than 256 bytes (nice round log2 number).

Should I worry about another connection sending me bad data on the same port?

UDP listens for any data from any computer on a port, so on this sense yes. Also note that UDP is a primitive and a raw format can be used to fake the sender, so you should use some sort of "key" in order for the listener to verify the sender against their IP.

If data doesnt arrive typically how long may I (typically) not see data for (250ms? 1 second? 1.75sec?)

Data sent on UDP is usually disposable, so if you don't receive data, then it can easily be ignored...however, sometimes you want "semi-reliable" but you don't want 'ordered reliable' like TCP uses, 1 second is a good estimate of a drop. You can number your packets on a rotation and write your own ACK communication. When a packet is received, it records the number and sends back a bitfield letting the sender know which packets it received. You can read this unfinished document for more information (although unfinished, it still yields valiable info):

http://gafferongames.com/networking-for-game-programmers/

Answer 5

In addition to don.neufeld's recommendation to use TCP.

For most applications TCP is easier to implement. If you need to maintain packet boundaries in a TCP stream, a good way is to transmit a two byte header before the data to delimit the messages. The header should contain the message length. At the receiving end just read two bytes and evaluate the value. Then just wait until you have received that many bytes. You then have a complete message and are ready to receive the next 2-byte header.

This gives you some of the benefit of UDP without the hassle of lost data, out-of-order packet arrival etc.

Answer 6

Fragmentation and reassembly happens at the IP level, so you need not worry about that (Wikipedia). (This means that you won't receive split or truncated packets).

UDP packets have a checksum for the data and the header, so receiving bogus data is unlikely, but possible. Lost or duplicate packets are also possible. You should check your data in any case anyway.

There's no congestion control, so you may wish to consider that, if you plan on clogging the tubes with a lot of UDP packets.