Inter-Process Communication with Sockets
Client-Server Model
A standard model for distributed applications is the client-server model. A server is a process that is waiting to be contacted by a client process so that the server can do something or the client. A typical scenario is as follows:
- The server process is started on some computer system. It initializes itself, then goes to sleep waiting for a client process to contact it requesting some service.
- A client process is started, either on the same system or on another system that is connected to the server’s system with a network. The client process sends a request across the network to the server requesting a service of some form.
- When the server process has finished providing its service to the client, the server goes back to sleep, waiting for the next client request to arrive.
Socket definition
A communication between two processes running on two computer systems can be completely specified by the association: {protocol, local-address, local-process, remote-address, remote-process} We also define a half association as either {protocol, local-address, local-process} or {protocol, remote-address, remote-process}, which specify half of a connection. This half association is also called socket, or transport address. The term socket has been popularized by the Berkeley Unix networking system, where it is “an end point of communication”, which corresponds to the definition of half association.
System calls related to sockets
For a UNIX file, there are six system calls for input/output (I/O): open, create, close, read, write and lseek. All these system calls work with a file descriptor, a number corresponding to a certain file. It would be nice if the interface to the network facilities maintained the file descriptor semantics of the Unix file system, but network I/O involves more details and options than the file input/output. However, the difference is not extremely big.
This figure shows a time line of a typical scenario that takes place for a connection-oriented transfer. First the server is started, then sometimes later a client is started that connects to the server.
To do network I/O, the first thing a process must do is call the socket (see the man page for the system calls presented, e.g. man -s3n socket) system call, specifying the type of communication protocol desired.
#include <sys/types.h>
#include <sys/socket.h>
int socket(int family, int type, int protocol);
for our lab, we will use only the internet protocols and stream socket type, so the function call will look like: sockfd = socket(AF_INET, SOCK_STREAM, 0); The socket system call returns a small integer value, similar to a file descriptor. We call this a socket descriptor, or a sockfd.
Up to now, for the association {protocol, local-address, local-process, remote-address, remote-process} we have only specified the protocol. In order to fill the local-address and local-process elements of the association we will use the bind system call.
#include <sys/types.h>
#include <sys/socket.h>
int bind(int sockfd, struct sockaddr *myaddr, int addrlen);
The second argument of bind is a pointer to a protocol-specific address, and the third argument is the size of the address structure. bind tells the system “this is my address and any messages received for this address are to be given to me”.
Then, the server indicates that is willing to receive connections:
int listen(int sockfd, int backlog);
The backlog argument specifies how many connection requests can be queued by the system while it waits for the server to execute the accept system call.
After executing the listen system call, an actual connection is waited for by having the server execute the accept system call.
#include <sys/types.h>
#include <sys/socket.h>
int accept(int sockfd, struct sockaddr *peer, int *addrlen);
accept takes the first connection request from the queue, and creates another socket with the same proprieties as sockfd. When a connection request is received and accepted, the new socket descriptor returned by accept refers to a complete association {protocol, remote-address, remote-process} with the last two fields filled with information from the client. The client’s address is also set in the second (*peer) parameter together with its length, *addrlen;
A client process connects to a socket descriptor following the socket system call to establish a connection with a server:
#include <sys/types.h>
#include <sys/socket.h>
int connect(int sockfd, struct sockaddr *servaddr, int addrlen);
The sockfd is a socket descriptor that was returned by the socket system call. The second and the third argument are a pointer to a socket address, and its size.
From now on, the server and the client can use the write/read system calls for file descriptors in order to communicate. Stream sockets exhibit a behaviour with the read and write system calls that differs from normal file I/O. A read or a write on a socket might input or output fewer bytes than requested, but this is not an error condition. The reason is that buffer limits might be reached for the socket in the kernel and all that is required is for the caller to invoke the read or write system call again, for the remaining bytes.
Many of the socket system calls require a pointer to a socket address structure as an argument. The definition of this structure is in
<sys/socket.h>:
struct sockaddr {
u_short sa_family; /* address_family: AF_xxx value */
char sa_data[14];
};
The contents of the 14 bytes of protocol-specific address are interpreted according to the type of address. For the Internet family, the following structures are defined in <netinet/in.h>:
struct in_addr {
u_long s_addr; /* 32 bit netid/hostid */
};
struct sockaddr_in {
short sin_family; /* AF_INET */
u_short sin_port; /* 16 bit port number, network byte ordered */
srtuct in_addr sin_addr; /* 32 bit netid/hostid, network byte ordered */
char sin_zero[8]; /* unused */
}
Both the client and the server close their sockets using the close function call.
