59

User Datagram
Protocol—UDP
Aleksander
Malinowski 59.1 Introduction..................................................................................... 59-1
Bradley University 59.2 Protocol Operation.......................................................................... 59-1
UDP Datagram • Port Number Assignments • Connectionless
Bogdan M. Service—Flow and Error Control
Wilamowski 59.3 Programming Samples...................................................................59-8
Auburn University References................................................................................................... 59-10

59.1 Introduction
User datagram protocol (UDP) is a part of TCP/IP suite [STD6,C02-1,F10,GW03,PD07]. It provides
full transport layer services to applications. It belongs to the transport layer in the TCP/IP suite model,
as shown in Figure 59.1. UDP provides a connection between two processes at both ends of transmis-
sion. This connection is provided with minimal overhead, without flow control or acknowledgment of
received data. The minimal error control is provided by ignoring (dropping) received packets that fail
the checksum test.
The UDP is standardized by Internet Society, which is an independent international not-for-profit
organization. A complete information about UDP-related standards is published by RFC Editor [RFC].
Several relevant RFC articles as well as further reading materials are listed at the end of this article.

59.2 Protocol Operation

Underlying IP provides data transport through the network between two hosts. UDP allows addressing
particular processes at each host so that incoming data is handled by a particular application. While
underlying IP provides logical addressing and is responsible for data transmission through networks
[STD5], UDP provides additional addressing that allows setting up connections for multiple applica-
tions and services on the same end. Addressing the processes is implemented by assigning a number
to each connection to the network, which is called a port number. Figure 59.2 illustrates the concept of
port numbers and shows the difference between IP and UDP addressing. UDP packets are also called
datagrams. Each datagram is characterized by four parameters—the IP address and the port number
at each end of the connection [STD6]. Certain class of destination IP addresses may not describe indi-
vidual computers but a group of processes on multiple hosts that are to receive the same datagram
[STD2,RFC3171]. Computers that need to receive multicast messages must “join” the multicast group
associated with a particular multicast IP address.
Although the term connection is used here, unlike in case of transmission control protocol (TCP),
there is no persistent connection between the two processes. The data exchange may follow certain

59-1

K10148_C059.indd 1 8/20/2010 6:08:56 PM

 59-2 Industrial Communication Systems

Application layer

SMTP FTP DNS SNMP BOOTP

Transport layer

TCP UDP

Network layer

IGMP ICMP IP ARP RARP

Data link layer

Underlying LAN or WAN technology

Physical layer

FIGURE 59.1 UDP and TCP/IP in the TCP/IP suite model.

Processes Processes
(running application program) (running application program)

Internet

Domain of IP protocol
Domain of UDP protocol

FIGURE 59.2 Comparison of IP and UDP addressing.

pattern or protocol but there is no guarantee that all data reach the destination and that the order of
their receiving would be the same as the order they were sent. The client–server approach, which is
usually used to describe interaction between two processes, still can be used. The process that may be
identified as waiting for the data exchange is called the server. The process that may be identified as one
that initializes that exchange is called the client.

59.2.1 UDP Datagram

AQ1 UDP have a constant size 8 byte header prepended to the transmitted data, as shown in Figure 59.3
[STD6]. The meaning of each header field is described below:
• Source port address: This is a 16 bit field that contains a port number of the process that sends
options or data in this segment.
• Destination port address: This is a 16 bit field that contains a port number of the process that is
supposed to receive options or data carried by this segment.

K10148_C059.indd 2 8/20/2010 6:08:58 PM

 User Datagram Protocol—UDP 59-3

8 bytes

Header Data

Source port number Destination port number

16 bits 16 bits

Total length Checksum

16 bits 16 bits

FIGURE 59.3 User datagram format.

• Total length: This is a 16 bit field that contains the total length of the packet. Although the num-
ber could be in the range from 0 to 65,535, the minimum length is 8 bytes that correspond to the
packet with the header and no data. The maximum length is 65,507 because 20 bytes are used by
the IP header and 8 bytes by the UDP header. Thus, this information is redundant to the packet
length stored in the IP header. An extension to UDP that allows for transmission of larger data-
grams over IPv6 packets has been standardized [RFC2675] [RFC2147]. In such a case, the UDP
header specified total length is ignored.
• Checksum: This 16 bit field contains the checksum. The checksum is calculated by
• Initially filling it with 0’s.
• Adding a pseudoheader with information from IP, as illustrated in Figure 59.4.
• Treating the whole segment with the pseudoheader prepended as a stream of 16 bit
­numbers. If the number of bytes is odd, 0 is appended at the end.
• Adding all 16 bit numbers using 1’s complement binary arithmetic.
• Complementing the result. This complemented result is inserted into the checksum field.
• Checksum verification: The receiver calculates the new checksum for the received packet that
includes the original checksum, after adding the so-called pseudoheader (see Figure 59.4). If the
new checksum is nonzero, then the datagram is corrupt and is discarded.

32 bit source IP address

Pseudoheader

32 bit destination IP address

8 bit
All 0s 16 bit UDP total length
protocol

Source port address Destination port address

16 bits 16 bits
Header

UDP total length Checksum

16 bits 16 bits

Data
(padding must be added to make the data
a multiple of 16 bits)

FIGURE 59.4 Pseudoheader added to the UDP datagram.

K10148_C059.indd 3 8/20/2010 6:08:59 PM

 59-4 Industrial Communication Systems

In case of UDP, the use of checksum is optional. If it is not calculated then the field is filled with 0’s.
The receiver can determine whether checksum was calculated by inspecting the field. Even in case the
checksum is 0 the field does not contain 0 as the calculated checksum is complemented at the end of the
process and negative 0 (the field filled with 1’s) is stored.

59.2.2 Port Number Assignments

In order to provide platform for an independent process addressing on a host, each connection of the
process to the network is assigned a 16 bit number. There are three categories of port numbers: well-
known (0-1,023), registered (1,024-49,151), and ephemeral (49,152-6,553). Well-known ports have been
historically assigned to common services. Table 59.1 shows well-known ports commonly used by UDP.
Some operating systems require that the process that utilizes these ports must have administrative priv-
ileges. This requirement was historically created to avoid hackers running server imposters on multiuser
systems. Well-known ports are registered and controlled by Internet Assigned Numbers Authority
(IANA) [IANA] [STD2]. Registered ports are also registered by IANA to avoid possible conflicts among
different applications attempting to use the same port for listening to incoming connections. Ephemeral
ports are also called dynamic ports. These ports are used by outgoing connections that are typically
assigned to the first available port above 49,151. Some operating systems may not follow IANA rec-
AQ2 ommendations and treat the registered ports range as ephemeral. For example, BSD uses ports 1,024
through 4,999 as ephemeral ports, many Linux kernels use 32,768–61,000, Windows use 1,025–5,000,
while FreeBSD follows IANA port range.

59.2.3 Connectionless Service—Flow and Error Control

As it was already outlined, UDP provides connectionless communication. Each datagram is not related
to another datagrams coming earlier or later from the same source. The datagrams are not numbered.
There is no need for establishing or tearing down the connection. In the extreme case, just one datagram
might be sent in the process of data exchange between the two processes.
UDP does not provide any flow control. The receiving side may be overflowed with incoming data.
Unlike in TCP, which has a windowing mechanism, there is no way to control the sender. There is no

Table 59.1 Common Well-Known Ports Used with UDP

Port Protocol Description RFC/STD #
7 Echo Echoes a received datagram back to its sender STD20
9 Discard Discards any datagram that is received STD21
13 Daytime Returns the date and the time in ASCII string format STD25
19 Chargen Returns a string of characters of random length 0 to 512 characters STD22
37 Time Returns the current time in seconds since 1/1/1900 in a 32 bit format STD26
53 Nameserver Domain Name Service STD13
67 DHCP Dynamic Host Configuration Protocol Server RFC2131
68 DHCP Dynamic Host Configuration Protocol Client RFC2131
69 TFTP Trivial File Transfer STD33
111 RPC SUN Remote Procedure Call RFC5531
123 NTP Network Time Protocol STD12
161 SNMP Simple Network Management Protocol STD62
162 SNMP Simple Network Management Protocol (trap) STD62
213 IPX Internetwork Packet Exchange Network Layer Protocol over IP RFC1234
520 RIP Routing Information Protocol SDT56
546 DHCPv6 DHCPv6 client RFC3315
547 DHCPv6 DHCPv6 server RFC3315

K10148_C059.indd 4 8/20/2010 6:08:59 PM

 User Datagram Protocol—UDP 59-5

FIGURE 59.5 Sample C program that illustrates a UDP server.

K10148_C059.indd 5 8/20/2010 6:09:00 PM

 59-6 Industrial Communication Systems

FIGURE 59.6 Sample C program that illustrates a UDP client.

K10148_C059.indd 6 8/20/2010 6:09:01 PM

 User Datagram Protocol—UDP 59-7

FIGURE 59.7 Sample C program that illustrates a UDP server utilizing multicasting.
(continued)

K10148_C059.indd 7 8/20/2010 6:09:01 PM

 59-8 Industrial Communication Systems

FIGURE 59.7 (continued)

other error control than the checksum discussed above. The sender cannot be requested to resend any
datagram. However, an upper level protocol that utilizes UDP may implement some kind of control. In
that case, unlike in TCP, no data is repeated by resending the same datagram. Instead, the communicat-
ing process sends a request to send some information again. Trivial file transfer protocol (TFTP) is a
very good example of that situation [STD33]. Since it has its own higher level flow and error control, it
can use UDP as a transport layer protocol instead of TCP. Other examples of UDP utilization are simple
network management protocol (SNMP) [STD62] or any other protocol that requires only simple short
request-response communication.

59.3 Programming Samples

Figures 59.5 and 59.6 contain two C programs that demonstrate use of UDP for communication using
AQ3 client–server paradigm [C02-3]. Socket API is a de facto standard. Programs use conditional compila-
tion directives that include minor variations in the library headers needed for operation under Unix/
Linux and Windows. Function calls should be modified, if desired, to run under other operating sys-
tems or with proprietary operating systems for embedded devices. Minor modifications need to be per-
formed when utilizing underlying IPv6 API, as described in [RFC3493]. Figure 59.5 shows the server
program that waits for incoming datagram from the client program listed in Figure 59.6. Because UDP
is connectionless, the server is capable of servicing data from several clients almost simultaneously. In
case a distinction is needed among clients, this must be implemented in the code of the server program.
Programs show all steps necessary to set up, use, and tear down a UDP-based exchange of data.
Figures 59.7 and 59.8 contain another pair of C programs that demonstrate the use of UDP for com-
munication using multicasting. Several server programs listed in Figure 59.7 receive one message sent by
the client program listed in Figure 59.8. The server must subscribe to the multicast IP address, i.e. “join
the multicast group” in order to receive data. In case of a client that only sends multicast data this step
may be omitted.

K10148_C059.indd 8 8/20/2010 6:09:02 PM

 User Datagram Protocol—UDP 59-9

Internet socket is an end point of a bidirectional interprocess communication flow across an IP-based
computer network. Interface to the socket library is standardized only on Unix/Linux and Windows. Other
operating systems including various embedded systems may employ different functions to carry out the same
functionality. Programs of the same functionality implemented in other languages may combine several
steps into calling a single function. This is especially true for the socket initialization and connection set up.

FIGURE 59.8 Sample C program that illustrates a UDP client utilizing multicasting.
(continued)

K10148_C059.indd 9 8/20/2010 6:09:03 PM

 59-10 Industrial Communication Systems

FIGURE 59.8 (continued)

References
[C02–1] D. Comer, Internetworking with TCP/IP Vol. 1: Principles, Protocols, and Architecture, 5th edn.,
Prentice Hall, Upper Saddle River, NJ, 2005.
[C02–3] D. Comer et al., Internetworking with TCP/IP, Vol. III: Client-Server Programming and
Applications, Linux/Posix Sockets Version, Prentice Hall, Upper Saddle River, NJ, 2000.
[F10] B.A. Forouzan, TCP/IP Protocol Suite, 4th edn., McGraw-Hill, New York, 2010.
[GW03] A. Leon-Garcia, I. Widjaja, Communication Networks, 2nd edn., McGraw-Hill, New York, 2003.
[IANA] Web Site for IANA - Internet Assigned Numbers Authority, http://www.iana.org/
[PD07] L.L. Peterson, B.S. Davie, Computer Networks: A System Approach, 4th edn., Morgan Kaufmann
Publishers, San Francisco, CA, 2007.
[RFC] Web Site for RFC Editor, http://www.rfc-editor.org/
[RFC2147] D. Borman et al., TCP and UDP over IPv6 Jumbograms, May 1997. http://www.rfc-editor.org/
[RFC2675] D. Borman et al., IPv6 Jumbograms, August 1999. http://www.rfc-editor.org/
[RFC3171] Z. Albana, K. Almeroth, D. Meyer, M. Schipper, IANA Guidelines for IPv4 Multicast Address
Assignments, August 2001. http://www.rfc-editor.org/
[RFC3493] R. Gilligan et al., Basic Socket Interface Extensions for IPv6, February 2003. http://www.rfc-
editor.org/
[STD2] J. Reynolds, J. Postel, Assigned Numbers, October 1994. http://www.rfc-editor.org/
[STD5] J. Postel, Internet Protocol, September 1981. http://www.rfc-editor.org/
[STD6] RFC0768/STD0006, J. Postel, User Datagram Protocol, August 1980. http://www.rfc-editor.org/
[STD33] K. Sollins, The Tftp Protocol (Revision 2), July 1992. http://www.rfc-editor.org/
[STD62] D. Harrington, R. Presuhn, B. Wijnen, An Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks, December 2002. http://www.rfc-editor.org/

K10148_C059.indd 10 8/20/2010 6:09:03 PM

K10148_C059.indd 11 8/20/2010 6:09:03 PM