Like TCP, the User Datagram Protocol (UDP) is a protocol that runs on top of IP. Where TCP is designed to allow you to communicate using "streams" of data, UDP is designed to let you communicate using "datagrams."
As you may recall from the introduction at the start of this tutorial, all IP information is transmitted in "datagrams". So why is there a UDP? What is the difference between an "IP datagram" and a "UDP datagram"?
What's the difference? What's the difference? Not much.
If you really want to know (you were quite insistent, after all) here's the difference:
struct udphdr { /* UDP header */
u_short uh_sport; /* source port */
u_short uh_dport; /* destination port */
short uh_ulen; /* UDP length */
u_short uh_sum; /* UDP checksum */
};
That's it. Those 8 bytes are the only difference between UDP and IP datagrams. ("short" is 5I 0 in RPG, and "u_short" is 5U 0 in RPG... so these are all "short integers") When these 4 items are placed in the first 8 bytes of an IP datagram, it becomes a UDP datagram!
What these four integers provide is a "source port", "destination port", and some safeguards to ensure that the data is the same length and content on the receiving side as it was on the sending side.
These "source" and "destination" ports are really very significant. They allow different applications to call bind() and therefore these applications can be addressed individually. They're a method of differentiating between different applications on the same computer.
In other words, if these ports weren't specified, only one program on the system could work with them -- the operating system itself -- because there would be no way to differentiate each program's datagrams.
And this is why it's called the "User" datagram protocol. It allows "user" applications to send and receive datagrams, as opposed to system processes.
Unlike TCP, UDP does not ensure that data was received at the other end of the connection. When many datagrams are sent, UDP does not ensure that they are received in the same order that they were sent like TCP does.
So why would you ever use UDP?
Well, first of all, it's faster than TCP. The "safeguards" and "datagram sequencing" functions of TCP do add some overhead to the protocol. UDP does not have that overhead, and therefore UDP is a bit faster.
Secondly, you don't always WANT the data that gets "lost". An example of this might be a radio broadcast over the internet. If one datagram in the middle of a stream of audio data gets lost, it might be better to just skip the lost data -- much like receiving static on your traditional radio, rather than lose time in the broadcast. Real Audio is an application that uses this feature.
Third, you don't always need to send more than a single datagram of data. If the entire conversation consists of only a few bytes of data, there's no need to undergo the additional overhead of negotiating a TCP connection. Just send all the data in one datagram, and have the other side manually send back an acknowledgement.
So, although there are many advantages to using TCP, there are some situations where UDP makes more sense. Nearly all of the internet application protocols are run over TCP. But there are still several that use UDP. Some of the better known ones are:
Domain Name System ("DNS") (the protocol that translates names, such as 'www.myhost.com' to IP addresses)
Network Time Protocol ("NTP") (a protocol for synchronizing your system clock over a TCP/IP network)
Simple Network Management Protocol ("SNMP") (a protocol for managing your network devices)
Traceroute (a program used to see how packets are being routed across the internet)
By comparison to TCP, very few applications actually use UDP. However, it is still an important protcol that deserves a look in our tutorial!