Subject: Re: multiple consumers of msmux
To: Erik E. Fair <fair@clock.org>
From: Greg A. Woods <woods@weird.com>
List: tech-misc
Date: 05/20/2003 15:53:11
[ On Tuesday, May 20, 2003 at 12:24:39 (-0700), Erik E. Fair wrote: ]
> Subject: Re: multiple consumers of msmux 
>
> Dennis Ritchie gave the UNIX world "streams" as the answer to the
> question, "why are tty line disciplines so hard to write?" It is
> very, very important to distinguish that from its later perversion
> into System V's networking API to compete against BSD sockets.

It's also very important to note that many serious limitations in the
original Ritchie implementation of streams, some of which were finally
fixed in the UNIX System V Release 4 implementation.  :-)

In particular are the issues in the original implementation which would
need to be overcome to support your deisred application:

   Although the new organization performs well, it has several peculiarities    
   and limitations. Some of them seem inherent, some are fixable, and some      
   are the subject of current work.                                             

[[ .... ]]

   Streams are linear connections; by themselves, they support no notion of     
   multiplexing, fan-in or fan-out.

There is multiplexing support in the later implementations.

There are also serious issues in the original design with flow control,
accounting & scheduling, error handling, and so on.  Some of these
problems are also solved in the later implemenations, but perhaps not all.

A full TCP/IP networking suite would be impossible to do with the
original 8th Edition "streams".

With correctness, completeness, and robustness comes complexity....


See also:

	<URL:http://cm.bell-labs.com/cm/cs/who/dmr/spe.ps>
	<URL:http://cm.bell-labs.com/cm/cs/who/dmr/spe.pdf>

and if I may:

	<URL:http://mail-index.netbsd.org/tech-kern/1995/09/13/0000.html>

> Now, as much as I'd like to see dmr's streams in NetBSD, that is
> not what I am suggesting now - that's more work than is necessary
> for this, I believe. What I think we need in wscons is an interface
> or tap like bpf(4) so that a program could snoop the keypresses
> and do things. Your wsfilter notion sounds interesting...

How about importing FreeBSD's snp(4) driver?

For a slightly different look at the bigger picture there's also
FreeBSD's netgraph....

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>