Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!sdcsvax!darrell
From: darrell@sdcsvax.UUCP
Newsgroups: mod.os
Subject: Experiences with RPC
Message-ID: <2493@sdcsvax.UCSD.EDU>
Date: Wed, 21-Jan-87 10:15:00 EST
Article-I.D.: sdcsvax.2493
Posted: Wed Jan 21 10:15:00 1987
Date-Received: Wed, 21-Jan-87 21:36:56 EST
Sender: darrell@sdcsvax.UCSD.EDU
Organization: Codex Corp, a division of Motorola; Canton, MA, USA
Lines: 39
Approved: mod-os@sdcsvax.uucp

--

  For those of you using RPC as the "heart" of a distributed system I thought
I would tell you how I changed it to make it more efficient. The single 
largest problem with RPC is not in the concept but in the implementation.
Every known implementation of RPC (to my knowledge) involves translating the
"passed arguments" to a universal format and transmitting the message to the
other side. The otherside of the connection will take the message and 
the arguments into a form suitable for its use. This is pointless if the two
ends could exchange data in the same format.

  The change I made to the implementation is that I prepend the message with
a special identity code (it actually describes the data types present on the
sending machine). The data on the sending machine is left intact - no
translation is made to a universal format. On the receiving side of the 
connection, the identity code is checked - if the sender and receiver formats
are compatible, no conversion takes place and the data is immediately 
available (very little overhead).

  On the other hand, if the formats are incompatible a call is made to a
special conversion program that takes three arguments -

 		1) the identity code of the sender,	
		2) the untranslated data (sent by the sender), and
		3) the argument types expected.

The last bit of data might need some enlightenment - the target procedure
(the remote procedure) knowns what arguments it expects and the type of data
expected. So the remote procedure passes this information to the conversion
routine. The conversion routine will construct a message containing the
translated data. It all works very well.

  In fact, on the system I am building, I save a great deal of processor time
on similar machines. It only incurs a cost on greatly dissimilar machines.

                    Chuck Wegrzyn, not an employee of Codex.

				cdx39!wegrzyn
--