Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!im4u!ut-sally!ico!violet!dougm
From: dougm@violet.UUCP
Newsgroups: comp.dcom.lans
Subject: Re: Streams vs. Sockets
Message-ID: <688@ico.UUCP>
Date: Thu, 26-Feb-87 21:19:50 EST
Article-I.D.: ico.688
Posted: Thu Feb 26 21:19:50 1987
Date-Received: Sun, 1-Mar-87 09:07:36 EST
References: <605@rna.UUCP> <13748@sun.uucp>
Sender: news@ico.UUCP
Reply-To: dougm@ico.ISC.COM (Doug McCallum)
Distribution: world
Organization: Interactive Systems Corp.
Lines: 55

In article <13748@sun.uucp> guy@sun.UUCP (Guy Harris) writes:

To build on what Guy has stated:

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

To state this a little differently, both streams and sockets (actually
the proto switch code under sockets) provide a "framework" onto which
protocol implementations can be built.  Streams are somewhat more
generalized than sockets, allowing different drivers, modules, etc. to
be linked and stacked in different ways.

As was mentioned, TLI corresponds more closely to what sockets are.
TLI offers some additional flexibility in terms of programmer
interface than sockets, but at the loss of complete generality.  The
TLI streams descriptor cannot be used as an ordinary file descriptor
unless the TLI module is popped and the read/write module pushed on.
You then lose the ability to use TLI operations.

>
>Be careful here.  I'm not sure the term "driver-like" has any
>meaning; the only things that character special file drivers have in
...
>Even this is only true in a *very* loose sense of streams modules,
>which have "open" and "close" routines that are called rather
...
>similar to what you'd do in a conventional driver, but a lot of it is
>*very* different.
>

Streams drivers definitely have some different characteristics from
traditional style drivers.  Some examples that might illustrate how
different are:

    getmsg: there is no read hook into a streams driver.  If you
	    happen to use "read", it turns into a getmsg.  Where
	    getmsg is different is in the fact that it "passively"
	    waits for a message to appear at the stream head.  It
	    doesn't ever give the driver an indication that the user
	    is waiting.
    sleep:  in general, you NEVER sleep on an event in a streams
	    driver or module.  Modules run out of the streams
	    scheduler and a sleep might put the wrong process to sleep
	    (such as the process scheduler or other critical process).

To state it another way, "arrival events" trigger actions and the
components of a "stream" are all scheduled independently.
Doug McCallum		Interactive Systems Corp.
dougm@ico.isc.com	{cbosgd, hao, nbires}!ico!dougm