Streams vs what?

[Guy Harris]

> But while the changes to Streams to support out-of-band and urgent data were
> minimal, changing BSD sockets to support OSI or some other layered protocol
> would involve much more work. And again, without a framework like
> Streams, it would have to be done all over again for the next great
> Protocol to be.

Well, here's the word on how much work it actually took to put OSI under
sockets, straight from the horse's mouth (well, actually, straight from
Keith Sklower's keyboard)

   Changes in the Socket Interface to accomodate OSI protocols.

        The OSI transport protocols make use of  some  features
   that the 4.3BSD version of sockets didn't handle very grace-
   fully.  However, by making rather modest  changes,  we  have
   been  able  to  incorporate an implementation of OSI TP with
   great success.

        The main change has  been  to  the  sendmsg()/recvmsg()
   system calls.  Here we added three new entries to the msghdr
   structure: a returned value for  flags,  and  a  buffer  and
   length for ancillary data.

        The  motivation  for  a  returned,   in   addition   to
   requested,  flags fields, is to unambigously convey ``end of
   record''.  This also allows one to  return  expedited  data,
   and  mark it as such, without the expense of a separate sys-
   tem call enquiring (are we ``ATMARK''?), or  the  scheduling
   of an interrupt.

        The motivation for the ancillary data was to provide  a
   separate  place  for  user  connect/confirm/disconnect  data
   (which is not regarded as a part of the actual data stream),
   data  stream  type  for XNS, ip options for IP, or any other
   protocol features that previously would have required  look-
   ing at packet headers.

        Another common misconception is that sockets in and  of
   themselves do not allow confirmation or rejection of connec-
   tion requests.  Perhaps the accept() system  call  has  been
   misnamed  all  along;  it  really  should  have  been called
   dequeue_next_connect_request().

        For the ISO case, accept() returns a file descriptor on
   which  one  can  query for user connect data, and explicitly
   reject the connection request either  by  closing  the  file
   descriptor,  or sending disconnect data.  One can explicitly
   confirm the connection request by sending user confirm data,
   or  implicitly  confirm  the  connection by doing the normal
   operations of read and write.

        Another change to the socket layer has been to  include
   a  length  field  in  all  sockaddrs.  Although we have been
   warned that a transport address may run up to 84  bytes  (64
   bytes  of  TSEL,  20 bytes of NSAP), it seems regretable and
   unnecessary to have fixed size address buffers for the worst
   case.

        A socket interface to Datakit would also  make  use  of
   this  feature.   We  have  revised the kernel routing lookup
   software  to  deal  with  variable  length  addresses   with
   hierarchical defaults in a uniform way.

This doesn't seem to be a huge change; it may well be comparable in size
to the changes to streams and to TLI (remember, in S5 at least, the
equivalent to sockets isn't streams, it's streams plus TLI) to support
out-of-band and urgent data.  (The item about the routing lookup
software doesn't apply, since S5 doesn't include general routing support
code as 4.x BSD does, leaving the routing support up to the individual
protocol implementations, although network-layer protocol implementors
could agree to share a set of common code that they add to S5.)

It certainly didn't involve adding any new system calls.  Several of the
changes generalize the sockets mechanism in ways that enhance its
support of several different protocols, just as the changes to
streams+TLI to support out-of-band data generalize streams (and, I hope,
TLI) to enhance its support of several different protocols.  I certainly
don't see any indication that the next protocol along the line will
require any more or less extensive changes to sockets than to
streams+TLI.  (If you leave TLI out, it may become trivially true of
streams alone - but then, you can implement new protocols in
BSD-flavored systems without putting them atop sockets, too.)