Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Are sockets the wave of the future? Message-ID: <11730:Aug2503:46:4590@kramden.acf.nyu.edu> Date: 25 Aug 90 03:46:45 GMT References: <9008242107.AA19843@ucbvax.Berkeley.EDU> Organization: IR Lines: 71 In article <9008242107.AA19843@ucbvax.Berkeley.EDU> JAZBO@BROWNVM.BROWN.EDU ("James H. Coombs") writes: > > From: Tom Reingold [ portability: sockets vs. streams ] > > Which is "the way" to go? > Sun now states that no new applications should be developed at the socket > level. They recommend 1) RPC or 2) TIL(?--which starts with SunOS 4.1). RPC > has several advantages: For comparison, here's how my auth package measures up to your criteria. > 1. The library is available through ftp. The same is true of auth. /comp.sources.unix/volume22/auth/* on uunet. > 2. You can work at a high level with minimal concern for networking details. The same is true of auth. auth-util/* are sample applications, including (for example) a shell script adaptation of trivial inews. 76 lines, with comments and better error checking than the original. > 3. Client and server can be bound together into a single process without > modifying the code (although you may want to eliminate the code that > would normally establish a connection). auth is based on a client-server model, not a single-process RPC model, so this does not apply. See below. > 4. Various transport mechanisms may be used under the RPC interface. The same is true of auth. The c.s.unix version of auth is based on sockets; the same interface can be set up over practically any two-way communications medium. You don't have to change code to use this. Note that auth uses RFC 931 for authentication; it eliminates mail and news forgery above TCP. auth-util includes a small set of wrappers that you can put around sendmail to achieve this extra security with no effort. > 5. The application-specific protocol can be developed relatively invisibly > by defining c-type structures. The auth programmer doesn't have to bother thinking about a protocol. He need only use the software techniques he's comfortable with for writing data to a file. The same techniques work for transferring data over the network through auth. > On the down side: > 1. It is a little trickier to do something like have the server fork > immediately after accepting a connection. This is an advantage of auth, again reflecting a difference in philosophy. auth was designed for a client-server model, so it doesn't naturally adapt to single procedures run on different machines as part of the same program. RPC was designed for remote procedure call, so it doesn't naturally adapt to the (perhaps more common) client-server case. > 2. There may remain a need to drop down to the transport layer for such > details as keepalive options on sockets. The same is true for auth. This is only a reflection of the ``problem'' that a high-level interface cannot anticipate all the possible extensions of the low-level interface it's based on. > Whatever you decide, you should take a good look at RPC. I haven't been fully > converted yet, but I will certainly be influenced by the library even if I > decide to stay with sockets (and my object-oriented server building block). Whatever you decide, you should take a good look at auth. I have been fully converted, as I wrote the package. If you want to develop client-server applications and be sure that they'll work on the networks of the UNIX of the future, auth is the way to go. ---Dan