X hits on this document





18 / 21


  • A.D. Birrell and B. J. Nelson

3.6 Other Optimizations

The above discussion shows some optimizations we have adopted: we use subsequent packets for implicit acknowledgment of previous packets, we attempt to minimize the costs of maintaining our connections, we avoid costs of estab- lishing and terminating connections, and we reduce the number of process switches involved in a call. Some other detailed optimizations also have signifi- cant payoff.

When transmitting and receiving RPC packets we bypass the software layers that correspond to the normal layers of a protocol hierarchy. (Actually, we only do so in cases where caller and callee are on the same network--we still use the protocol hierarchy for internetwork routing.) This provides substantial perform- ance gains, but is, in a sense, cheating: it is a successful optimization because only the RPC package uses it. That is, we have modified the network-driver- software to treat RPC packets as a special case; this would not be profitable if there were ten special cases. However, our aims imply that RPC/s a special case: we intend it to become the dominant communication protocol. We believe that the utility of this optimization is not just an artifact of our particular implemen- tation of the layered protocol hierarchy. Rather, it will always be possible for one particular transport level protocol to improve its performance significantly by by-passing the full generality of the lower layers.

There are reasonable optimizations that we do not use: we could refrain from using the internet packet format for local network communication, we could use specialized packet formats for the simple calls, we could implement special purpose network microcode, we could forbid non-RPC communication, or we could save even more process switches by using busy-waits. We have avoided these optimizations because each is in some way inconvenient, and because we believe we have achieved sufficient efficiency for our purposes. Using them would probably have provided an extra factor of two in our performance.

3.7 Security

Our RPC package and protocol include facilities for providing encryption-based

security for calls. These facilities use Grapevine key distribution center) and use the federal data

as an authentication encryption standard

service (or



are given a end-to-end protection tempts at

guarantee of the identity of the callee, and vice versa. We provide full encryption of calls and results. The encryption techniques provide from eavesdropping (and conceal patterns of data), and detect at- modification, replay, or creation of calls. Unfortunately, there is

insufficient space to describe here to support this mechanism. It will

the be

additions and modifications reported in a later paper.





As we have mentioned already, Nelson's thesis included extensive analysis of several RPC protocols and implementations, and included an examination of the contributing factors to the differing performance characteristics. We do not repeat that information here.

We have made the following measurements of use of our RPC package. The measurements were made for remote calls between two Dorados connected by an

ACM Transactions on Computer Systems, Vol. 2, No. 1, February 1984

Document info
Document views83
Page views83
Page last viewedSat Jan 21 02:20:12 UTC 2017