Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!mit-eddie!apollo!rees From: rees@apollo.uucp (Jim Rees) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <3681fb61.b8ab@apollo.uucp> Date: Thu, 6-Aug-87 11:00:00 EDT Article-I.D.: apollo.3681fb61.b8ab Posted: Thu Aug 6 11:00:00 1987 Date-Received: Sat, 8-Aug-87 11:17:22 EDT References: <649@houxa.UUCP> <278@unixprt.UUCP> <561@applix.UUCP> <24336@sun.uucp> <281@rruxa.UUCP> Organization: Apollo Computer, Chelmsford, Mass. Lines: 40 Xref: mnetor comp.dcom.lans:714 comp.protocols.tcp-ip:839 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.