Newsgroups: comp.protocols.tcp-ip
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Sockets vs streams.  An attempt to answer the original question
Message-ID: <1990Aug28.162400.17811@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <9008242107.AA19843@ucbvax.Berkeley.EDU> <PAGE.90Aug26161024@swap.Eng.Sun.COM> <1990Aug27.111656.1@amazon.llnl.gov> <Aug.27.17.09.46.1990.14447@athos.rutgers.edu>
Date: Tue, 28 Aug 90 16:24:00 GMT

In article <Aug.27.17.09.46.1990.14447@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
>...  (By the way, the original
>ATT claim was that sockets were a terrible wart on Unix, and streams
>were "clean".  I'm not sure what -- if anything -- that meant.  It
>seems to me that sockets makes network I/O look a lot more like normal
>file I/O than streams do.)

It is important to distinguish "streams" (Dennis Ritchie's term for his
revised non-block-device i/o system) from "STREAMS" (what AT&T put into
System V).  Dennis's streams cleaned up a lot of mess, and improved
performance to boot.  But as Dennis is rumored to have said, "`streams'
means something different when shouted".

The way to do i/o on Dennis's streams was with "read" and "write".
Network i/o, in general, looked *exactly* like local device i/o.  This
is the way it should be, unlike what both Berkeley and AT&T have done
(both have reluctantly conceded that most people want to use "read"
and "write" and have made that work, but their hearts were clearly
elsewhere).
-- 
TCP/IP: handling tomorrow's loads today |Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads tomorrow|  henry@zoo.toronto.edu   utzoo!henry
