A socket is a communication endpoint on a network node. Sockets interact directly with processes.

A process is a unit of state and behavior in an application. An application can run as a single process, but may use multiple processes that handle specific elements of the application. For example, the National Weather Service has a process that exposes weather data. (A process that exposes data and/or functionality directly to the web is called a web service. A web service is a type of process.) A web application may access the data and put it in a web page. In this case, the application uses two processes, the NWS data process and the “main” process that gets the weather data and serves up web pages.

Sockets allow two processes to communicate (this is called IPC, or inter-process communication). Each process has its own socket, and connects with the other socket. This is called binding. So, sockets are the mechanism by which TCP establishes a connection between a client and a server.

There are different types of sockets (the term “socket” is very general, as it refers to communications between various different entities). An internet socket consists of an IP address and a port number.

TCP Sockets

Socket objects are a common implementation of sockets. The steps to use socket objects to establish a TCP connection are:

1. 1. Server creates (or, has already created) a socket object that listens on a particular port (for example, 80 for HTTP traffic).
   2. Client creates a socket object, and assigns its own IP address and a port number to it. This is called *binding*. (Assigning a port number of 0 when binding will cause the operating system to select and bind an available ephemeral port number to the socket; this is the usual practice with client sockets). It also assigns a constant to a type parameter that specifies the type of service requested. In TCP, this constant is SOCK_STREAM, which specifies the connection-oriented byte stream that TCP uses.
   3. Client sends a connection request to the listening server socket object.
   4. The process that the listening server socket object is bound to creates a new process, connects it to a new socket object, assigns it the server IP address and port number (again, 80 for HTTP traffic), and assigns the incoming IP address and port to it.

This creates a connection: a socket in the client with a server IP address and port, and a socket in the server with the client IP address and port. Communication takes place over this connection.

This allows multiple discrete connections between a single client and a single server. Since the port number for each client socket is different, the traffic for one client port doesn’t get confused with traffic for a different one, so multiple processes on the same client can interact independently with the same server.

UDP Sockets

Since UDP is a connectionless protocol, UDP sockets work a bit differently from TCP sockets:

1. 1. The server has a listening socket as always.
   2. The client creates a socket as in step 2 above, but specifies SOCK_DGRAM for the type parameter, which specifies the datagrams that UDP uses.
   3. The client sends a message to the server, specifying the server’s IP address and port number in the message.
   4. The server sends a message back to the client, using the client IP address and port contained in the client message.
   5. Repeat steps 3 and 4 as necessary.

With TCP, the server process creates a socket on its end for each client socket making requests to it. With UDP, the process responds directly to client sockets making requests on UDP. The socket method of the Socket API specifies the type of socket to use with a type parameter: this parameter can either a SOCK_STREAM (for TCP) or SOCK_DGRAM value, among others. (For more information, see Berkeley Sockets.)

The next article begins the discussion of the Application Layer.