Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!sdcsvax!darrell
From: mod-os@sdcsvax.uucp
Newsgroups: mod.os
Subject: Re: Concerning RPC
Message-ID: <2508@sdcsvax.UCSD.EDU>
Date: Fri, 23-Jan-87 14:00:09 EST
Article-I.D.: sdcsvax.2508
Posted: Fri Jan 23 14:00:09 1987
Date-Received: Sat, 24-Jan-87 05:36:47 EST
Sender: darrell@sdcsvax.UCSD.EDU
Lines: 33
Approved: mod-os@sdcsvax.uucp

--

[Oops, sorry Lindsay, I lost your return address.  I gotta remember to use
 's' and not 'w'!  -DL]

In article <2493@sdcsvax.UCSD.EDU> wegrzyn@cdx39.UUCP (Chuck Wegrzyn) writes:
>--
>
>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.
>

This is precisely how the RPC used by the Newcastle Connection works and for
the same reasons - it is grossly inefficient to translate into a standard
form, unless of course your machine just happens to be built to use that
format. The standard ALWAYS seem to be the 68000 style of ordering which
means that anyone with a network of VAXen or PDP-11s is losing in a big way.
As Chuck says, all you need is some standard way of identifying the format
of the rest of the message - the Connection uses 2 bits in the first byte
of the message (though more would be needed if real numbers are to be
supported) and this is sufficient as the types of the RPC parameters are
deduced from the call (N.B. this is obviously not suited to an environment
where arbitrary calls can be made - in that case some kind of parpameter type
encoding is essential, but actual representation manuipulation is still not
needed)

Lindsay


--