UNIX Internet Programming

• Connection oriented sockets are a standard way of communicating between processes.
  • A socket address holds information about the machine and port number. Various types exist, e.g., internet socket addresses are

    struct sockaddr_in {
        u_char  sin_len;
        u_char  sin_family;        /*----Internet address family, e.g. PF_UNIX or PF_INET */
        u_short sin_port;          /*----Port number */
        struct  in_addr sin_addr;  /*----Holds the IP address */
        char    sin_zero[8];       /*----Filling */
    };
                   

  • int socket(int domain,int type,int protocol); - Creates a socket endpoint for communication and returns a descriptor.
    • The domain determines the protocol family. AF_INET is the internet domain.
    • The type describes the type of communication. SOCK_STREAM is the connection oriented type.
    • The protocol specifies the protocol. If set to 0 a default is chosen, e.g., TCP for SOCK_STREAMs.
  • int bind(int socket,struct sockaddr *addr,socklen_t addrlen); - Assigns the socket address to a socket.
  • int listen(int socket,int backlog); - Indicates a willingness to accept connections, queueing up to backlog pending connections.
  • int accept(int socket,struct sockaddr *addr,socklen_t *addrlen); - Accepts connections to the socket. addr is filled with information about the connecting machine, or can be NULL.
  • int connect(int socket,struct sockaddr *name,socklen_t namelen); - For the SOCK_STREAM type, attempts to make a connection to another socket, as specified in name.
  • ssize_t send(int socket, void *msg,size_t len,int flags); - Used to transmit a message to another socket.
  • ssize_t recv(int socket,void *buf,size_t len,int flags); - Used to receive messages from a socket.
• The standard model is a server-client relationship
  • Server
    • Create a socket address for local machine
    • Create a socket
    • Bind the socket address to the socket
    • Listen for connections
    • For each connection received
      • Accept connection
      • Use connection (typically fork a child for this)
  • Client
    • Create a socket address for target machine
    • Create a socket
    • Connect the socket to the target socket address
    • Use connection
• Example server - client programs
  • mysockets.h - Socket library header file
  • mysockets.c - Socket library implementation
  • SocketServerFork.c - Socket server
  • SocketClient.c - Socket client

CSC322 STOPS HERE

• What is RPC?
  • RPC is a powerful technique for constructing distributed, client-server based applications. It is based on extending the notion of conventional, or local procedure calling, so that the called procedure need not exist in the same address space as the calling procedure. The two processes may be on the same system, or they may be on different systems with a network connecting them. By using RPC, programmers of distributed applications avoid the details of the interface with the network. The transport independence of RPC isolates the application from the physical and logical elements of the data communications mechanism and allows the application to use a variety of transports.
  • When combined with the ONC RPCGEN protocol compiler clients transparently make remote calls through a local procedure interface.
• How RPC Works
  • An RPC is analogous to a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure.

  • 

  • The client makes a procedure call that sends a request to the server and waits. The thread is blocked from processing until either a reply is received, or it times out.
  • When the request arrives, the server calls a dispatch routine that performs the requested service, and sends the reply to the client.
  • After the RPC call is completed, the client program continues.
  • A remote procedure is uniquely identified by the triple: (program number, version number, procedure number)
    • The program number identifies a group of related remote procedures, each of which has a unique procedure number.
    • A program may consist of one or more versions. Each version consists of a collection of procedures which are available to be called remotely. Version numbers enable multiple versions of an RPC protocol to be available simultaneously.
    • Each version contains a a number of procedures that can be called remotely. Each procedure has a procedure number.
  • Program numbers are defined in a standard way:
    • 0x00000000 - 0x1FFFFFFF: Defined by Sun
    • 0x20000000 - 0x3FFFFFFF: User Defined
    • 0x40000000 - 0x5FFFFFFF: Transient
    • 0x60000000 - 0xFFFFFFFF: Reserved
• Levels of interface
  • RPC has multiple levels of application interface to its services. These levels provide different degrees of control balanced with different amounts of interface code to implement.
  • The simplified interfaces are used to make remote procedure calls to routines on other machines, and specify only the type of transport to use. The routines at this level are used for most applications.
  • The standard interfaces are divided into top level, intermediate level, expert level, and bottom level.
    • These interfaces give a developer much greater control over communication parameters such as the transport being used, how long to wait beforeresponding to errors and retransmitting requests, and so on.
    • At the top level, the interface is still simple, but the program has to create a client handle before making a call or create a server handle before receiving calls. If you want the application to run on all transports, use this interface.
    • The intermediate level interface of RPC lets you control details. Programs written at these lower levels are more complicated but run more efficiently. The intermediate level enables you to specify the transport to use.
    • The expert level contains a larger set of routines with which to specify transport-related parameters.
    • The bottom level contains routines used for full control of transport options.
  • The standard interfaces provides access to user authentication protocols.
• RPC Programs (using the Simplified Interface)
  • A "remote procedure" is a function.
    • It must take a single pointer argument and return a pointer.
    • To pass multiple items of data in or out they can be bundled into a struct
    • The return pointer must be to non-automatic data so that it exists to be passed back to the calling side, e.g., static or malloced data.
  • Marshalling
    • RPC handles arbitrary data structures, regardless of different machines' byte orders or structure layout conventions, by always converting them to a standard transfer format called external data representation (XDR) before sending them over the transport.
    • The XDR is an data abstraction needed for machine independent communication. The client and server need not be machines of the same type.
    • The conversion from a machine representation to XDR is called serializing, and the reverse process is called deserializing.
    • The translator arguments of callrpc and registerrpc can specify an XDR primitive procedure like xdr_u_long(), or a programmer supplied routine that processes a complete argument structure.
  • A remote procedure is accessed via a server stub.
    • The server registers uniquely identified remote procedures with RPC.
    • xdr functions have to be specified to marshall the data into and back from standard RPC form, so that calls can be made between code in different languages.
    • int registerrpc(u_long prognum,u_long versnum,u_long procnum,char *(* procname)(char *),xdrproc_t inproc,xdrproc_t outproc);
      • prognum, versnum, and procnum identify the procedure.
      • procname is the name of the procedure
      • inproc de-marshalls the input argument
      • outproc marshalls the return value
      • Returns 0 on success, -1 on failure
    • The server calls svc_run() which listens for calls to registered procedures.
  • A remote procedure is called by a client stub.
    • The stub calls an identified remote procedure using the callrpc function.
    • int callrpc(char *host,u_long prognum,u_long versnum,u_long procnum,xdrproc_t inproc,char *in,xdrproc_t outproc,char *out);
      • host is the name of the machine running the remote procedure.
      • in is the address of the data to be passed to the remote procedure
      • out is where the returned data is placed.
      • inproc marshalls the in data
      • outproc de-marshalls the out data
      • Returns 0 if it succeeds, or the value of enum clnt_stat cast to an integer if it fails. The routine clnt_perrno() is handy for translating failure statuses into messages.
  • Hand rolled example
    • LSHeader.h - Header used by all parts
    • LS.c - The remote procedure that does a directory listing
    • LSServer.c - Server main
    • LSClient.c - Client and client stub
    • LS_xdr.c - Marshalling for all directions and cases
• Marshalling
  • The following XDR Primitive Routines are available:
    • xdr_int()
    • xdr_netobj()
    • xdr_u_long()
    • xdr_enum()
    • xdr_long()
    • xdr_float()
    • xdr_u_int()
    • xdr_bool(
    • xdr_short()
    • xdr_double()
    • xdr_u_short()
    • xdr_wrapstring()
    • xdr_char()
    • xdr_quadruple()
    • xdr_u_char()
    • xdr_void()
    • The nonprimitive xdr_string(), which takes more than two parameters, is called from xdr_wrapstring().
  • Complex data structures
    • User defined routines
      • Must take only two arguments: a pointer to the result and a pointer to the XDR handle.
      • Must return bool_t
      • For the structure

        typedef struct {
            int a;
            short b;
            } simple; 

        this would do the trick

        #include <rpc/rpc.h>
        #include "simple.h"
        
        bool_t xdr_Simple(XDR *xdrsp,simple *simplep) {
        
            if (!xdr_int(xdrsp,&simplep->a))
                return(FALSE);
            if (!xdr_short(xdrsp,&simplep->b))
                return (FALSE);
        
            return (TRUE);
        } 

    • XDR prefabricated routines
      • xdr_array()
      • xdr_bytes()
      • xdr_reference()
      • xdr_vector()
      • xdr_union()
      • xdr_pointer()
      • xdr_string()
      • xdr_opaque()
    • Example, to send a variable-sized array of integers, packaged in a structure containing the array and its length:

      typedef struct {
          int *data;
          int array_length;
      } dynamic_array_type;
                          

      Translate the array with xdr_array():

      bool_t xdr_dynamic_array_type(XDR *xdrsp,dynamic_array_type *arrp) {
      
          return(xdr_array(xdrsp,(caddr_t)&arrp->data,(u_int *)&arrp->array_length,
      MAXLEN,sizeof(int),xdr_int));
      }
                          

      The arguments of xdr_array() are the XDR handle, a pointer to the array, a pointer to the size of the array, the maximum array size, the size of each array element, and a pointer to the XDR routine to translate each array element.
• Defining the protocol
  • The protocol is the stubs and the marshalling functions.
  • The easiest way to generate the protocol is to use a protocol complier such as rpcgen
  • For the protocol you must identify the name of the service procedures, and data types of parameters and return arguments.
  • A protocol compiler reads a definition and automatically generates client and server stubs.
  • rpcgen uses its own language (RPC language or RPCL) which looks very similar to preprocessor directives.
  • rpcgen exists as a standalone executable compiler that reads definition files with a .x prefix.
  • Example
    • Message.c - Simple program to print a message.
    • Now to convert it so that the message is printed on a remote machine.
    • Message.x - Protocol definition for remote service
    • Compiling with rpcgen produces
      • Message.h - Header file for both sides
      • Message_svc.c - Server main and stub; calls the real function to be written.
      • Message_clnt.c - Client stub; takes pointer to real argument and client machine name as arguments.
    • In more complex situations rpcgen might also produce <File>_xdr.c containing any necessary XDR filters.
    • Now write the client and server sides
    • Message_svc_doit.c - Function that prints the message in the server
      • Receives a single pointer to its argument
      • Returns a pointer to the result (static).
      • Name appended with _1 corresponding to version in Message.x
      • Compile

        prompt> gcc Message_svc.c Message_svc_doit.c -o Message_svc 

    • Message_clnt_doit.c - Main routine for client
      • clnt_create is a generic client creation routine.
      • If the printmessage_1 client stub returns NULL then the call failed.
      • Compile

        prompt> gcc Message_clnt.c Message_clnt_doit.c -o Message_clnt 

    • Run the server and the client on different machines