Upgrading and Repairing Networks

The User Datagram Protocol (UDP)

Although TCP uses an acknowledgment mechanism to ensure that data is actually delivered to another computer, the User Datagram Protocol (UDP) does not. Both use IP as a transport protocol, but UDP is a much simpler protocol that doesn't require the overhead that TCP does. If an application does not need the benefits that a TCP connection provides, UDP can be used. Because UDP does no session setup, and all UDP datagrams are independent entities on the network, it can be considered an unreliable, connectionless protocol.

An example of this is the Domain Name Service (DNS). Most implementations of DNS use UDP packets in order to efficiently exchange information with other computers. If a client doesn't receive a response back from a simple DNS request, it can try again, or simply use another DNS server if it is configured to do so.

Examining UDP Header Information

Compared to the TCP header, the UPD header is much smaller because it doesn't require fields for sequence or acknowledgment numbers. UDP also doesn't need the connection setup flags, window size fields, and other information required for a connection-oriented protocol. In Figure 24.9 you can see that UDP has only four fields.

Figure 24.9. The UPD protocol uses a smaller header.

Source Port (16 bits)	Destination Port (16 bits)
Length (16 bits)	Checksum (16 bits)

The following are the purposes of the UDP header fields:

• Source port This 16-bit field is used to identify the port being used by the application that is sending the data.

• Destination port This 16-bit field is used to identify the port to which the packet will be delivered on the receiving end of the connection.

• Length This 16-bit field is used to store the length of the entire UDP datagram, which includes both the header and data portions.

• Checksum This 16-bit field is used to ensure that the contents of the UDP datagram are not corrupted in transit.

Although the length field in the UDP header can store a value of up to 65,535, in actual practice the size of a datagram is usually limited to a much smaller value. For example, the application programming interface (API) of a particular operating system might use smaller fields to specify the length of a datagram.

The checksum field is calculated on the UDP header information and its data, along with pseudo header information, just as is done with TCP. Using this method, UDP can determine whether the IP layer has passed to it a datagram that was not intended for this computer. If the checksum calculated on the receiving end does not match the value stored in this field, the UDP datagram is discarded. Similar to IP, no message is sent back to the sender of the datagram if this happens. For a reliable connection an application should use TCP, not UDP.

Interaction Between UDP and ICMP

Whereas UDP has no built-in mechanisms for guaranteeing delivery of the information carried in its datagrams, the Internet Control Message Protocol (ICMP) is used to report conditions back to the sending computer. For example, if a UDP datagram is sent to a computer with a destination port that is not being used (that is, that service is not running on the destination computer), then the ICMP port unreachable message (subcode value 3 of the destination unreachable message) is returned to the sender.

ICMP messages also can be used with UDP to find out the maximum transmission unit (MTU) sizethat is, the largest size a datagram can be in order to be sent through the network without being fragmented. Remember that on a network that uses different routers, or perhaps on an internetwork that is made up of different types of equipment or network media, the maximum size of a frame can change from one device to another. To discover the maximum size of a datagram that can be sent through the network, another subcode of the ICMP unreachable message (subcode 4) can be used along with UDP.

To create a utility that can be used to discover the MTU of a network connection, the IP Don't Fragment field can be set in the IP header information. When the UDP datagram reaches a router or other device that can't forward the datagram without fragmenting it, it will return the ICMP unreachable message "fragmentation needed, don't fragment bit set."

Finally, in some implementations a router or host will return the ICMP "source quench" error if a system is sending UDP datagrams at a rate that is too fast for the system receiving them. In this case, the application using UDP should be coded to take this into account, because the datagrams will be discarded by the system that generates the "source quench" ICMP messages.