UDP - User Datagram Protocol

See Sockets API for details on using UDP sockets.

Connectionless, unreliable, datagram service. Note that unreliable does not refer to the presence of undetected errors (data integrity is guaranteed, but delivery and sequence is not). A very thin veneer on top of IP. Lower overhead both for header and for time (no connection set-up).

UDP is a good match to applications that don't need reliability, for example SNMP, DNS. Or for those in which the environment is clean and small (LAN) so that errors are quite unlikely.

UDP packets may be corrupted in transit, lost due to congestion in a router, lost due to buffer overrun in the receiver's buffer. In all cases their is no indication given to the sending process. Packets just disappear.

Packet format

source port	destination port	length	checksum	data payload
16 bits	16 bits	16 bits	16 bits
ids the source process	ids the dest process	includes both header and data payload	covers entire packet; may be turned off	up to 64k - 8 bytes, in practice often smaller

Some notes:

Port numbers 0-255 are reserved for well-known-services (in Unix, see /etc/services)
UDP ports are independent of TCP ports. Some servers offer their services via both TCP and UDP, in which case either the same or different port numbers can be used.
The length field incudes the header and payload, so the min length is 8
The source port may be 0 (not used).

The UDP checksum is optional so that applications operating in a highly reliable environment can save the computational burden of calculating it. However, since IP doesn't protect the payload portion of an IP packet with a checksum, if you choose not to use the UDP checksum you have no way of detecting corrupted packets.

Pseudo header

The UDP datagram contains no information about destination address, just the port number. To insure that a received UDP datagram was indeed meant for the machine which received it, a psuedo-header can be constructed from the source and destination IP address found in the header of the IP packet which contained the UDP datagram.

The UDP checksum calculation is peformed (on both ends) for the datagram + the pseudo-header + some padding bytes. Thus checking the checksum also confirms that the datagram was delivered to the correct host.

Since the UDP checksum includes the IP source and destination addresses, these must both be known by UDP to calculate the checksum for the UDP datagram. The destination address is known by UDP, but the source address depends on the route chosen by the IP layer, so can't be known to UDP. How can the checksum be calculated without violating the purity of the layer model? It can't. UDP and IP are tightly integrated, so either UDP makes an IP packet and passes that, or IP tells UDP the source address to use for the checksum calculation.

Congestion control

There is no congestion control in UDP since there is no connection and the service is unreliable and hence no channel for feedback to be given to the
sender that it should slow down transmission.

When UDP was a small part of network traffic this was ok. But with the increasing popularity of video and audio over the net, more and more traffic is UDP based. This can be a problem for ISPs and backbone routers on the net, since congestion isn't handled by the sources of the data (the transport layer of the sender).