Toward a better understanding of sockets

The term "sockets" crops up all the time in the TCP/IP world, but do you really know what it means? Basically, it is the method of identifying a specific process running on a machine that is accessible via an IP connection. More importantly, it is also the common name for the standard API for TCP/IP.

The Sockets API - also called the Berkeley Sockets Interface - was developed at the University of California at Berkeley for the 4.1c release of BSD Unix in the early 1980s (by the by, BSD stands for Berkeley Software Distribution). The simplicity of the interface made it common in Unix variants, including SCO, Linux and SunOS. Ultimately, it was supported by Windows (95, 98, NT and CE), NetWare, BeOS and a slew of other operating systems.

Berkeley Sockets provides applications with two ways to access network transport services: connection-oriented (a.k.a. session- or streamoriented), whereby TCP is used to maintain a channel between the client and server; and connectionless (a.k.a. datagram) communications, which use the User Datagram Protocol (UDP) to transfer data packets from one machine to another without guaranteed delivery.

The concept of sockets is straightforward: To send a message to a machine is not enough - you need to be able to send the message to a specific software process, an end point for the communication. By giving each service process running on a machine a "port" - a numeric value used to identify the process - a client application can distinguish between, say, a file transfer service and a Web service.

The Internet Assigned Numbers Authority (www.iana.org) sets the port value for a given service. For example, Web servers, by default, use TCP connections on Port 80. FTP servers are a little more complex, using TCP on Port 21 for commands and Port 20 for data transfers.

Protocols such as echo (Port 7) use UDP or TCP, while SNMP (which uses Port 161) only uses UDP. Most services can be allocated to different port numbers if required. For example, a Web site might run a second Web server on Port 8080.

It is the combination of a port and an IP address that makes a socket. Each client application has a unique socket associated with it, while the socket for a service process may support multiple instances of a service.

For example, a Web server might receive a number of service requests on Port 80 in a short period. Instead of handling the requests on a first-in, first-out basis, the server could launch a copy of itself for each request. Knowing the client's socket allows the results of each request to be returned to the correct client.

This strategy ensures that service requests that take a long time to complete (for example, having a Web server-based application perform a database lookup) don't block other requests that can be satisfied quicker (such as simple Web content retrievals).

The socket API, while simple, is not particularly elegant, and programmers usually access TCP/IP communications through higher-level APIs, such as Remote Procedure Calls.

Under Windows, of course, things are different, and there's a variant of the Berkeley Sockets Interface specifically for Windows called, not too surprisingly, the Windows Socket Specification (WinSock).

Currently, most of the Windows market uses the WinSock 1.1 implementation, but Microsoft is slowly but surely moving the market toward WinSock 2, described by some as WinSock 1.1 on steroids.

The bottom line is that due to the rise of the Internet and TCP/IP, sockets are now the dominant communications mechanism and look likely to remain in that position for a long time to come.

Send a message to the Gearhead socket at gh@gibbs.com.