mod-os@sdcsvax.uucp (01/23/87)
-- [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 --
darrell@sdcsvax.UUCP (02/12/87)
In article <2508@sdcsvax.UCSD.EDU> mod-os@sdcsvax.uucp writes: >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 As does the RPC protocol Apollo just announced as part of the Network Computing System product. We ended up reserving 32 bits in the packet header to contain a scalar data type description. The current set of scalars we deal with are integers, characters, and floating point numbers. Our current encoding of representation used is fairly generous: 4 bits to encode the type of integer representation (only 2 possibilities actually used now), 4 bit for characters (only 2 possibilities used), and 8 bits for floating point (only 4 possibilities used). The implicit assumptions (worth noting) of anyone adopting this "receiver makes it right" approach are (1) the set of scalar data types is not getting much larger, and (2) the set of representation used for a single scalar data type is not getting much larger. The latter seems like quite a safe assumption. (There seems to be convergence: e.g. IEEE floating point and no one talks much about ones complement integer representation any more.) The former assumption is a bit riskier: A 16-bit character scalar data type seems likely (e.g. for Kanji), but hopefully the world won't make the same mistake it did with 8-bit characters of defining multiple representations. Even so, we have 16 bits left in our descriptor to add information about a few more scalar data types. Note that our interface compiler produces stub code that handles the data representation conversion. As an optimization (time over space), the stub actually contains two data unmarshalling paths: one that runs in case the sender and receiver have identical representations for all scalars, and another in case there are any differences. Another interesting point that people often don't think about in this area is alignment. One could argue that since sender's alignment rules can differ from the receiver's and that since the sender wants to use his alignment when marshalling the data, the alignment rule should be captured in the data representation description too. Rather than doing this, we decided to adopt "natural alignment" -- scalars of size N bytes are aligned on N byte boundaries in memory. This yields a little bit of wasted space -- a 68000 will use 8 bytes to store a 16 bit integer followed by a 32 bit integer -- but the receiver who has higher alignment requirements than the sender will be much happier. (In some cases, it might allow the server-side stub to save a data copy by pushing a pointer to the arrived packet on the stack when calling the real procedure, rather than unmarshalling the data into a local variable first.) Rearranging the order in which the data is marshalled can also save some of the wasted space. -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {wanginst,yale,mit-eddie}!apollo!mishkin ------- -- Darrell Long Department of Computer Science & Engineers, UC San Diego, La Jolla CA 92109 ARPA: Darrell@Beowulf.UCSD.EDU UUCP: darrell@sdcsvax.uucp Operating Systems submissions to: mod-os@sdcsvax.uucp