Technical Beef -

Every now and then I stumble upon a framework or a program using this poor old UDP protocol, and I kind of feel the need to make a parody of a famous YouTube video, except that I'm not enough of a drama king to make a good film, so I can just chew my beef on this blog: Leave UDP Alone! Don't use it. UDP was a handy protocol to have, back in times when we were bashing some C code with our bare hands or building some cheesy ad hoc network protocol for our petty university projects, but it's not worth it anymore.

Let's recapitulate what's good and wrong, but mostly wrong, with UDP.

- It's a packet-oriented. Actually, there's more constraints than benefits in using a packet-oriented protocol: the size of the data is limited, and large data needs to be fragmented at the application level (but keep in mind that the packet itself is fragmented by the lower network layers anyway if it reaches the MTU). In other words, if you want to transmit data over the (65Kb) size barrier, you need to implement your own fragmenting protocol over UDP. You can also do something similar to the DNS protocol: send all your data below 65-Kb in a UDP packet, and switch to TCP when it's above. Right, there's nothing like developing and maintaining the same protocol twice, so it's always something to consider... NOT.

NOTE: let me clarify what I just said here in a provocative manner: there are really good reasons why the DNS is designed like that, and I would have done probably the same choices (I hope so). The interesting fact is that once it was clear that the data had to be sent over multiple packets, the DNS people did NOT decide to hack the protocol and implement fragmentation (and integrity control, and so on) over UDP, they just made the switch to TCP when UDP was not suited. That was a smart move (this is said shamelessly with the comfort of my 20/20 hindsight). However, cases such like this one are rare, and chances are you're safe to assume that your own protocol is NOT similar to DNS.

- It's fast. But it's fast, because it's lossy. Keep in mind that both UDP and TCP run with the same engine: IP. The only difference is that UDP sends single packets, while TCP sends several related packets of data, but also manages their flow, packs them for the destination application in the correct order (which may be rather different from the order of arrival), and checks the integrity of the data. All the things that you would have done, sooner or later, at the application level when using UDP. The speed penalty for TCP mainly comes from the connection stage: by the time that TCP has done its protocol handshake, UDP would have sent and received several packets of useful data. However, most applications do send more than a one-packet-size payload, and once the connection is established, the speed penalty becomes irrelevant (specially when considering the benefits of the communication reliability).

- It's simple. Yes, it is. But it's not simpler than TCP, so we can just drop this argument where it stands: nowhere.

Once you've established that the networking communication between your servers has to be RELIABLE and/or VERSATILE (in size, at least in its evolution), you've also established that you need TCP. Not UDP. Because if you stick on UDP, you'll have to rewrite a TCP layer just to implement reliability and packet fragmentation anyway.

So, when is it relevant to use UDP ? Use your instinct, but there are a few acceptable patterns:
- Your protocol works correctly even with occasional losses of packets, and won't need the emitter to re-send lost packets.
- The data you send is inherently fragmented, or is easily fragmented in smaller pieces
- You really really need multicast, because you have an important number of clients. A handful of servers talking to each other is definitely not an important number, and the drawback of not having reliability is a severe dead-end, and is not to be taken lightly. So be wise, stick to your real needs.

If your requirements fits all (or most of) those statements, UDP may be a good choice, as it will give a real speed boost (over TCP). Otherwise, please just don't. Not in 2008.