From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 90423d85 for ; Wed, 28 Aug 2019 09:24:50 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 5A7F89BCA1; Wed, 28 Aug 2019 19:24:49 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 1BE589BC99; Wed, 28 Aug 2019 19:24:24 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 9541D9BC42; Wed, 28 Aug 2019 19:24:21 +1000 (AEST) X-Greylist: delayed 428 seconds by postgrey-1.36 at minnie.tuhs.org; Wed, 28 Aug 2019 19:24:20 AEST Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) by minnie.tuhs.org (Postfix) with ESMTPS id 68D229BC35 for ; Wed, 28 Aug 2019 19:24:20 +1000 (AEST) Received: from mba2.fritz.box ([80.101.112.122]) by smtp-cloud7.xs4all.net with ESMTPA id 2u4iiSA3sThuu2u4jiGN2J; Wed, 28 Aug 2019 11:17:10 +0200 From: Paul Ruizendaal Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <5467B5A6-B084-424E-9493-52D7F03E4074@planet.nl> Date: Wed, 28 Aug 2019 11:17:08 +0200 To: TUHS main list X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfNpxVGCGNWwu4eIE4BWoAM7wQesbSzI/G9QAY3RLsyG4cV52JLmGQxSaQTKDjs0qoauStcErrrMGU/R18o9XuAlZhvuRlZ+VfqbVWNRH3XMCprPCKc6p R65qYvmltRWFlN3AoVq5GVbTPz9lyhGZOH1EDbfPkYubrwNXFOqYD0Lk Subject: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > I find it hard to believe what you remember Dennis saying. The point = of > dmr's streams was to support networking research in the lab and avoid = the > myriad bugs of the mpx interface by stepping around them completely. >=20 > Perhaps it's out of context. >=20 > -rob > I could be wrong but that's my memory. What he told me was streams = was > for line disciplines for tty drivers. That's what I know but you were > there, I was not. I'm pretty confused because what Dennis said to me > was that he did not think streams would work for networking, he = thought > they made sense for a stream but not for a networking connection = because > that had multiple connections coming up through a stream. There is some contemporary material that gives a bit of context. The = quotes are a bit contradictory and perhaps reflect evolving views. [1] The original dmr paper (1984) on streams = (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no = networking view, focussing on terminal handling in its discussion. Also, = near the end it says: "Streams are linear connections; by themselves, = they support no notion of multiplexing, fan-in or fan-out. [...] It = seems likely that a general multiplexing mechanism could help in both = cases, but again, I do not yet know how to design it.=E2=80=9D This = seems to exclude usage for networking, which is typically multiplexed. [2] However, now that the V8 sources are available it is clear that the = streams mechanism was used (by dmr?) to implement TCP/IP networking. He = explains how that tallies with the above quote on multiplexing in a 1985 = usenet post: = https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3= Astreams/net.unix-wizards/b7W_j_0qASU The config files in the surviving TUHS V8 source tree actually match = with the setup that dmr described in the penultimate paragraph. If the post by dmr does not immediately appear, click on the 8-10-85 = post by 'd...@dutoit.uucp=E2=80=99 to make it fold out. For ease of = reference, I=E2=80=99m including the message text below. Steven J. Langdon claimed that without multiplexing one couldn't do a proper kernel-resident version of TCP/IP in the V8 stream context. Here's how it's done. It is still true in our system that stream multiplexing does not occur, in the sense that every stream connection has (from the point of view of the formal data structures) exactly two ends, one at a user process, and the other at a device or another process. However, this has, in practice, not turned out to be a problem. Say you have a hardware device that hands you packets with a channel (or socket) number buried inside in some complicated format. The general scheme to handle the situation uses both a line discipline (stream filter module) and associated code that, to the system, looks like a stream device driver with several minor devices; these have entries in /dev. A watchdog process opens the underlying real device, and pushes the stream module. Arriving packets from the real device are passed to this module, where they are analyzed, and then given to the appropriate associated pseudo-device. Likewise, messages written on the pseudo-device are shunted over to the line discipline, where they are encoded appropriately and sent to the real device. This is where the multiplexing-demultiplexing occurs; formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules. However, the interfaces of the combined larger module obey stream rules. For example, IP works this way: The IP line discipline looks at the type field of data arriving from the device, and determines whether the packet is TCP or UDP or ARP or whatever, and shunts it off to the stream associated with /dev/ip6 or /dev/ip17 or whatever the numbers are. TCP, of course, is multiplexed as well. So there is a TCP line discipline, and a bunch of TCP devices; a watchdog process opens /dev/ip6, and pushes the TCP line discipline; then the TCP packets it gets are parcelled out to the appropriate /dev/tcpXX device. Each TCP device looks like the end of a stream, and may, of course, have other modules (e.g. tty processor) inserted in this stream. UDP sits on top of IP in the same way. This example is complicated, because (TCP,UDP)/IP is. However, it works well. In particular, the underlying real device can be either an ethernet or our own Datakit network; the software doesn't care. For example, from my machine, I can type "rlogin purdy" and connect to a Sequent machine running 4.2; the TCP connection goes over Datakit to machine "research" where it is gatewayed to a local ethernet that purdy is connected to. A further generalization (that we haven't made) is in principle easy: there can be protocol suites other than IP on an Ethernet cable. So there could be another layer to separate IP from XNS from Chaosnet, etc. Dennis Ritchie Maybe the subtle notion expressed as "formally, it is outside of the = stream structure, because the data-passing doesn't follow the forward = and backward links of the stream modules. However, the interfaces of = the combined larger module obey stream rules=E2=80=9D explains how dmr = could talk about streams as being just suitable for line disciplines = without meaning to say that they did not have good use in networking. Paul =20