0

I am learning udp in the next few days. This weekend I am going to be in one of those 72hour competition and I would like to have my UDP code work online by the end of it. During the competition I wont have any internet (so no calling someone and having them test).

I know of some of the problems about UDP like packets coming in twice, not coming in for several frames (but I don't know how long in milliseconds I should expect), the recommended byte size (576) etc. What should i know about UDP programming?

But what are some of the things that happen to you after moving from LAN to internet?

NOTE: I will be running some code ASAP and testing it online. Hopefully what my end code will look like but I may also miss a few things.

Community
  • 1
  • 1
  • 576 isn't recommended, it's the guaranteed minimum supported size by all IPv4 networks without fragmentation. IPv6 increases this to 1,500 bytes. – Steve-o May 15 '11 at 16:45

4 Answers4

0

Your delays may increase and you may get more packet loss. This is dependent on where the transmitter and receiver are. If you are in the US and you are trying to communicate with UDP with Australia, you're going to get pretty high latency you will suffer more packet loss/reordered packets/duplicates because there is more distance to travel and more paths for the packets to be routed.

CookieOfFortune
  • 13,836
  • 8
  • 42
  • 58
0

If you're using UDP as transport protocol, you have to secure your transmission inside your application protocol. There are several ways to do this:

  • Packet sequence numbers
  • Packet sizes
  • Checksums

You should send these as a header of your application packets and check them at the receiving end.

PS: If you really rely on correct packet order and completeness in all aspects of your protocol (not just parts of it) you should switch to TCP.

Koraktor
  • 41,357
  • 10
  • 69
  • 99
  • 1
    I would say that you *may* want to secure your transmission. For example, if you're receiving real-time price updates for indicative purposes, then it's likely that you can afford packet misses. – Brian Agnew Apr 28 '09 at 21:50
0

This may be a bit extreme (!) but if this is important, you could write a UDP proxy that listens for incoming datagrams and forwards them on. You could then modify this to provide:

  1. latency
  2. packet drop
  3. packet replication

and direct your client to send data to the proxy, and the proxy to direct on (with appropriate packet modifications) to the server.

Like I say, perhaps extreme. However, even in the presence of your LAN/internet, you would be able to use this to test your application for its behaviour in a UDP-unfriendly environment.

EDIT: Surely someone has written something like this ? If not, I sense an open-source project coming on....

Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
0

The short answer is: on a LAN, you will probably notice very few of the tradeoffs (good and bad) of UDP, because on a LAN few things can go wrong.

You could lose packets. LAN congestion or local system limitations are the most likely cause.

When you leave the LAN, and depend on routers, then the majority of UDP problems will appear (fragmentation, duplicate packets, delayed packets, discarding of packets beyond a certain size, lack of error messages being returned).

In other words, MOST of what makes UDP complicated is "leaving the LAN".

benc
  • 1,381
  • 5
  • 31
  • 39
  • what do you mean by fragmentation? i will get half my packet? will i get the 2nd half on a different read? –  Apr 29 '09 at 09:26