Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:3039 comp.os.linux.misc:21143 Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!calcite!vjs From: vjs@calcite.rhyolite.com (Vernon Schryver) Subject: re: STREAMS (was I hope this wont ignite ...) Message-ID: <Cu2Ey9.2oM@calcite.rhyolite.com> Organization: Rhyolite Software Date: Fri, 5 Aug 1994 14:01:21 GMT References: <CtMnq1.C8@rex.uokhsc.edu> <31d5ls$8e9@quagga.ru.ac.za> <Cu0w8x.923@seas.ucla.edu> Lines: 56 In article <Cu0w8x.923@seas.ucla.edu> michel@lightning.seas.ucla.edu (Scott Michel) writes: > ... >Most x86 System V's use Lachman's TCP/IP package (I know that SCO >and Interactive did) which is based on top of Streams. But there >are some optimizations that Lachman did to make it faster. And there >are numerous stream buffer parameters that can be tuned. > >Keep in mind that Streams was designed to implement the ISO 8 layer >model, and not the IP 4 layer. It was also designed to allow >flexibility in configuring multiple protocols (like ISO requires). > >Yes, most implementations of sockets on top of streams are hideous, but >it should have been possible to rewrite sockets in terms of the TLI >package (which I don't think is going on). Conceptually sockets and TLI >implement the same thing. The inventor of "streams" is reported to have said something like "shouted, STREAMS is something else." System V STREAMS are a nice porting environment. It's far easier to port STREAMS code from one system to another than BSD protocol switch code , which is justification for DKI/DLPI using STREAMS (but not the reason for using STREAMS; that has to do with politics). STREAMS were emphatically not "designed to implement the ISO 8 layer model" (was that an intentional slip? It's great!) STREAMS were designed for not just network stuff--read the old AT&T "STREAMS Primer." My first experience with STREAMS was writing what I suspect was the first commerical implementation of UNIX STREAMS tty code. It shipped years before either AT&T or Sun shipped theirs, and was completed about the time the Lachman TCP/IP was started. Unfortunately, all of those put and service functions and the generic nature of the stream head and scheduler ensure that STREAMS are never as fast as sockets. I think you can make "page flipping" and "hardware checksumming" work with STREAMS (two primary techniques for fast networking), but I doubt it is possible to make a "squashed STREAMS stack" without doing fatal violence to the fundamental ideas of STREAMS. The fastest TCP/IP implementations are based on sockets, not STREAMS, and they run 2 to 20 times faster (yes, twenty, as in Gbit/sec). It is extremely difficult to implement sockets on top of STREAMS. The years of bad results were not just because they didn't care, but because it is very hard. The models differ in critical respects. It is simply false that "conceptually sockets and TLI implement the same thing" unless you stand so far back that you think COBOL and C are the same. If you want "flexibility in configuring multiple protocols (like ISO requires)", (another neat slip!) then the greatest variety of network protocols is in BSD socket stacks. If you want many choices in TCP or TP4 vendors, STREAMS best, but if you want many different protocols in one system and not just TCP and OSI, it's hard to beat the BSD source. Vernon Schryver vjs@rhyolite.com