Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:3069 comp.os.linux.misc:21255
Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!trib.apple.com!amd!decwrl!netcomsv!calcite!vjs
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Subject: Re: STREAMS (was I hope this wont ignite ...)
Message-ID: <Cu4oAu.CJ3@calcite.rhyolite.com>
Organization: Rhyolite Software
Date: Sat, 6 Aug 1994 19:18:30 GMT
References: <Cu0w8x.923@seas.ucla.edu> <Cu2Ey9.2oM@calcite.rhyolite.com> <MICHEL.94Aug5120311@blizzard.seas.ucla.edu>
Lines: 111
In article <MICHEL.94Aug5120311@blizzard.seas.ucla.edu> scottm@intime.com writes:
>
>V> System V STREAMS are a nice porting environment. It's far
>V> easier to port STREAMS code from one system to another than BSD
>V> protocol switch code , which is justification for DKI/DLPI
>V> using STREAMS ...
>I own one of the original STREAMS manuals from AT&T, and had to to
>battle with the DataKit (a fiber interface to a network processor
>who's name escapes me.) Sure, STREAMS is a generic pathway for
>seperating components in a device driver, but then again, the
>conversation was about networking, wasn't it? Pedantic displays of
>knowledge ("I've been doing programming for 25 years") don't help the
>discussion much.
It does help a little to separate the pronouncements of those who know
what they know about STREAMS by reading "Comm.Week" from those who have
seen some System V STREAMS kernel code.
The thesis of the person who started this sub-thread seemed to me to be
"STREAMS is a fine scheme for fast networking code and may be important
before long, especially with the work of Mentat."
I find that thesis unlikely, to say the least, and I base my prejudice
on my professional experience with both STREAMS and sockets.
>V> Unfortunately, all of those put and service functions and the
>V> generic nature of the stream head and scheduler ensure that
>V> STREAMS are never as fast as sockets. I think you can make
>V> "page flipping" and "hardware checksumming" work with STREAMS
>V> (two primary techniques for fast networking), but I doubt it is
>V> possible to make a "squashed STREAMS stack" without doing fatal
>V> violence to the fundamental ideas of STREAMS. The fastest
>V> TCP/IP implementations are based on sockets, not STREAMS, and
>V> they run 2 to 20 times faster (yes, twenty, as in Gbit/sec).
>
>Ever notice that everything has to be designed and implemented twice?
>I think the same is true of STREAMS, it needs to be reimplemented now
>that we know the mistakes and things we'd like to do better.
Those put and service functions are no longer implementation issues.
Once you chisel everything into the stone of DKI and DLPI, you don't
so much implementation freedom.
Again, I don't see how you can build DLPI "squashed stacks". I do not
see how you can build a DLPI compliant TCP/IP implementation that comes
within a factor 20 of the number of instructions Van Jacobson has reported
for his code, counting all instructions from user process to the wire.
I would be very impressed with a DLPI compliant implementation of
TCP/IP/Ethernet that took fewer than 8,000 instructions to cause a 10
bytes TCP segment to be transmitted. (That's closer to 100X than 20X,
but never mind.)
While you can page flip by building new STREAMS buffer types, how do
you do checksumming in the user-copy code called by the STREAM head?
if you find a checksum error, you'll have to somehow tell TCP to ask
for a retransmission. There are obvious ways to handle even this problem,
but I doubt they'd be SVR4 standards compliant.
>V> It is extremely difficult to implement sockets on top of
>V> STREAMS. The years of bad results were not just because they
>V> didn't care, but because it is very hard. The models differ in
>V> critical respects. It is simply false that "conceptually
>V> sockets and TLI implement the same thing" unless you stand so
>V> far back that you think COBOL and C are the same.
>
>I dunno about that statement. If you're talking about actual semantics
>and syntax, then the COBOL vs. C issue is valid. If you're talking
>about the process modelled, then there are some striking
>similarities. For example, given that we want to set up a simple
>connection oriented IPC:
>
>sockets:
>server calls: socket -> bind -> listen -> accept -> read -> write ...
>client calls: socket -> connect -> write -> read ...
>
>TLI:
>server calls: t_open -> t_bind -> t_alloc -> t_listen -> t_accept ->
> t_rcv -> t_snd ...
>client calls: t_open -> t_bind -> t_alloc -> t_connect -> t_snd -> t_rcv ...
>
>Structurally, they model the same thing, the names of the calls are
>different.
That's exactly on target. White board, manager meeting, consortium
conference room designs like that prove that there's no significant
programming work to emulate sockets over TLI. When you get up close
enough to not be blurring C and COBOL (there's no program you can write
in one that you can't write in the other), you find minor details like
keeping a lot of the TLI network state in user space made emulating
sockets over TLI not quite trivial. (Think about what happens when you
fork() and exec() and expect both parent and child to have the same
network file descriptors in the same state.) Other minor details did
concern the committee nature of the designs, such as the lack of consensus
on how to represent IP addresses.
It is far easier to emulate TLI over sockets. It requires only a few
man-months to get SVR4 XTI and the SVR4 user code working over 4.3BSD-reno
TCP/IP. That effort is sufficient to also glue hooks into most of your
socket-style interface drivers to send non-IP packets up DLPI compliant
SVR4 STREAMS stacks. (I'm talking about what was done a couple of years
ago at one of the big 5 UNIX vendors.) Of course, it is not DLPI
compliant for TCP/IP.
(I've tried to be careful about using TLI to refer only to the SVR3.2
stuff.)
Vernon Schryver vjs@rhyolite.com