carlos@DEERVAX.CONCORDIA.CA (Carlos Perez) (12/09/88)
1. Has anybody tried to describe RCP using LOTOS, or try to relate (incorporate) RCP the ISO scheme?. 2. Is it reasonable to use ASN.1 ----- RPC rather than: XDR --- RPC a) what could be the constrains, advantages, disadvantages, etc? b) Will combinig ASN.1 and RPC be a reasonable path to migrate from TCP/IP to ISO? Any Information on the above subjects will be very much appreciated. -_-_-_ Carlos Perez, Systems Programmer Concordia University 1455 de Maisonneuve Blvd. West Montreal, Quebec, H3G 1M8 (514) 848-3107 Internet: carlos@deervax.concordia.ca UUCP : ...watmath!deervax!carlos
mrose@TWG.COM (Marshall Rose) (12/10/88)
There are a number of fundamental differences in the OSI remote operations model from the traditional RPC mechanism used, e.g., by Sun. Although a number of these might be addressed over time (e.g., at the moment all OSI remote operations are based on a connection-oriented transport), it's not clear how much will carry over. I recently re-cast rsh using OSI remote operations, calling the result "osh". Although the ROS-based protocol was fairly simple, implementation of it was very painful in comparison to rsh. A lot of this is due to the amazing similarity between the service raw TCP gives you (a reliable byte stream) and what a UNIX pipe offers. In contrast, OSI remote operations, while connection-oriented, still pass discrete units (i.e., use of ASN.1, et. al., imposes structure). /mtr
carlos@deervax.concordia.ca (Carlos Perez) (12/13/88)
Thank you for your comments [I'm re-posting them to tcp-ip because I am looking for more opinions on this subject]: >>I'm not sure what you mean by RPC, but if you mean "Sun RPC" you can >>just run XDR and RPC atop ISO, given a "transport" implementation for >>it, so I don't see that switching to ASN.1 from XDR helps - in any >>*practical* sense - migration. (It may make some purist happier, but >>they might be even happier if you run some ISO-blessed RPC scheme....) It is my understanding that there are several variations of RPC, thus their interfaces (on the applications side and on the transport side) should be standardized for the sake of interoperability (this is my particular opinion). What I wonder is how these interfaces should be efficiently (openly) defined and if it is worth at all defining them. First, I would like to understand how a standard RPC would look like and then, see how this 'pseudo-standard' would relate to OSI, more for academic purposes than for practical ones (although interoperability is a practical aspect). -_-_-_ Carlos Perez, Systems Programmer Concordia University 1455 de Maisonneuve Blvd. West Montreal, Quebec, H3G 1M8 (514) 848-3107 E-mail: carlos@deervax.concordia.ca
guy@auspex.UUCP (Guy Harris) (12/15/88)
>It is my understanding that there are several variations of RPC, Well, there are several different Remote Procedure Call implementations; I wouldn't necessarily call them "variations", except in the sense that C, Pascal, FORTRAN 77, etc. are "variations" on the idea of a "conventional" programming language. >thus their interfaces (on the applications side and on the transport >side) should be standardized for the sake of interoperability (this is >my particular opinion). Unfortunately, I don't know that this is practical. The designs of the different RPC mechanisms may be sufficiently different that, while you may be able to build an "abstract" interface that sits atop several different RPC mechanisms and offers access to some - not necessarily all - of the features of those RPC mechanisms, I don't know that you can go in and change the interfaces to those mechanisms to all look the same without doing some violence to their designs. The same applies to the bits pushed out over the wire. You'd end up with something that might interoperated with other modified versions, but it wouldn't interoperate with the existing implementations....