From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, MIME_QP_LONG_LINE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2847 invoked from network); 15 Jul 2022 04:29:52 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 15 Jul 2022 04:29:52 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id B844A406DB; Fri, 15 Jul 2022 14:29:45 +1000 (AEST) Received: from cesium.clock.org (cesium.clock.org [157.22.10.65]) by minnie.tuhs.org (Postfix) with ESMTPS id 78B8D4068E for ; Fri, 15 Jul 2022 14:29:38 +1000 (AEST) Received: from cesium.clock.org (localhost [127.0.0.1]) by cesium.clock.org (Postfix) with ESMTP id B688ACBC84; Thu, 14 Jul 2022 21:29:36 -0700 (PDT) From: "Erik E. Fair" In-reply-to: <654a4152-2bad-86fd-fc3c-528330e6e093@spamtrap.tnetconsulting.net> References: To: Grant Taylor Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Date: Thu, 14 Jul 2022 21:29:36 -0700 Message-ID: <24949.1657859376@cesium.clock.org> Message-ID-Hash: A6XWVM2MLJUP5KC7ARWIUB4QM36R5WEB X-Message-ID-Hash: A6XWVM2MLJUP5KC7ARWIUB4QM36R5WEB X-MailFrom: fair-tuhs@netbsd.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Unix V8 Chaosnet, any takers? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Grant, You've just described a useful piece of old ARPANET hardware: the Advanced = Communications Corp (ACC) Error Control Unit (ECU). ARPANET IMP 1822 (serial) = interface could be "local host" (30 feet, unbalanced serial), or "distant = host" (up to 2,000 feet, balanced serial). One used a pair of ACC ECUs - one at the IMP end, one at the host end, with = potentially arbitrary distance inbetween the ECUs, so as to obviate the 1822 = LH/DH limits. I managed such a setup at LLNL in 1986 (MILNET, IMP #21): when I was hired, = the group I hired into (well, put under contract to by CDC Professional = Services) was on-site at the lab, but as the wires ran between the old AEC = instrument trailer that was our machine room for a VAX-11/780 and PDP-11/70 = (both running BSD, natch) and the Magnetic Fusion Energy Computer Center (MFE = CC) where the IMP was located was rather longer than 1822 DH could handle. A 3002 circuit ("dry" pairs) and a pair of LADDS high-speed modems did the = trick there. Later, my group moved to the Hacienda Business Park in Pleasanton, some miles = away; we set up a Pac*Bell 56Kb/s (DS0) leased line with standard CSU/DSUs to = connect the ACC ECUs and in turn the host (well, router) to our port on the = IMP. I had some trouble getting that one going again because the ACC ECU = manuals were ... disjoint: simple recipies for setting DIP switches (with no = explanation of why), and a complete schematic in the back, which was useless = to me because I'm not an EE, but the documented switch settings for our desired = setup didn't work. ACC sent two engineers to our site from Santa Barbara to = solve the problem - the senior one was the last engineer to issue an = Engineering Change Order (ECO) on the ECUs. To bring this back to a Unix context, that sort of "spoofers in the middle" = was also the shtick of Telebit Trailblazer modems for the UUCP "g" protocol = in UUCP/USENET days - 19.2Kb/s in one direction at a time, and the modems = "knew" the "g" protocol and spoofed it for maximum speed in one direction, = which was the way UUCP worked too: file transfers were handled one direction = at a time, and just ACKs coming back. Internally, they effectively provided = an optimized UUCP tunnel atop their quite tenacious Packetized Ensemble = Protocol (PEP). Erik