IN CHAPTER 2, WE COVERED THE BASIC functions used in socket programming, and demonstrated a simple socket server and a simple socket client. Yet while our server and client programs were functional, they didn't do all that much. In this chapter and the following chapters, we'll go through implementing the socket interface in real-world scenarios and creating more robust networked applications step by step.

You'll remember that in Chapter 1 we discussed two types of network communications: those that required a connection, and those that did not. Our simple server and simple client require a connection and use the Transmission Control Protocol (TCP). Thus, the server and client applications in Chapter 2 use streaming sockets-that is, sockets that require a connection. There are also datagram sockets, or sockets that don't require a connection and use the User Datagram Protocol (UDP). In this chapter, we'll step through a UDP server and a UDP client. We'll also take a look at transferring files back and forth, which is more involved than just sending strings. Finally, we'll discuss error handling and error checking as a key part of any applications you develop.

User Datagram Protocol

In Chapter 2, our client and server programs were based on streaming sockets and used TCP. There is an alternative to using TCP, and that is UDP, or what is otherwise known as datagram sockets. Remember from Chapter 1 that a UDPbased network communication has some particular qualities:

• UDP makes no guarantee of packet delivery.
• UDP datagrams can be lost and arrive out of sequence.
• UDP datagrams can be copied many times and can be sent faster than the receiving node can process them.

UDP sockets are generally used when the entire communication between the server and client can exist within a distinct network packet. Some examples of UDP-based communications include the Domain Name Service (DNS), Network Time Protocol (NTP), and the Trivial File Transfer Protocol (TFTP). For example, a simple DNS lookup request essentially consists of just two pieces of information: the name or number in the request, and the corresponding answer from the DNS server in the response (which might even be an error). There's no need to incur the overhead of opening a streaming socket and maintaining a connection for such a simple communication. An NTP request is similar. It consists of a question ("What time is it?") and the server's answer. No ongoing communications are necessary. More information on when to use UDP over TCP, or vice versa, is covered in Chapter 7.