Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!rutgers!ucla-cs!zen!ucbvax!ACC.ARPA!art From: art@ACC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Re: Streams TCP/IP Message-ID: <8707290156.AA09655@ucbvax.Berkeley.EDU> Date: Tue, 28-Jul-87 22:22:00 EDT Article-I.D.: ucbvax.8707290156.AA09655 Posted: Tue Jul 28 22:22:00 1987 Date-Received: Thu, 30-Jul-87 04:31:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 33 >Would someone please post a summary of reasons why use of Streams is >an advantage. Is this just another sales-hype buzzword? or is there >a reason Streams is better? than sockets? than psudo-sockets? or >select? Does the end user see any advantage? faster response? less >CPU waste? what? Does anyone have some before & after figures on >drivers that were converted to Streams? Please share them with us. Lets not compare apples and oranges here. STREAMs is an architectural feature of the System V Rel 3 UNIX kernel. STREAMs are to the kernel what pipes are to users, allowing various kernel components to connected in useful configurations. This is the base used for kernel resident communications support in Sys V Rel 3. Sockets in the Berkeley UNIX world can mean a couple of things, the socket systems calls or the architecture of the kernel resident protocol implementations. In my opinion, the STREAMs mechanism is a much cleaner way to implement things like communications protocols in the kernel (but there are some limitations). The user interface to streams can be nearly anything you could want, but normally is via the Transport Level Interface (TLI) which is a stream module which is intended to present a standard transport service interface to users. Most of the TCP/IP implementations that I have seen for STREAMs provide the socket interface, either via new systems calls or via an interface emulation library. As far as performance, I would suspect that a STREAMs implementation would be at least as fast as functionally equivalent code in the Berkeley kernel. Art Berggreen art@acc.arpa ------