Chapter 2: Introduction to Sockets Programming

---

In this chapter, we take a quick tour of Sockets programming. We discuss the basic elements of the Sockets API, addressing, ports, and differences between client and server applications. We complete this quick introduction with a look at a sample client and server application that can communicate over the Internet using the stream model of communication. All code for this chapter can be found on the companion CD-ROM under /software/ch2.

Note 

Except for line numbers, boldface is used only for functions that are part of the Socket API in code listings and in the text. It is used to emphasize what is networking specific. This convention is followed in this chapter and throughout the book.

The Sockets Programming Paradigm

The Sockets API, first introduced into the 4.2BSD Unix® system, is the de facto standard for network programming. With a very simple API, Sockets provides the ability to build complex communications applications with server and/or client semantics. The Sockets API has been ported to all useful operating systems, including Linux®, commercial kernels, and real-time operating systems, academic operating systems, and even Windows® (though some differences were made here).

In this section, we take a quick tour of the Sockets API using a sample client and server to illustrate the function calls. As with all software examples in Part I of this book, the C language is used. Part II includes software patterns for many other languages, leveraging from the original patterns written in C.

Ports

Recall from Chapter 1 that an application available on the Internet can be defined by two elements, an Internet address (IP address) and a port. The port can be well-known (typically defined for servers, so that clients can find it) or ephemeral (typically used by clients, dynamically assigned by the network stack). The port is the communication endpoint between two entities on the Internet, connected by a socket.

Sockets

The socket is the conduit between applications over the Internet. A stream socket must be logically connected between the two endpoints (using the BSD API), whereas datagram sockets require no connection setup other than the creation and initialization of the local socket endpoints.

After a stream socket is defined and connected, data flows without any additional attention to addressing because a virtual circuit has been defined. With datagram sockets, because no virtual circuit exists, each packet sent must have a recipient address specified to direct the datagram to its destination (with one caveat, which we discuss later in Chapter 6, Advanced Sockets Programming Topics).

Note 

It’s important to note that a port represents an application, but an application can be represented by multiple ports. Methods for dealing with multiple ports (such as using the select call) are discussed in Chapter 6, Advanced Socket Programming Topics.

Addressing

If we use standard communication analogies to define the two socket types, we can define a stream connection as a telephone call and a datagram connection as postcard communication. When we make a telephone call, we’re required to set up the channel to communicate (in this case, dial the number and await the receiver to pick up the phone). Once the receiver answers, we can communicate on a one-to-one basis in a stream fashion. Datagram communication allows us to define addressing information for each message we send. Therefore, there’s no stream, but a number of independent (or related) packets sent separately. Furthering the analogy, if we were provided N-way conferencing on our telephone call, multicast communication would be realized. Finally, broadcast would be much like using a bullhorn to talk to our neighbors.

In either the stream or datagram case, we still need to identify the receiver for our communication. This is done using a tuple, which uniquely identifies the receiver. The tuple includes the host address, the port (local identifier), and the protocol, such as

{ tcp, 192.168.1.1, 45001 }

This tuple is called a half-association. It defines all the necessary elements to uniquely identify an endpoint of a socket. Note that the protocol is included in the tuple, which means that port 45001 for TCP is not the same as port 45001 for another protocol, such as UDP.

To identify a complete socket connection, including both endpoints, we need a 5-tuple association. This defines the protocol and both endpoints for the socket. For example,

{ tcp, 192.168.1.1, 45001, 192.168.9.181, 80 }

defines a full association representing the hosts and processes for the socket.

---