System coding: Network & UDP

In the final instalment of Dr. Chris Brown’s guide, we investigate the connectionless model and network programming using UDP.

Last month, we examined the use of the sockets API for writing connection-oriented clients and servers that use the TCP protocol. This month we’re going to look at a connectionless model, using UDP. What do we mean by ‘connectionless'? Well, from a programmer’s viewpoint, we mean there are no steps required in your code to actually set up the communication – none of the connect(), listen() and accept() calls that we saw in LXF203. A client simply builds a datagram, slaps the recipient’s address on and sends it. From the server’s point of view, we sometimes picture a UDP-based server as holding out a bucket, labelled ‘Port 69’ or whatever. Any client can lob a datagram into the bucket. A UDP-based server may find itself retrieving messages from many clients in an arbitrarily interleaved order (As my sequence of operations diagram show).

If you were to examine the packet flow on the network it would also become clear that UDP-based services are, in a sense, simpler than TCP-based ones, because there’s no exchange of packets to set the connection up, or to dismantle it again. So, eg, if a program on machine A wants to send, say, a few dozen bytes of data to a program on machine B, it’s far more efficient in terms of the amount of data traversing the network to just send a quick UDP datagram rather than the nine messages that TCP would take (three to set the connection up, one to send the data, one to acknowledge it, and four to close the connection).

There is, of course, a down-side to the frugal nature of UDP: there is no ‘guarantee’ of delivery. The datagram might simply be lost in transit and we would be none the wiser. For this reason UDP is sometimes half-jokingly referred to as the ‘Unreliable datagram Protocol’. (It actually stands for ‘User Datagram Protocol’.) We need to be clear what ‘unreliable’ means. We’re not saying that UDP is inherently flaky. We’re simply saying that there is no mechanism built in to the protocol to verify that the datagram arrived, or to re-send it if it didn’t. For that matter we need to be clear what it means to say that TCP is a ‘guaranteed’ delivery service. If someone pulls the network cable out of the server, your packets won’t arrive. And you won’t get your money back. We’re simply saying that TCP has built-in mechanisms to acknowledge receipt of data and to re-transmit it if necessary.

Actually, it gets worse! UDP not only doesn’t guarantee to deliver the messages, it doesn’t even guarantee to deliver them in the order you sent them. Admittedly, if you’re sending packets across a local area network, the chances of one packet leapfrogging over another are slight, but as you broaden your scope to a wide area network, the possibility of mis-ordered packets increases.

Now it might occur to you to question why it would ever be acceptable to use a delivery service that makes such weak guarantees. Well, the reality is that for many applications things don’t immediately fall over if packets go missing. They just degrade a bit. A classic example is VoIP (Voice Over IP) which uses a protocol called RTP (Real-time Transport Protocol), usually layered over UDP, to carry the actual media stream. For an application like this, timeliness of delivery is more important than reliability. We all know that we can make sense of conversations from our children on their phones even if parts of them are missing. (Parts of the conversation I mean, not parts of our children or parts of their phones.)

Text vs binary protocols

In the context of this discussion, an application protocol is a description of how a client and server will communicate – the types of message they can send and receive, and the structure of those messages. Protocols such as HTTP (Hypertext Transfer Protocol) and SMTP (Simple Mail Transfer Protocol) are text based – the messages they exchange are simply lines of text. For sure, it’s highly structured text, but fundamentally it’s just a sequence of