Guide to Embedded Systems Architecture - Part 3: Transport layer (UDP) and embedded Java and networking middleware examples

[Part 1 of this article begins by defining "middleware" and looking at some networking middleware driver examples. Part 2 offers pseudocode examples for PPP Link Control Protocol states and a look at the IP networking layer protocol.]

Transport Layer Middleware Example: User Datagram Protocol (UDP)
The two most common transport layer protocols are the transmission control protocol (TCP) and the user datagram protocol (UDP). One of the main differences between the two protocols is reliability. TCP is considered reliable because it requires acknowledgments from recipients of its packets. If it doesn't receive them, TCP then retransmits the unacknowledged data.

UDP, on the other hand, is an unreliable transport layer protocol, because it never knows whether or not the recipient of its packets actually receive the data. In short, this example covers UDP, a simple, unreliable, datagram-oriented protocol based upon RFC768. The UDP packet is shown in Figure 10-15.

Transport layer protocols, such as UDP (user datagram protocol), sit on top of internet layer protocols (such as IP), and are typically responsible for establishing and dissolving communication between two specific devices. This type of communication is referred to as point-to-point communication. Protocols at this layer allow for multiple higher-layer applications running on the device to connect point-to-point to other devices. While some transport layer protocols can also ensure reliable point-to-point data transmission, UDP is not one of them.

While the mechanisms for establishing communication on the server side can differ from those of the client device, both client and server mechanisms are based upon the transport layer socket. There are several types of sockets that a transport protocol can use, such as stream, datagram, raw, and sequenced packet, to name a few. UDP uses datagram sockets, a message oriented socket handling data one message at a time (as opposed to a continuous stream of characters supported by a stream socket used by TCP, for example).

There is a socket on each end of a point-to-point communication channel, and every application on a device wanting to establish communication to another device does so by establishing a socket. Sockets are bound to specific ports on that device, where the port number determines the application incoming data is intended for. The two devices (client and server) then send and receive data via their sockets.

In general, on the server side a server application is running, listening to the socket, and waiting for a client to request a connection. The client essentially communicates to the server through its port (see Figure 10-16a).

Ports are 16-bit unsigned integers, meaning each device has 65536 (0-65535) ports. Some ports are assigned to particular applications (i.e., FTP = ports 20-21, HTTP = port 80, etc.). UDP essentially includes the destination IP address and port number in the transmitted packet, there is no handshaking to verify the data is received in the correct order, or even at all.

The server determines if the received data is for one of its own applications by extracting the IP address and port number from the received packet. After the connection is successfully established, the client application establishes a socket for communication, and the server then establishes a new socket to listen for incoming requests from other clients (see Figure 10-16b).

The pseudocode below demonstrates a sample UDP pseudocoded algorithm for processing an incoming datagram. In this example, if the socket for the received datagram is found, the datagram is sent up the stack (to the application layer), otherwise an error message is returned and the datagram discarded.