Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.dcom.lans
Subject: Re: Streams vs. Sockets
Message-ID: <13748@sun.uucp>
Date: Fri, 20-Feb-87 15:23:02 EST
Article-I.D.: sun.13748
Posted: Fri Feb 20 15:23:02 1987
Date-Received: Sat, 21-Feb-87 07:22:55 EST
References: <605@rna.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 76

>	Streams has added fewer new system calls than sockets.

Yes, but it added tons of new "ioctl" calls and protocol messages,
instead.  Robert Elz, a while ago, refuted the claim that the number
of system calls used by any facility can, in and of itself, be
considered a reasonable figure of merit.

>	Streams corresponds more closely to the ISO protocol layers.

Actually, streams *per se* don't correspond to any protocol layers.
You can implement the layers as streams multiplexor drivers (neither
e.g. TCP nor IP would function very well as streams modules; TCP has
fan-out at the top, and IP has both fan-out at the top and fan-in at
the bottom), but then you can also implement them as different bits
of a 4BSD-style protocol implementation.  They both can match the ISO
protocol layers about equally well.

>	Streams cleans up Unix character handling outside of the networkng
>	realm.

Well, *some* UNIX character handling; dealing with "ioctl"s in a
streams module can be messy.

>	The socket system calls seem to obviously map into the network
>protocol arena. Things like accept, listen, and sendto match my notion
>of how one would program network communications. I just don't know if it
>is similarly easy to create applications using streams.

This brings up one point missed by some "sockets vs. streams"
discussions.  The terms "sockets" and "streams" are used loosely at
times.  Strictly speaking, *neither* sockets *nor* streams are
sufficient to implement networking protocols, in general.  Streams
plus the Transport Layer Interface stream module (plus the "tirdwr"
module, if you want to do something really bizarre and un-UNIX-like
such as doing "read" and "write" rather than "getmsg" and "putmsg" on
descriptors referring to network connections) provides roughly the
same functions as the "socket code" plus the protocol-to-protocol and
protocol-to-network interface code in the 4BSD networking code.

>	The driver-like nature of stream protocol modules makes it easy
>to imagine writing my own streams protocol module.

Be careful here.  I'm not sure the term "driver-like" has any
meaning; the only things that character special file drivers have in
common are that they all have some subset of "open", "close", "read",
"write", and "ioctl" entry points (they may have others, like
"select", "mmap", "reset", etc.).

Even this is only true in a *very* loose sense of streams modules,
which have "open" and "close" routines that are called rather
differently from the way regular character special file drivers'
"open" and "close" routines are called.  They *never* have "read",
"write", nor "ioctl" routines; instead, they may have routines to
receive messages from the modules above or below them, and may have
service procedures to process those messages and send them further
along the stream.  A lot of stuff you'd do in a streams module may be
similar to what you'd do in a conventional driver, but a lot of it is
*very* different.

>I have looked at the Berkeley code for sockets, and I haven't the foggiest
>notion how I would implement a new protocol on top of the sockets mechanism.

Note that you don't generally implement a new protocol on top of
streams; you have to write it to handle the TLI.  There is also a
Link Layer Interface that would roughly correspond to the
protocol-to-network-interface conventions of the 4BSD networking
code, although it's somewhat oriented towards the IEEE 802.2
specification and may or may not be appropriate to other sorts of
networks.  (It also is *not* appropriate for connecting IP to the
link layers it supports, because it requires you to provide the
link-layer address to which a packet is to be sent; IP would prefer a
different interface, which an ARP module would provide, and that ARP
module would talk LLI to the modules below it.)

As such, you'd probably find dealing to those guys about as
complicated as dealing with the 4BSD interfaces.