Re: Streams TCP/IP


Jim Rees (apollo!rees@eddie.mit.edu)
6 Aug 87 15:00:00 GMT


First, this is probably obvious, but "sockets" is an interface, and is best
compared to TLI. Streams is an implementation framework, and has no direct
counterpart in bsd4.3, although it was originally intended as a replacement
for clists and parts of tty.c.

I'm doing a streams implementation here (see my paper in the Phoenix Usenix
Proceedings). It has a TLI interface and a socket interface too. The two
don't always cooperate very well, but it sort of works. 8th edition has
a socket interface too, but I haven't seen it and don't know how it works.

    Guy Harris:
    If you want a STREAMS-based terminal driver, there will be some
    problems with sharing a single pool of buffer resources between the
    networking code and the terminal driver; it makes it more likely that
    networking operations will exhaust these resources.

SysV neatly avoids this problem by not using streams for ttys! There
is a simple priority scheme that tries to avoid this problem, but it
isn't really adequate, especially since the guy (no relation to Guy)
who wrote the tty driver probably didn't talk to the guy who wrote the
IP multiplexor about who was going to allocate how much of which priority.

    The concept is the same in Dennis Ritchie's version and in the S5R3
    version, but some of the details are different. I believe the S5R3
    version is bigger and more complicated.

AT&T added multiplexors (I believe), which are really necessary for
doing protocols. They also added the clone driver, a crock if I've ever
seen one. My version of this uses a special minor device number to
indicate a clone open, and there is no separate clone driver. The sysV
version of streams is indeed bigger and hairier than the v8.

The big potential advantage to streams, from my point of view, is that
it allows you to mix and match protocol modules. Want to run TCP on top
of X.25 transport? Buy a TCP multiplexor module from vendor A, a X.25
network multiplexor from vendor B, and a driver from vendor C. Plug them
all in and it just works. In practice, this requires everyone to use
the same messsages between all their modules, and the interconnectivity
problems make the TCP/IP interoperability problems we are all so painfully
aware of look as easy as tying your shoes in comparison.



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:49 GMT