Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!ucsd!ucbvax!BROWNVM.BROWN.EDU!JAZBO
From: JAZBO@BROWNVM.BROWN.EDU ("James H. Coombs")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Are sockets the wave of the future?
Message-ID: <9008242107.AA19843@ucbvax.Berkeley.EDU>
Date: 24 Aug 90 19:12:12 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 55


>
>Date:         Fri, 24 Aug 90 01:54:52 GMT
>From:         Tom Reingold <cs!samadams.princeton.edu@PRINCETON.EDU>
>
>At my job, we are about to write some applications for running over
>TCP/IP on Unix hosts.  We would like to think ahead with portability in
>mind.

>3. Are all TCP/IP suites done with sockets nowadays?

Definitely not.

>5. Currently, our hosts run System V release 3.[23] and have both
>libraries.  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:

1. The library is available through ftp.
2. You can work at a high level with minimal concern for networking details.
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).
4. Various transport mechanisms may be used under the RPC interface.  The
   package supports sockets and raw buffers.  Future versions will probably
   use TIL(?), which in turn provides some independence from lower levels.
5. The application-specific protocol can be developed relatively invisibly
   by defining c-type structures.  The programmer does not have to think
   about sending a long, using htonl(), etc.  If it is convenient to change
   a long to a short, then rebuilding the application should update both the
   client and the server (assuming the proper make dependencies).  One is
   less likely to try to send a long to a process that is waiting for a short.

On the down side:

1. It is a little trickier to do something like have the server fork
   immediately after accepting a connection.
2. There may remain a need to drop down to the transport layer for such
   details as keepalive options on sockets.

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).

--Jim

Dr. James H. Coombs
Chief Architect
Institute for Research in Information and Scholarship (IRIS)
Brown University, Box 1946
Providence, RI 02912
jazbo@brownvm.bitnet
Acknowledge-To: <JAZBO@BROWNVM>