OS Interface: Sockets

We have seen earlier abstract ideas behind OS-supported message passing, which can be implemented on the network layers mentioned above. To show how an OS layer sits on top of these network layers, let us consider the concrete example of Unix sockets. Unix sockets provide an interface to UDP and TCP/IP and other protocols at this level. Unlike IP ports, sockets support a combination of free, input, and bound ports. Socket declarations are given in the file <sys/socket.h>. A server providing a service first creates a socket that serves as an input port:

service\_sock = socket (af, type, protocol)

listen (service_socket, qlength) - stream
server_end = accept (service_socket, remote_addr, remote_addr_len)  - stream only
write (server_end, msg, len)
or
send (server_end, msg, length, flags)
or
sendto (server_end, msg, length, flags, dest_addr, addr_len) - datagram only

read (server_end, &msg, len)
or
recv (server_end, &msg, len, flags)
or
recvfrom (server_end, msg, length, flags, &from_addr, &from_addr_len) - datagram only

client_connection_sock = socket (af, type, protocol)

connect (client_connection_sock, dest_addr, dest_addr_len)
read, write, send, receive, sendto, recvfrom

The bind call binds the socket to a local address. The structure of local addresses is given in the file <netinet/in.h>.

The address indicates an internet address and port number. The port number is a 16 bit number the server chooses. Port numbers 0..1023 are reserved by system servers such as ftp and telnet. Look at the file /etc/services for port number of system servers. A user-defined server, must choose an unbound port number greater than 1023. You can explicitly pick one of these values and hope no other process is using the port. A port number of 0 in the port field indicates that the system should choose the next unbound port number, which can then be read back by the server using getsockname.

When communicating internet addresses, port numbers, and other data among machines with different byte orders, you should use routines (such as htons, htonl, and ntohs ) that convert between network and host byte orders for shorts/longs. A bind call can use a special constant (htonl (INADDR_ANY)) for an internet address to indicate that it will listen on any of the internet addresses of the local host.

To talk to a server, a client needs to create a connection endpoint through its own socket and bind calls. Then it can use connect to link its socket with the server socket. If it does not have the internet address of the host, it can determine this address from the host name using gethostbyname.

A socket bound by the server serves as an ``input port'' to which multiple clients can connect. The connect call creates a new ``bound port'' for the server-client connection. The client end of the bound port is the socket connected by the client. The other end is returned to the server by the accept call, when a successful connection is established by the client. The server determines the number of connections to a bound socket using the listen call. For UDP, no connections need to be established through accept and connect - the connect call can be invoked but it is a local operation simply storing the intended remote address with the socket. In the stream case, the client usually does not bind its end of the socket to a local port, the system automatically binds the socket to an anonymous port. Sockets are not strictly input or bound ports since they can be inherited and accessed by children of the process that created them (through the mechanism of file descriptor inheritance we shall see later).

Data can be send/received using either the regular read and write calls, or the special send and recv calls, which take additional message-specific arguments such as send ``out of band'' data. The sendto and recvfrom calls are applicable only for UDP datagram communication and are necessary if the client has not ``connected'' the socket to a remote address.