Communications

Using An RPC Protocol To Create A Basic File Server

Richard Johnston

Richard Johnston is product development manager for Stony-Brook Technologies—a network systems integrator and reseller. He has worked in the computer communications industry for ten years and has a B.S. in computer science from SUNY Brockport. He can be reached at (516) 567-6060.

The Client-Server Model

Remote Procedure Call (RPC) protocols support network activities by supplying a mechanism to perform local functions on a remote system. An RPC protocol is designed to deliver the parameters from a local system function and return the response back to the originator. The local application is ignorant of whether the function executed directly on the local system or was shared with the remote.

The application in this system is referred to as the client. A dedicated process on the remote system, called the server, performs the function and returns the results. Thus, RPC is a system built upon the Client-Server Model. A client-server system is depicted in Figure 1. Multiple processes can be clients and can make requests for services on the server. Typical client-server systems can be found in network file systems, distributed database systems, electric-mail systems, and even simple applications such as printer spoolers and terminal servers.

The Basic File System

As an example of RPC design, this article will show how to implement an RPC protocol for remote file access. This basic file system (BFS) protocol was developed to emulate the network file systems that are available with LANs but the BFS is specifically designed to operate on a wide area network (WAN). X.25 was selected for the underlying communications medium since it provides most of the services normally found at the transport level (OSI Layer 4) — reliable, in-order delivery with buffer segmentation and support for multiple destinations and sources. Although X.25 was selected, the BFS is not limited to this communications medium, and with modifications to the communications interfaces could be ported to other types of networks.

The BFS is designed to allow multiple client systems to communicate with multiple server systems. A single file server system network would appear as if it was a star topology — the file server in the middle with client systems at the end-points (see Figure 2) . A network with several file servers and client systems would logically appear as a highly meshed network (all of the client systems could have a connection to every file server). The use of X.25 provides a much simpler network topology as shown in Figure 3.

Client System Components

The BFS client system is comprised of two components: the application interface (APL) and the client monitor (CMON). The APL is linked to user-written programs that will use remote files. The CMON operates as an independent process and is responsible for the associated intra-system routing and X.25 communications.

The APL implements a group of routines called the r-functions (Listing 1) . These routines parallel the f-functions of the UNIX Streams interface (e.g. fopen, fclose, etc.). The parameters of the r-functions are the same as the f-functions except for three differences: the rfopen returns a pointer to an RFILE structure instead of a pointer to a FILE structure; the other routines use the RFILE pointer for the rstream parameter; and the rfopen filename parameter specifies both the name of a file server system and the name of the file on the file server.

The filename parameter follows the same format as UUCP file references: <server-name>!<file-name>. The server-name is a logical reference to the desired file server system and is mapped to an X.25 call address by the CMON.

The CMON performs a routing/multiplexing function between the local applications and the networked file servers. When a file is requested the CMON will open an X.25 virtual circuit to the server monitor on the remote file server. Requests from the applications, for specific file servers, are multiplexed onto the appropriate virtual circuit. Likewise, responses from the file servers are routed to the original application. The RPC protocol contains both a client and server identifier which identifies the current session. The CMON performs only a minor translation of the routing information within the RPC protocol header and otherwise does not play an active role in the file access processing.

Server System Components

The server system has a single component, the server monitor (SMON) which is responsible for processing requests from the client systems and executing the r-function operations on the local file system. The SMON decodes the RPC message, formats the proper f-function parameters, and then calls the local f-function routine. Any resulting status (or errno value) is returned as the RPC response message. For read operations, the data will follow the response; for write operations, the data follows the request message.

The SMON is also responsible for the X.25 communications interface. Unlike the CMON which "calls" file ser- vers, the SMON "listens" for client systems attempting to establish an X.25 virtual circuit. The SMON must have a unique "listen" request pending for each client system for which it is configured to process requests. Listing 2 and Listing 3 contain sample client and server configuration files.

The BFS RPC Protocol

The BFS RPC protocol is a custom protocol designed to support the r-functions and is not a general purpose RPC protocol. The RPC protocol uses a common message structure for all commands and responses. Listing 4 contains the declarations of the common message format and the command and response specific portions. The protocol is a synchronous transaction-oriented protocol — a command is sent to the server and the application waits for the response prior to initiating another transaction.

Several implied operations are embedded within the protocol. The RPC_FOPEN_CMD message header is transmitted with the Server Session Identifier (SSID) set to -1, indicating to the server that a server session should be allocated. The server sends the allocated SSID in the RPC_FOPEN_RSP if the fopen function succeeded. A failure implies that no session is needed. Another implied operation occurs on the RPC_FCLOSE_CMD. When a server completes an fclose operation the session is deallocated unconditionally. The life expectancy for a client-server session is equal to the time that a remote file is open.

Each RPC command and response is transmitted in its own X.25 packet. Thus the server or client can wait for any packet and assume it to be an RPC message with a valid header. Data for read and write operations is transmitted as a separate packet (or packets depending on the size of the data field). The client or server will perform an isolated read or write to the virtual circuit to receive the data.

The application programs, client monitor, and server monitor are tied together via the BFS's data structures (see Listing 5) . Each of the three entities is 'attached' by exchanging process/file ids, RPC session ids, or X.25 circuit/line ids with the next entity in the processing chain.

The Client Application

The client application has two functional components: the user supplied program and the r-functions application interface (API). The r-functions application interface is a library of routines which support access to files on remote file servers. The application program can utilize the r-functions just as the f-functions fopen, fclose, fread, fwrite and feof would be used. The r-functions are rfopen, rfclose, rfread, rfwrite, and rfeof. With some exceptions, the parameters to the r-functions are the same as those for the f-functions. Specifically, the rfopen filename parameter's format is different — it uses the UUCP-like format: <server-name>!<file-name>. The result of an rfopen call is a pointer to an RFILE structure. This is a control structure for opened remote files (it should not be directly accessed by the user program). The RFILE pointer is passed to the other routines as an rstream pointer (instead of the stream pointer that the f-functions use).

Error Response

While the individual routines operate like their local counterparts, the user should be aware that the status and errno results do not correspond to local file system conditions — they refer to the remote file system conditions. This is important if an rfopen error indicates that the file does not exist. This behavior may confuse the first-time user who is attempting to access a file on the local system — the file must exist in the proper directory of the remote file system.

Even though brief, the r-functions supply an integral part of the three layers of functionality in the bfs_apl code (see Listing 6) . The r-functions routines validate the incoming parameters for the internal routines.

The next (arpc) layer implements the application's RPC session protocol. The arpc_fopen routine requests that a file be opened on a remote server and the arpc-fclose routine requests that the file be closed. These two routines initiate and terminate the RPC session between an application and a file server. The arpc_read and arpc_write routines are responsible for transferring data between the application's buffers and the fifos to the client monitor.

The afifo management routines perform the actual transfer of commands, responses, and user data. For each process these routines open a unique fifo (named pipe) for reading responses and incoming data flow. The afifo routines also write outgoing commands and data to the system global fifo for the client monitor. The afifos are opened and closed based on a link count. The link count represent the current number of open RFILEs.

A link count of zero indicates that the fifos are not opened and that the afifo_open routine is executed. Close operations decrement the link count and close the afifos when the count becomes zero.

A sample application program is shown in Listing 7. The program is simple but the power to access files from a remote system can be significant when used in distributed applications. The reader should note that the program will operate in the same manner as if the calls were all f-functions referencing files on the local system.

The Client Monitor

A client system can have many applications interacting with many file servers. The client monitor (CMON) facilitates the orderly routing of data between the file server systems and the client system. The CMON is launched during system startup and executes as a background task. During initialization it creates the global client monitor fifo and opens the X.25 communications ports. The CMON has three processing layers: the fifo management layer, the session routing layer, and the X.25 communications interface (see Listing 8) .

The CMON's three layers communicate with each other via references to the internal control block tables: fifo control blocks (c_fcb), session control blocks (c_scb), and line control blocks (c_lcb). Each table contains indexes to the next higher or lower level in the processing chain. The c_fcb and c_lcb contain link counts for determining if a fifo or line is active and will execute the open and close functions automatically.

Data from applications is received by the fifo management routine (cfifo_read). The main processing loop assumes that an RPC command will be received first and locates the session in the c_scb table via the process and file identifiers (pid and fid) in the RPC header. Note that the client session identifier (csid) is an index into the c_scb table. The server session identifier (ssid) is a similar index. A client-server session is identified by matching csid and ssid pairs.

To route the RPC command/data to the server system, the CMON uses the line identifier (lid) from the c_scb entry as an index into the c_lcb table. The c_lcb entry contains the X.25 port number and circuit number (cid) that is allocated for connecting to the server. If the link count is zero then the client is not connected to the server and an X.25 Call Request/Confirm Operation is performed, allocating a cid. The entries in the c_lcb contain the appropriate X.25 information for making the call to the server.

Responses from the server are processed in reverse. The cid/lid is known by the incoming X.25 event and the session is located in the c_scb via the csid contained in the RPC response header. The CMON then uses the csid to index into the c_scb and extracts the pid/fid representing the local applications file reference. This pid is used to find the application's c_fcb entry for the write fifo. The response is adjusted and sent on the correct fifo. Whether the RPC operation succeeds is an issue only to routing and communications layers - not to the CMON.

The CMON uses and contains specific support for the Eicon Technologies' X.25 Toolkit and HSI/PC communication controller. For example, the CMON will allocate an X.25 buffer (on-board memory) and will read or write the data from the X.25 communications interface directly into the fifo, saving a copy operation and reducing local system operating requirements.

The CMON operates in a synchronous processing loop (it is single transaction oriented). The CMON will receive a command from an application and will transmit the command to the server. It will then wait for a response (this could take some time), and send the response back to the application. The CMON will ignore (temporarily) any other pending requests from other applications. Although the CMON's tables and the RPC protocol structure will support asynchronous processing (i.e. multiple commands/responses), the synchronous design of the CMON demonstrates the type of multiplexing that is necessary to support a client-server system.

The Server System

The server system contains the server monitor (SMON). This background task is launched at system startup and during initialization opens the X.25 communications port and posts a listen request for each Client System configured. (A 'listen' request is the X.25 toolkit's counterpart to the call request function. A listen request completes when a call request with matching parameters is received.) The SMON has a line control block table (s_lcb) for keeping track of the client system circuits and a session control block table (s_scb) for keeping track of the client-server sessions and file system access.

The SMON doesn't depend on any applications above it, and as a result is not noticeable in a system. The SMON has three layers of functionality: the X.25 interface, the RPC protocol layer, and the file system interface (see Listing 9 for source code). The SMON continuously waits for either a completion of any listen request (i.e., new client systems making contact) or received data (i.e., RPC commands from client systems). The SMON will accept any connection request from a client system and will maintain the X.25 circuit until it is cleared by the client. Data received in the main processing loop is interpreted as an RPC command and is passed to the srpc routines.

The srpc routines are the mates of the arpc routines. These routines process the decoded RPC header and perform specific RPC functions. The SMON follows the CMON design where a RPC_FOPEN_CMD initiates a new RPC session and the RPC_FCLOSE_RSP closes the session. The srpc routines identify the sessions by extracting the csid and ssid from the RPC header. On RPC_FOPEN_CMD commands the ssid is -1 and is replaced with the allocated session identifier (e.g. the s_scb index) within the RPC_FOPEN_RSP response message.

Future Directions

These enhancements are critical if the BFS is to be a file access method:

Conclusion

The future of RPC protocols is expanding as the fourth-wave of computing emerges. Network-based applications or "Groupware" products will enhance the productivity of the computing community, increase the types of applications available, change how existing applications operate, and allow users to economically upgrade computing power where it is needed. The power of RPC protocols is not limited to software gurus or manufacturers — it is now being delivered to the users themselves. Products such as Netwise's RPC Tool will allow individual programmers to develop custom client-server applications that execute on UNIX, MS-DOS, and other operating systems.

References

Anderson, Bart & Costales, Bryon & Henderson, Harry. UNIX Communications, Indiana, Howard W. Sams & Company, 1987.

Fritz, T. E. & Hefnet, J. E. & Raleigh. "A Network of Computers Running the Unix System," AT&T Bell Laboratories Technical Journal Vol. 63, No. 8, October 1984, reprinted in AT&T Unix System Readings and Applications, Vol. II, New Jesey, Prentice-Hall, 1987.

Stallings, William. Handbook of Computer Communications Standards, Volume 1, "The Open Systems Interconnection (OSI) Model and OSI-Related Standards." New York, Macmillan, 1987.

Stevens, W. Richard. Unix Network Programming, Prentice-Hall Software Series, New Jersey, Prentice-Hall, 1990.

Tanenbaum, Andrew S. Computer Networks, Second Edition, New Jersey, Prentice-Hall, 1988.

Sidebar: Network Standards

Sidebar: OSI Reference Model Layer Functions