From owner-freebsd-hackers Sat Jun 3 11:45:27 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA11364 for hackers-outgoing; Sat, 3 Jun 1995 11:45:27 -0700 Received: from mail.htp.com ([199.171.4.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA11356 for ; Sat, 3 Jun 1995 11:45:26 -0700 Received: from et.htp.com (et.htp.com [199.171.4.228]) by mail.htp.com (8.6.5/8.6.5) with SMTP id OAA04478 for ; Sat, 3 Jun 1995 14:44:07 -0400 Date: Sat, 3 Jun 1995 14:44:07 -0400 Message-Id: <199506031844.OAA04478@mail.htp.com> X-Sender: dennis@mail.htp.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-hackers@freebsd.org From: dennis@et.htp.com (dennis) Subject: Re: Anyone interested in a STREAMS port? Sender: hackers-owner@freebsd.org Precedence: bulk Someone wrote.. >> On top of the TCP interface (using XTI in user mode) I have a >> XTI/streams based rlogind/telnetd daemon which takes incoming >> connections, forks to handle the incoming connection, performs >> the initial protocol work, and then pushes on either a rlogind or >> telnetd streams module, and execs login right over itself. >> >> This module converts talks TPI to TCP on the bottom and talks to >> ldterm (the streams terminal line discipline module) on the top. >> Hence the network connection is now a terminal. Even better there >> are no context switches when doing I/O, no extra processes, less CPU >> utilization, ... > >Paol-Henning Kamp writes.. >As I said: good for terminal work, as it is primarily suited for >character based stuff. I'm all for the stuff you did. I just don't >want anybody to even think about the tcp/ip becoming streams based... >Streams aware maybe, but not -based. >-- This is not true at all, BSD is clearly designed for TCP/IP, and support for other protocols is basically patchwork. While running TCP/IP over STREAMS doesn't make any sense, STREAMS does provide a clean mechanism for passing event information and data to a user process that far exceeds the capabilities of BSD messaging. It is much more effiecient for high-speed (non-character oriented) applications (like HS serial drivers) than the mbuf/socket stuff in BSD. db