From: Alexander G Balikov (alexgb_at_u.washington.edu)
Date: Mon Feb 02 2004 - 16:41:45 PST
In this paper the authors present the design of the RPC infrastructure for the Xerox's Messa development environment.
The design is very similar to the contemporary COM infrastructure on Windows platforms, but seems novel for its time 20 years ago. The goal of the authors is to provide simple for usage, convenient and performant infrastructure for performing RPC - essentially similar to local procedure calls.
The RP call consists of 5 parts user -> client RPC stub -> name resolution database + network -> serverRPC stub -> server instance. The stubs are generated by a utility called Lupine from interfaces written in Mesa language. The binding of the client to a server instance is done by using a distributed registration interface containing information about the server instances, their network locations, and the interfaces they implement. The database provides a level of inderection allowing dinamic binding - the client can bind either to a specific instance implementing an interface (providing instance name and interface name) or to any instance providing just an interface name (in this case the database will bind to the closes instance implementing the requested interface).
The paper describes in detail the communication between the client and the server for an RPC call. Impressing is the simplicity of the design - the connection state is minimal - just a process and request IDs. By using unique IDs the authors implement restart discovery and consistency of the communication. For performance reasons the authors employ custom packet based communication protocol avoiding additional acknoledgement packets - a new message serves also as an acknowledgement for the previous one. The performs pings to ensure that the server is alive during long calls.
Even though the authors use custom communication protocol, they mention that it is possible to use csome common ones as well.
The Grapevine database used for name resolution actually has been specifically designed to server such purposes. Being a distributed databes it also provides services for update propagation. Another service it provides is authentication.
The authors use this database to perform authenticaiton for RPC as well. Since interfaces are published by registering them in the database, the authors can reuse the database security to control who can publish interfaces and who can access them.
The described RPC package provides error(exception) propagation back to the client. The authors described the exception propagation in the context of local exception propagation. Local exceptions though allow execution to be restarted from the point where the exception occurred - it was not cler from the paper if the described RPC implementation allowed this. If it did, then most probably the underlying RPC infrastructure could not be reused by other high level programming environments (providing language independent communication).
The paper mentions a server process pool for performance reasons. The infrastructure tries to reuse the previous used process. This is another optimization for chatty RPC communication.
The paper was very interesting to ready. It was striking the similarity with the contemporary RPC infrastructure. Even though the Grapevine database has it own problems as described in the other paper, I think in an intranet, the described infrastructure provides excellent environment for seamless distributed computing.
This archive was generated by hypermail 2.1.6 : Mon Feb 02 2004 - 16:41:45 PST