From mboxrd@z Thu Jan 1 00:00:00 1970 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=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 18954 invoked from network); 6 Apr 2020 18:13:02 -0000 Received-SPF: pass (minnie.tuhs.org: domain of minnie.tuhs.org designates 45.79.103.53 as permitted sender) receiver=inbox.vuxu.org; client-ip=45.79.103.53 envelope-from= Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with UTF8ESMTPZ; 6 Apr 2020 18:13:02 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2987894496; Tue, 7 Apr 2020 04:12:59 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 298B694483; Tue, 7 Apr 2020 04:12:23 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=planet.nl header.i=@planet.nl header.b="VhTky8rk"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id EC3E394483; Tue, 7 Apr 2020 04:12:18 +1000 (AEST) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by minnie.tuhs.org (Postfix) with ESMTP id 0CCA093D06 for ; Tue, 7 Apr 2020 04:12:16 +1000 (AEST) Received: from cpsps-ews12.kpnxchange.com ([10.94.84.179]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(8.5.9600.16384); Mon, 6 Apr 2020 20:12:09 +0200 X-Brand: 7abm2Q== X-KPN-SpamVerdict: e1=0;e2=0;e3=0;e4=(e1=10;e3=10;e2=11;e4=10);EVW:Whi te;BM:NotScanned;FinalVerdict:Clean X-CMAE-Analysis: v=2.3 cv=A4b3w5eG c=1 sm=1 tr=0 cx=a_idp_e a=/dHbpd/3q0lrH6oA/zwSgQ==:117 a=soxbC+bCkqwFbqeW/W/r+Q==:17 a=x1i13A_MHe4A:10 a=IkcTkHD0fZMA:10 a=cl8xLZFz6L8A:10 a=GmCAywlCgC3T03l3_XQA:9 a=8xGFiW1KH6zWr9El:21 a=jJGHFkVd1_no8MXm:21 a=QEXdDO2ut3YA:10 X-CM-AcctID: kpn@feedback.cloudmark.com Received: from smtp.kpnmail.nl ([195.121.84.45]) by cpsps-ews12.kpnxchange.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Mon, 6 Apr 2020 20:12:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:date:message-id:subject:mime-version:content-type:from; bh=J6qzvi16uPTqj47567QXwT8uL7sKiyGcXhl4tKBY5qM=; b=VhTky8rksYRFnIphl6KE3heT+SpDeyvUxfE5P+rYNk8CrKfwiktLF/krWd7vsuK0Y3EXG8o/QEURr 5gLIlBnSr4xzyvQuW2+9xDDFkn8FvDLf3YD1NnLlusPtAxl3K6hDkPbdnfjigCZz57Ce/mhg2+/PLa YJIw6ynnF5GxL7sg= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|+6wF9IGk8p2djddd+iBONiLQY46QFPqNA7hkrBuywKx6h1t9W857Q1DP/dxJKpE 8Vs9cyIK4/GVarE8BXZCoHw== X-Originating-IP: 80.101.112.122 Received: from mba2.fritz.box (sqlite.xs4all.nl [80.101.112.122]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 2196db59-7832-11ea-a1d0-005056ab7447; Mon, 06 Apr 2020 20:12:09 +0200 (CEST) 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: <1E2FB6CE-868E-45D3-81DA-9DCA94283800@planet.nl> Date: Mon, 6 Apr 2020 20:12:09 +0200 To: TUHS main list X-Mailer: Apple Mail (2.3445.104.11) X-OriginalArrivalTime: 06 Apr 2020 18:12:09.0682 (UTC) FILETIME=[E368F320:01D60C3E] X-RcptDomain: minnie.tuhs.org Subject: [TUHS] PK protocol 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 ran a search for =E2=80=98Datakit=E2=80=99 on the archive of this = maling list and came across the below message from Norman Wilson (Sep = 2017). Having spent quite a bit of time recently on figuring out Datakit = details and 8th Edition source, I now much better understand what he was = saying =E2=80=94 or at least I think I do. It made me take another look at the /dev/pk[0123].c files in the V7 = source code. I=E2=80=99d seen it before, but always thought it was UUCP = code. Now I=E2=80=99m wondering. It looks like UUCP packet "protocol g=E2=80=9D = is maybe much the same as the original (=E2=80=9CChesson=E2=80=9D) = packet algorithm for Datakit, and if so it would be =E2=80=9Cdual = use=E2=80=9D. It would seem that in V7 line discipline =E2=80=980=E2=80=99= was normal tty handling, discipline =E2=80=981=E2=80=99 was PK protocol = over serial and line discipline =E2=80=982=E2=80=99 was PK protocol over = something with CRC in the driver - whatever that was. If the above thought is correct, then it shines a light on network = buffering in V7: it uses buffer space in blocks of n*32 bytes, carved = out from a pool of disk buffers (see pk3.c); it pre-allocates space for = one full receive window. I have not fully figured it out, but at first glance it seems that the = PK line discipline was only integrated with the DH-11 driver in the = public V7 source. That would make sense in a networking context, as that = board offered input buffering / DMA output to reduce the interrupt load. = In 1979 Datakit seems to have connected over a DR-11C board, but there = is no driver for that in the V7 source tree. Am I on the right track? =3D=3D=3D=3D=3D The point of the stream I/O setup with stackable line disciplines, rather than the old single line-discipline switch, was specifically to support networking as well as tty processing. Serial-device drivers in V7 used a single line-discipline driver, used variously for canonical-tty handling and for network protocols. The standard system as used outside the labs had only one line discipline configured, with standard tty handling (see usr/sys/conf/c.c). There were driver source files for what I think were internal-use-only networks (dev/pk[12].c, perhaps), but I don't think they were used outside AT&T. The problem Dennis wanted to solve was that tty handling and network protocol handling interfered with one another; you couldn't ask the kernel to do both, because there was only one line discipline at a time. Hence the stackable modules. It was possible to duplicate tty handling (probably by placing calls to the regular tty line discipline's innards) within the network-protocol code, but that was messy. It also ran into trouble when people wanted to use the C shell, which expected its own special `new tty' line discipline, so the network code would have to know which tty driver to call. It made more sense to stack the modules instead, so the tty code was there only if it was needed, and different tty drivers could exist without the network code knowing or caring. When I arrived at the Labs in 1984, the streams code was in use daily by most of us in 1127. The terminals on our desks were plugged into serial ports on Datakit (like what we call a terminal server now). I would turn on my terminal in the morning, tell the prompt which system I wanted to connect to, and so far as I could tell I had a direct serial connection. But in the remote host, my shell talked to an instance of the tty line module, which exchanged data with a Datakit protocol module, which exchanged data with the low-level Datakit driver. If I switched to the C shell (I didn't but some did), csh would pop off the tty module and push on the newtty module, and the network code was none the wiser. Later there was a TCP/IP that used the stream mechanism. The first version was shoehorned in by Robert T Morris, who worked as a summer intern for us; it was later cleaned up considerably by Paul Glick. It's more complicated because of all the multiplexers involved (Ethernet packets split up by protocol number; IP packets divided by their own protocol number; TCP packets into sessions), but it worked. I still use it at home. Its major flaw is that details of the original stream implementation make it messy to handle windows of more than 4096 bytes; there are also some quirks involving data left in the pipe when a connection closes, something Dennis's code doesn't handle well. The much-messier STREAMS that came out of the official System V people had fixes for some of that, but at the cost of quite a bit more complexity; it could probably be done rather better. At one point I wanted to have a go at it, but I've never had the time, and now I doubt I ever will. One demonstration of virtue, though: although Datakit was the workhorse network in Research when I was there (and despite the common bias against virtual circuits it worked pretty well; the major drawback was that although the underlying Datakit fabric could run at multiple megabits per second, we never had a host interface that could reliably run at even a single megabit), we did once arrange to run TCP/IP over a Datakit connection. It was very simple in concept: make a Datakit connection (so the Datakit protocol module is present); push an IP instance onto that stream; and off you go. I did something similar in my home V10 world when quickly writing my own implementation of PPP from the specs many years ago. The core of that code is still in use in my home-written PPPoE code. PPP and PPPoE are all outside the kernel; the user-mode program reads and writes the serial device (PPP) or an Ethernet instance that returns just the desired protocol types (PPPoE), does the PPP processing, and reads and writes IP packets to a (full-duplex stream) pipe on the other end of which is pushed the IP module. All this is very different from the socket(2) way of thinking, and it has its vices, but it also has its virtues. Norman Wilson Toronto ON