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> <1990Aug27.111656.1@amazon.llnl.gov> Date: Tue, 28 Aug 90 16:24:00 GMT In article 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