Initially, a socket is created in the unconnected state, meaning the socket is not associated with any foreign destination. The connect subroutine binds a permanent destination to a socket, placing it in the connected state. An application program must call the connect subroutine to establish a connection before it can transfer data through a reliable stream socket. Sockets used with connectionless datagram services need not be connected before they are used, but connecting sockets makes it possible to transfer data without specifying the destination each time.
The semantics of the connect subroutine depend on the underlying protocols. An application program desiring reliable stream delivery service in the Internet family should select the Transmission Control Protocol (TCP). In such cases, the connect subroutine builds a TCP connection with the destination and returns an error if it cannot. In the case of connectionless services, the connect subroutine does nothing more than store the destination address locally. Similarly, application programs desiring connection-oriented datagram service in the AIX Network Device Driver (NDD) family should select the Asynchronous Transfer Mode (ATM) protocol. Connection in the ATM protocol establishes a permanent virtual circuit (PVC) or switched virtual circuit (SVC). For PVCs, the local station is set up, and there is no network activity. For SVCs, the virtual circuit is set up end-to-end in the network with the remote station.
Connections are established between a client process and a server process. In a connection-oriented network environment, a client process initiates a connection and a server process receives, or responds to, a connection. The client and server interactions occur as follows:
In the Internet domain, the server process creates a socket, binds it to a well-known protocol port, and waits for requests. If the server process uses a reliable stream delivery or the computing response takes a significant amount of time, it may be that a new request arrives before the server finishes responding to an old request. The listen subroutine allows server processes to prepare a socket for incoming connections. In terms of underlying protocols, the listen subroutine puts the socket in a passive mode ready to accept connections. When the server process starts the listen subroutine, it also informs the operating system that the protocol software should queue multiple simultaneous requests that arrive at a socket. The listen subroutine includes a parameter that allows a process to specify the length of the request queue for that socket. If the queue is full when a connection request arrives, the operating system refuses the connection by discarding the request. The listen subroutine applies only to sockets that have selected reliable stream delivery or connection-oriented datagram service.
A server process uses the socket, bind, and listen subroutines to create a socket, bind it to a well-known protocol address, and specify a queue length for connection requests. Invoking the bind subroutine associates the socket with a well-known protocol port, but the socket is not connected to a specific foreign destination. The server process may specify a wildcard allowing the socket to receive a connection request from an arbitrary client.
All of this applies to the connection-oriented datagram service in the NDD domain, except that the server process binds the locally created socket to an AIX NDD name and specifies ATM B-LLI and B-HLI parameters before calling the listen subroutine. If only B-LLI is specified, all incoming calls (or connections), regardless of the B-HLI value, will be passed to this application.
Once a socket has been set up, the server process needs to wait for a connection. The server process waits for a connection by using the accept subroutine. A call to the accept subroutine blocks until a connection request arrives. When a request arrives, the operating system returns the address of the client process that has placed the request. The operating system also creates a new socket that has its destination connected to the requesting client process and returns the new socket descriptor to the calling server process. The original socket still has a wildcard foreign destination that remains open.
When a connection arrives, the call to the accept subroutine returns. The server process can either handle requests interactively or concurrently. In the interactive approach, the server handles the request itself, closes the new socket, and then starts the accept subroutine to obtain the next connection request. In the concurrent approach, after the call to the accept subroutine returns, the server process forks a new process to handle the request. The new process inherits a copy of the new socket, proceeds to service the request, and then exits. The original server process must close its copy of the new socket and then invoke the accept subroutine to obtain the next connection request.
If a select call is made on a file descriptor of a socket waiting to perform an accept subroutine on the connection, when the ready message is returned it does not mean that data is there, only that the request was successfully completed. Now it is possible to start the select subroutine on the returned socket descriptor to see if data is available for a conversation on the message socket.
The concurrent design for server processes results in multiple processes using the same local protocol port number. In TCP-style communication, a pair of end points define a connection. Thus, it does not matter how many processes use a given local protocol port number as long as they connect to different destinations. In the case of a concurrent server, there is one process per client and one additional process that accepts connections. The main server process has a wildcard for the destination, allowing it to connect with an arbitrary foreign site. Each remaining process has a specific foreign destination. When a TCP data segment arrives, it is sent to the socket connected to the segment's source. If no such socket exists, the segment is sent to the socket that has a wildcard for its foreign destination. Furthermore, because the socket with a wildcard foreign destination does not have an open connection, it only honors TCP segments that request a new connection.
The operating system provides support for connectionless interactions typical of the datagram facilities found in packet-switched networks. A datagram socket provides a symmetric interface to data exchange. While processes are still likely to be client and server, there is no requirement for connection establishment. Instead, each message includes the destination address.
An application program can create datagram sockets using the socket subroutine. In the Internet domain, if a particular local address is needed, a bind subroutine must precede the first data transmission. Otherwise, the operating system sets the local address or port when data is first sent. In the NDD domain, bind must precede the first data transmission. The application program uses the sendto and recvfrom subroutines to transmit data; these calls include parameters that allow the client process to specify the address of the intended recipient of the data.
In addition to the sendto and recvfrom calls, datagram sockets can also use the connect subroutine to associate a socket with a specific destination address. In this case, any data sent on the socket is automatically addressed to the connected peer socket, and only data received from that peer is delivered to the client process. Only one connected address is permitted for each socket at one time; a second connect subroutine changes the destination address.
A connect subroutine request on a datagram socket results in the operating system recording the peer socket's address (as compared to a stream socket, where a connect request initiates establishment of an end-to-end connection). The accept and listen subroutines are not used with datagram sockets.
While a datagram socket is connected, errors from recent send subroutines can be returned asynchronously. These errors can be reported on subsequent operations on the socket, or a special socket option, SO_ERROR. This option, when used with the getsockopt subroutine, can be used to interrogate the error status. A select subroutine for reading or writing returns true when a process receives an error indication. The next operation returns the error, and the error status is cleared.
Read the following concepts for more information that you may need before connecting sockets: