Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Are sockets the wave of the future? Message-ID: Date: 27 Aug 90 20:30:24 GMT References: <9008242107.AA19843@ucbvax.Berkeley.EDU> <1990Aug27.111656.1@amazon.llnl.gov> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 39 Your complaint about SunNet has nothing to do with the portability or lack thereof of RPC. RPC -- whatever Sun may say -- is not an alternative to streams or sockets. Streams and sockets are ways of accessing the IP or TCP level directly. RPC imposes on top of that a data encoding standard and some other communications standards. It's roughly comparable to ASN.1 plus a bit of mechanism to identify applications. I certainly agree with your complaint that Sun should have implemented host monitoring using SNMP, but not because of any unportability in RPC. RPC is at least as portable as ASN.1. Indeed at the time the SNMP standard was issued, Sun had already posted RPC to the net, and everybody had to write ASN.1 parsers in order to implement SNMP. So SNMP would have been more portable if it had been written using RPC. But it wasn't. So the problem with rolling your own network monitoring protocol on top of RPC isn't that RPC is unportable, but that you're rolling your own network monitoring protocol when there already exists a standard one. At any rate, it seems clear that the advice to use RPC is for people who are writing their own applications. Nobody claims that RPC is going to replace raw TCP for implementing FTP. Give me a break. The claim is that if you want to write a high-level application, RPC handles issues of data portability between different architectures (byte order, floating point format, etc.), and will allow you to move between TCP/IP and ISO when RPC is implemented over ISO. That still seems reasonable advice. However RPC is not unique in this. There are competing mechanisms at the same. Since one of the primary goals of the industry groups is to make sure that Sun doesn't ever repeat their success with NFS, you can be sure hell will freeze over before OSF or anyone else adopts RPC. But at the moment there is specific alternative with overwhelming support. Since NFS is so widely available, and having NFS means that you have to have RPC, that seems to guarantee wide support for RPC. Thus until the industry converges on a single alternative, RPC seems a reasonable choice. Of course this doesn't address the original question, which is whether to use sockets or streams to access TCP. I'm going to do that in a separate response.