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.