Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!husc6!husc11!martillo
From: martillo@husc11.HARVARD.EDU (Yakim Martillo)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: More questions about TLI
Message-ID: <3536@husc6.harvard.edu>
Date: 13 Dec 87 04:51:26 GMT
References: <8711181601.AA00849@janeb.wisc.edu> <9080@utzoo.UUCP>
Sender: news@husc6.harvard.edu
Reply-To: martillo@husc11.UUCP (Yakim Martillo)
Organization: Harvard Univ. Science Center
Lines: 23

In article <9080@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
:: By creating streams Ritchie basically was expressing the view that
:: the old interface was inadequate for multiplexed data streams and
:: protocol stacks.

:Yes, and you'll notice that the new machinery was a modest extension of
:the old -- basically the ability to stack line disciplines rather than
:just choosing one -- rather than a complete re-invention of the wheel.

:: Now I think streams in Ritchies implementation are okay, I just don't
:: feel they lend themselves to offloading lower protocol levels to a
:: network front-end processor...

:Gee, we're planning to do precisely that using Ritchie streams (not the
:SysV version, which one of my less diplomatic friends calls "sewers")
:and we see no significant problems.

Just out of curiosity, how many protocol layers are being off-loaded
onto your front-end processor or intelligent controller.  If more than
one layer is being off-loaded, the descriptions I have read of streams
seem to imply that streams would have to be implemented on the controller.

Now that might not necessarily be bad, but I would have to think about it.