Hosts that support IP must also support the Internet Control Message Protocol (ICMP) defined by RFC 792: Internet Control Message Protocol. ICMP is a basic protocol for sending messages. Some common uses for ICMP are to send a PING message to learn if a host is available on the network and to obtain the IP addresses of local routers. ICMP messages travel in IP datagrams. The Protocol field in the IP header is 1 to indicate ICMP. The first byte in the data portion of the datagram is an ICMP Type code that determines the format of the data that follows. RFC 792, RFC 950, and RFC 1256 define the type codes listed in Table 4-5 and have further details about the message formats.

Exchanging Messages Using UDP and TCP

This section explains how UDP and TCP help get data to its destination. Knowing more about how the protocols work can help in selecting which protocol to use and in using the protocol effectively. Also included is a review of options for obtaining code to support UDP, TCP, and IP in embedded systems. The Ethernet standard specifies a way to transfer information between computers in a local network. But Ethernet alone doesn’t provide some things that many data transfers require. These include naming the port, or process, that is sending the data, naming the port that will use the data at the destination, handshaking to inform the source whether the destination received the data, flow control to help data get to its destination quickly and reliably, and sequence numbering to ensure that the destination knows the correct order for messages that arrive in multiple segments. The transmission control protocol (TCP) can provide all of these. The user datagram protocol (UDP) is a simpler alternative for data transfers that only require specifying of ports or error checking. Table 5-1 compares UDP and TCP. Network article 5-2 shows the location of UDP and TCP in a network protocol stack. UDP and TCP communicate with the IP layer and the application layer. Some applications don’t require UDP or TCP, and may communicate directly with the IP layer or the Ethernet driver.

About Sockets and Ports

Every UDP and TCP communication is between two endpoints, or sockets. Each socket has a port number and an IP address. In an Ethernet frame, the Source Address and Destination Address fields identify the sending and receiving Ethernet interfaces. A UDP or TCP communication specifies the destination more precisely by naming a port at the destination. Each TCP communication also names a source port that identifies the provider of the data being sent. Each UDP communication has a source port, but UDP datagrams aren’t required to include the source-port number in the header. A socket’s port isn’t a hardware port like the ports that a CPU accesses using inp and out instructions. Instead, the port number identifies the process, or task, that is providing the data being sent or using the data being received. You can think of a socket as one end of a logical connection between computers. Unlike a physical connection, where dedicated wires and electronic components form a link, a logical connection exists only in software.

Data that travels between sockets that have a logical connection doesn’t have to take the same physical path every time. The Internet Assigned Numbers Authority (IANA) (www.iana.org) maintains a Port Numbers list that assigns port numbers to standard processes. There are three groups of port numbers. Values from 1 to 1023 are called well-known ports, or contact ports, and are for use by system processes or programs executed by privileged users. Table 5-2 shows examples of a few common processes and their well-known ports. Assigning a well-known port to a process makes it easy for a computer to know what port to use when it wants to communicate with a remote computer. For example, a computer requesting a Web page normally sends the request to port 80. The receiving computer assumes that messages arriving at port 80 will use the hypertext transfer protocol (HTTP) for requesting Web pages. Ports from 1024 to 49151 are Registered ports. An entity can request a port number from the IANA for a particular use, and the IANA maintains a list of ports it has registered. Some of the Registered ports are assigned to companies. For example, ports 5190 through 5193 are assigned to America Online. Other assignments are to processes, such as Building Automation and Control Networks (bacnet) on port 47808. Networks that don’t use the ports in this group for their registered purposes are free to use these ports for any purpose. Ports from 49152 through 65535 are dynamic and/or private ports. The IANA doesn’t assign processes to these. A network may use these ports for any purpose. In a communication between two hosts, the values of the source and destination ports don’t have to be the same and usually aren’t. The source typically selects any available local port and requests to communicate with a well-known port on the destination computer. On receiving the request, the destination computer may send a reply that suggests switching the communication from the well-known port to a private port at the destination. This keeps the well-known port available to receive other new communication requests. For communications that don’t use a well-known port, such as the examples in this networking tutorial, the computers must agree ahead of time on what ports to transmit and receive on.

UDP: Just the Basics

UDP is a basic protocol that adds only port addressing and optional error detecting to the message being sent. There is no protocol for handshaking to acknowledge received data or exchange other flow-control information. UDP is a connectionless protocol, which means that a computer can send a message using UDP without first establishing that the remote computer is on the network or that the specified destination port is available to communicate. For these reasons, UDP is also called an unreliable protocol, meaning that using UDP alone, the sender doesn’t know when or if the destination received a message. The document that defines UDP is RFC0768: User Datagram Protocol. It’s also approved standard STD0006. A computer that wants to send a message using UDP places the message in a UDP datagram, which consists of a UDP header followed by the data payload containing the message. As Chapter 1 explained, the sending computer places the UDP datagram in the data area of an IP datagram. In an Ethernet network, the IP datagram travels in the data field of an Ethernet frame.

On receiving the Ethernet frame, the destination computer’s network stack passes the data portion of the UDP datagram to the port, or process, specified in the datagram’s header. In most respects, UDP is less capable than TCP, so UDP is simpler to implement and thus more suitable for certain applications. If needed, a communication can define its own handshaking protocol for use with UDP. For example, after receiving a message, a receiving interface can send a reply containing an acknowledge code or other requested information. If the sender receives no reply in a reasonable amount of time, it can try again. But if an application needs anything more than the most basic handshaking or flow control, you should consider using TCP rather than re-inventing it for use with UDP. UDP has one capability not available to TCP, and that is the ability to send a message to multiple destinations at once, including broadcasting to all IP addresses in a local network and multicasting to a defined group of IP addresses. Broadcasting and multicasting aren’t practical with TCP because the source would need to handshake with all of the destinations.

The UDP Header and Data

The UDP header contains four fields, followed by the data being transmitted. Source Port Number. The source port number identifies the port, or process, on the computer that is sending the message. The source port number is optional. If the receiving process doesn’t need to know what process sent the datagram, this field can be zero. The field is two bytes Destination Port Number. The destination port number identifies the port, or process, that should receive the message at the destination. The field is two bytes. UDP Datagram Length. The UDP datagram length is the length of the entire datagram in bytes, including the header, with a maximum of 65535 bytes. The field is two bytes. UDP Checksum. The UDP checksum is an optional error-checking value calculated on the contents of UDP datagram and a pseudo header. The pseudo header contains the source and destination IP addresses and the protocol value from the header of the IP datagram that will contain the UDP datagram when it transmits on the network (Table 5-4). The pseudo header doesn’t transmit on the network. Including the information in the pseudo header in the checksum protects the destination from mistakenly accepting datagrams that have been misrouted. The checksum value is calculated in the same way as the IP header’s checksum, described in Chapter 4. The field is two bytes. A message that travels only within a local Ethernet network doesn’t need the UDP checksum because the Ethernet frame’s checksum provides error checking. For a message that travels through different, possibly unknown, networks, the checksum enables the destination to detect corrupted data. Data. A UDP datagram can be up to 65,535 bytes, and the header is eight bytes, so a datagram can carry up to 65,527 bytes of data. In practice, the source computer usually limits datagrams to a shorter length. One reason to use shorter datagrams is that a very large datagram might not fit in the destination’s receive buffer. Or the application receiving the data may expect a message of a specific size. Shorter datagrams may also be more efficient. When a large datagram travels through networks with different capabilities, the Internet Protocol may fragment the datagram, requiring the destination to reassemble the fragments. All of the data will still probably get to its destination, but generally it’s more efficient to divide the data at the source and reassemble it at the destination, rather than relying on IP to do the work en route. The IP standard requires hosts to accept datagrams of up to 576 bytes. An IP header with no options is 20 bytes, and the UDP header is 8 bytes. So a UDP datagram with up to 548 data bytes and no IP options should be able to reach its destination without fragmenting.

Supporting UDP in Embedded Systems

Supporting UDP in an embedded system requires the ability to add a header to data to transmit and remove the header from received data, plus support for IP.

To send a datagram using UDP, a computer in an Ethernet network must do the following:

• Place the destination port number and datagram length in the appropriate locations in the UDP header. The source port number and checksum in the header are optional. Computing the checksum requires knowing the IP addresses of the source and destination.

• Append the data to send to the header.

• Place the UDP datagram in the data portion of an IP datagram. The IP datagram requires source and destination IP addresses and a checksum computed on the header.

• Pass the IP datagram to the Ethernet controller’s driver for sending on the network. To receive a datagram using UDP, a computer in an Ethernet network must do the following:

• Receive an IP datagram from the Ethernet controller’s driver.

• Strip the IP header from the datagram. Calculate the IP checksum and compare the result with the received value.

• If the checksums match, strip the header from the UDP datagram. If using the UDP checksum, calculate its value and compare it to the received checksum.

• Use the destination port number to decide where to pass the received data.

As the examples at the beginning of the networking tutorial showed, if you’re using a module with UDP support, the details of creating the datagrams, extracting data from a received datagram, and dealing with the checksums are handled for you. The application code just needs to provide the IP addresses, port numbers, and data to send and call a function to send the datagram, or wait to receive data in a datagram addressed to a specific port.