From: "Erik E. Fair" <firstname.lastname@example.org>
To: Grant Taylor <email@example.com>
Subject: [TUHS] Re: Unix V8 Chaosnet, any takers?
Date: Thu, 14 Jul 2022 21:29:36 -0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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).
next prev parent reply other threads:[~2022-07-15 4:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-14 11:08 [TUHS] " Lars Brinkhoff
2022-07-14 16:37 ` [TUHS] " John Floren
2022-07-14 17:00 ` Lars Brinkhoff
2022-07-14 17:51 ` segaloco via TUHS
2022-07-14 18:19 ` Ron Natalie
2022-07-14 20:32 ` Tom Teixeira
2022-07-14 20:39 ` Ron Natalie
2022-07-15 0:33 ` Grant Taylor via TUHS
2022-07-15 4:29 ` Erik E. Fair [this message]
2022-07-14 19:36 ` Lars Brinkhoff
2022-07-14 21:50 ` segaloco via TUHS
2022-07-16 6:38 ` Lars Brinkhoff
2022-07-16 14:05 ` Warner Losh
2022-07-15 8:51 Paul Ruizendaal via TUHS
2022-07-15 10:25 Noel Chiappa
2022-07-15 11:53 ` Theodore Ts'o
2022-07-16 6:59 ` Lars Brinkhoff
2022-07-16 15:51 Noel Chiappa
2022-07-16 17:02 ` Warner Losh
2022-07-16 20:02 Paul Ruizendaal
2022-07-17 23:39 Noel Chiappa
2022-07-18 1:01 ` Ron Natalie
2022-07-18 17:07 Noel Chiappa
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).