darrell@sdcsvax.UUCP (01/21/87)
--
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
--darrell@sdcsvax.UUCP (01/25/87)
--
In article <2493@sdcsvax.UCSD.EDU> wegrzyn@cdx39.UUCP (Chuck Wegrzyn)
argues for use of machine-specific RPC data formats rather than a
global standard format. This method of course loses badly when the
number of different machine types grows large (since the number of
format conversion routines which must be implemented grows with n^2
instead of 2*n). It also requires that all RPC implementations be
coordinated, since adding a new machine type to the network requires
that ALL machine implementations be changed when a new allowed machine
type is added. As a practical matter, though, he might be right IF the
expected number of different machine types on a network is small and if
there is a central registry of the allowed machine types. My
question: are these two assumptions in fact realistic?
For a proprietary network, they are certainly realistic. A given
vendor typically supports only a very few machine architectures. For a
network standard they are of course unrealistic (e.g. the Internet
community would never want a standard that so limited the set of
allowed machine types). How about for a typical research LAN?
Incidentally, instead of thinking of his type codes as describing the
client's architecture, one might better think of them as describing
which of a small registered set of standard RPC formats this client
is currently using. So one might have 2 RPC encoding standards that
just happened to correspond to VAX and 68020 data formats; when adding
an 80386 to the network, the 386 implementor might choose to do 68020
encoding rather than register his encoding type also.
The real problem with RPC encoding schemes, by the way, is not machine
specificity but language specificity. The preferred data encodings
for applications written in C are far different from those for data
when applications are written in Mesa, as a comparison of Courier with
SUN RPC will surely demonstrate. See Eric Cooper's thesis for more
details.
--darrell@sdcsvax.UUCP (01/26/87)
-- An alternative version of the same strategy is to use machine dependent format for messages local to the machine (perhaps also for messages between the same type of machine), and then to use a canonical format on the network. This requires very little more overhead than the strategy of always using a canonical format, yet avoids the cost of translations in the most important cases. This strategy is actually implemented by the Accent (and now Mach) IPC systems. It is possible because messages contain type information describing the fields in them. Non-local messages are implemented by a server which translates the messages and sends them over the net. At the same time, the anonymous nature of the port abstraction allows applications to remain ignorant of whether the messages they send are local or not. Rob --
darrell@sdcsvax.UUCP (01/26/87)
-- In our formal plans for the NAS supercomputer facility, we intended to use the machine to global translation format, so as to only have to write 2n translators, rather than 2^n; and in the long run we will probably have to do that. In the short run, we've found that machine specific translation was important in our environment for the reason of asymetry of processing power. While it may take the Cray 2 tenths of seconds to translate a file of binary data to or from the 'machine independent' format, it can take a 680xx based workstation many hours to translate the same file. For us, it makes sense to have a 2n translation facility on the Cray 2 consisting of translations to and from the local format of each of the workstations. Since n currently is equal to 1, there is no win or loss as far as the amount of code for translators is concerned and there is a big win as far as the amount of time spent translating. I think this kind of pragmatism is still important in algorithm design. In this case, the small development time required for each new workstation is more than compensated by the large gain in execution time. In fact, a problem which could come to exist in the future is that of two workstations with incompatable format using the supercomputer as a translation service. If the cost to copy the file to the supercomputer in A's local format, have the supercomputer perform the two translations (A->supercomputer) and (supercomputer->B) and then transfer the file to B is lower than the cost of A translating to B and sending, A sending and B translating, etc then users will use that; which leads to the idea of a translation server. --
darrell@sdcsvax.UUCP (01/28/87)
-- > 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. [...] >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. [...] > > 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). I'm not saying this approach is wrong, but one should be aware of the draw- backs. If a new machine type is added to the system, which uses data formats not covered by the protocol you have defined, it is necessary to change the code being executed by every machine in the system. This is no great problem for small (~10 machines) systems, and probably managable for systems with ~100 machines. For a really large system, with thousands or tens of thousands of machines, this kind of change could be a major undertaking. One approach to mitigate this problem is to have the data descriptions in a sufficiently general form that most new machines are covered by them. (I can't tell from the posted description whether this done in the system under discussion.) Given the inventiveness of hardware engineers, I have little confidence that one can come up with a truly universal description. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108 --