[ On Friday, May 7, 1999 at 22:21:57 (-0700), Erik E. Fair wrote: ]
> Subject: Re: uvm and/vs splice() (was: re: Ongoing projects)
>
> Well, just to be heretical for a second, we could implement ritchie streams
> (as opposed to that System V TLI/SEWERS nonsense) and push protocol modules
> on descriptors, and then connect them with splice()...

Don't confuse "streams" with some of the things some companies have
written as streams modules and interfaces.

Ritchie's original streams have some significant and serious problems
that are (mostly) solved in the SysV implementation -- something to do
with multiplexing, if I remember correctly (described in the original
paper that was published in BSTJ, and my copy is still buried in the
garage).  The SysV solution to those problems seemed practical and
elegant enough at the time, but of course if you're not going to follow
the SysV DDI/DKI specification then there's no need to follow the
STREAMS API either, though I don't remember it as all that different
from Ritchie's original API.  The basic idea is what's important.

SysV's TLI stuff is merely a user-space library and a bunch of streams
modules, and if you don't need a transport-independent networking API
then you don't need TLI or XTI or any look-alike.

The important thing to remember is that there are at least three or four
implementations of TCP/IP for TLI, most of which are very poor
performers, even if they might have "looked good" on the surface.  As I
understand it the Mentat, Inc. implementation, used in early SunOS-5, is
one of the best, and that the USL, and Lachman, and Wollongong(sp?)
implementations are the sucky ones.  Of course all of this stuff is 6-8
years old.

Of course if you're going to put something like streams in the kernel it
might make sense to migrate a number of subsystems into that framework,
since it's that basic framework which makes it not only possible but
*easy* to hook various unrelated things together in new and interesting
ways.  Even though everyone is doing TCP/IP these days, it still might
be handy to have a transport-independent sub-frame on which to rest it
all upon.  Naturally if you go that far then it might only make sense to
support an XTI interface too, even if only to be fully compatible with
UNIX 98 Networking Services Issue 5. 

In fact Sun has shown that it's possible to have a "native" socket
implementation and a TLI implementation both talking to the tcpmux
module at the same time.  If I remember correctly sun's zero-copy TCP
implementation is also in this same framework.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>