CIS307: Guidelines for the solution of Homework 5

Organization of the program

We now have two programs - STORE_MANAGER and RAND_PROC. These programs are invoked manually from the command line on possibly different computers. RAND_PROC communicates with STORE_MANAGER through sockets. STORE_MANAGER maintains a table of ordered pairs in STORE, and processes serially (an unbounded number of) requests for read and update operations on STORE received through messages from RAND_PROC, sending the response to each request in a message addressed to the requestor. RAND_PROC includes the code we have seen in the past for the homework_main and for the rand_child processes.

STORE_MANAGER is invoked first from the command line on a computer. It creates a datagram socket and binds it to a port chosen by the system. It then writes on the screen the port number associated with its socket. The client program RAND_PROC is invoked after STORE_MANAGER displays the port number assigned to its socket. Each client program is invoked from the command line with arguments specifying the host name of the computer that STORE_MANAGER is running on, the port number displayed by STORE_MANAGER, and the seed for the random number generator. Each client program may be invoked on the host running STORE_MANAGER or on a different computer.

Given this set up, the programs may be organized into two files - store_manager.c and rand_proc.c (additional header files may be used to group together data structures and operations needed in each program). Thus STORE_MANAGER may be run, say on snowhite server, by invoking

store_manager

at the command line at snowhite server. Thereafter RAND_PROC may be run, say on thunder, by invoking

rand_proc hostname portnumber seed

at the command line on thunder, where 

  
    hostname   :  host name of the computer that STORE_MANAGER is 
                  running on, in this example, snowhite.cis.temple.edu, 

    portnumber :  the port number displayed on the screen by STORE_MANAGER, 
 
    seed       :  seed for the random number generator
are the arguments to the program in rand_proc.c. Other copies of RAND_PROC may be run on snowhite, thunder, or any other machine of your choice by invoking rand_proc as shown above with the appropriate arguments from the command line on that computer. The files store_manager and rand_proc contain the executable code for store_manager.c and rand_proc.c respectively.

Establishing sockets for communication

RAND_PROC uses sockets to communicate with STORE_MANAGER. Each program creates a datagram socket in the Internet domain and binds an address to it to be able to receive messages through it. The address bound to a socket comprises an internet address (usually that of the host that the socket is created on) and a port number. A program typically sends messages to a socket by specifying the address associated with the socket.

STORE_MANAGER first creates an Internet domain datagram socket. It then binds a local address to the socket, getting the system to pick a port number for it. It queries the system for the port number assigned to the socket and writes the port number on the screen. Recall that the host name of the computer that STORE_MANAGER is invoked on and the port number displayed by STORE_MANAGER are made available to RAND_PROC through command line arguments. This enables them to construct the address associated with the socket created by STORE_MANAGER. The following is an outline of the steps carried out by STORE_MANAGER in establishing a socket. 

  Algorithm SetUpSocketInStoreManager
  begin

   1. Create a datagram socket by invoking socket() as 
        s := socket(AF_INET,SOCK_DGRAM,0);
   
   2. Bind local address to socket as follows :   
        { sm_socket_address is assumed to be declared as a variable of type 
          struct sockaddr_in }

        sm_socket_address.sin_family := AF_INET;
        sm_socket_address.sin_addr.s_addr := INADDR_ANY; 
        { The wildcard INADDR_ANY matches all valid network addresses of  
          the computer. }

        sm_socket_address.sin_port := 0;  { Let system pick port number } 
       
        Now invoke bind() as 
          bind(s,&sm_socket_address,sizeof(sm_socket_address));
   
   3. Find the port number assigned by the system by invoking 
      getsockname() as  
        getsockname(s,&sm_socket_address,&length_of_address);

   4. Print the host's representation of the port number, 
      ntohs(sm_socket_address.sin_port;

  end SetUpSocketInStoreManager
Each client program also creates a datagram socket and binds an address to it, having the system select a port number for the socket. STORE_MANAGER gets the address of the socket in a client when it receives a message (containing a request for a read or update operation) from the client, and sends its response to the socket associated with that address. The client program constructs the address of the socket in STORE_MANAGER from the host name and the port number arguments, and sends its messages requesting read and update operations to this address. Algorithm SetUpSocketInRandProc details the steps outlined above. 

  Algorithm SetUpSocketInRandProc
  begin

   1. Create a datagram socket by invoking socket() as 
        s := socket(AF_INET,SOCK_DGRAM,0);
   
   2. Bind local address to socket as follows :   
        { rp_socket_address is assumed to be declared as a variable of type 
          struct sockaddr_in }

        rp_socket_address.sin_family := AF_INET;
        rp_socket_address.sin_addr.s_addr := INADDR_ANY;
        { The wildcard INADDR_ANY matches all valid network addresses of 
          the computer. }

        rp_socket_address.sin_port := 0;  { Let system pick port number } 
       
        Now invoke bind() as 
          bind(s,&rp_socket_address,sizeof(socket_address));
   
   4. Construct the address of the socket created by STORE_MANAGER by 
      assigning the appropriate values to the components of 
      sm_socket_address. sm_socket_address is assumed to be declared 
      as a variable of type struct sockaddr_in.

        sm_socket_address.sin_family := AF_INET;

        Get the IP address of the computer running STORE_MANAGER from the 
        the first command line argument : 
 
        { assumes the declaration  
                           struct hostent *host_info;
        }
          host_info := gethostbyname(argv[1]);
        
        Assign the IP address by copying individual bytes, invoking bcopy as  
          bcopy(host_info->h_addr,&sm_socket_address.sin_addr,
                host_info->h_length);

        Assign the network representation of the port number from the 
        second command line argument : 
 
          sm_socket_address.sin_port := htons(atoi(argv[2]));

      { Now sm_socket_address contains the address of the socket created 
        by STORE_MANAGER. }

  end SetUpSocketInRandProc

Performing I/O through sockets

The client program RAND_PROC constructs the address of the socket created by STORE_MANAGER from the name of the machine STORE_MANAGER runs on and the port number associated with the socket they receive as arguments. It can then send messages to STORE_MANAGER by specifying this address for the destination. However, the addresses of the sockets created by the client programs are not made available to STORE_MANAGER explicitly. This is because STORE_MANAGER being a server does not INITIATE the exchange of messages with the clients but sends a message to a client in response to a request received from it, and with the proper choice of communication primitives the receiver of a message can obtain the address of the socket the message originated from.

Following this scheme, RAND_PROC invokes the function sendto() to send a message to STORE_MANAGER, and STORE_MANAGER invokes recvfrom() to receive messages from the clients. The function recvfrom() returns to STORE_MANAGER the address of the socket associated with the sender (through one of its parameters) and STORE_MANAGER sends its response to the request specifying this address for the destination. The functions sendto() and recvfrom() may be used in the transmission of messages from STORE_MANAGER to the clients as well.

The details of sending and receiving messages should be hidden in the functions SSTORE_READ() and SSTORE_UPDATE() invoked by the client programs. The intent is to avoid burdening the user with the details of the implementation and present an interface that specifies only the semantics of the operation.

Format of messages exchanged through sockets

STORE_MANAGER retrieves messages one at a time from its socket, carries out on STORE the operation requested in the message, and sends its response to the socket associated with the requester. Since the update operation requires one more operand than the read operation, the structure of a message requesting an update operation would be different from that of one asking for a read operation. Since datagram sockets preserve message boundaries in the data transmitted through them, STORE_MANAGER would be able to retrieve messages one at a time while reading from its socket. However, a message can be assigned to a variable of the appropriate type directly upon retrieval only if STORE_MANAGER can predict in advance the type of operation on STORE that would be specified in the message. Since these operations are chosen at random by RAND_PROC, STORE_MANAGER would not be able to anticipate them, and would have to adopt a somewhat cumbersome procedure involving an examination of the length of the message before assigning the message to a variable of the appropriate type. We may alleviate the task by arranging to use messages of the same length (incurring some loss in effective bandwidth) while requesting both read and update operations. A message specifying a read operation is padded at the end with enough spaces to make it as long as one asking for an update operation before being sent, and STORE_MANAGER ignores the dummy characters while parsing the message. This makes for a simpler design, accompanied, however, by a slight reduction in communication bandwidth. The command to read the store balance should be treated analogously [so that we have a single format for all the operations].

The above discussion applies to messages originating from STORE_MANAGER as well. Response messages for all cases except that of an invalid read operation have the same length, but the latter requires fewer characters. All cases may, however, be handled in a uniform manner by getting STORE_MANAGER to put in some padding in the messages containing the response to invalid read operations.