I’m a bit late to the show, but actually, story wise, it may be possible to combine the two approaches. Like, initially, it’s all over the 1970s and 1980s again, when grass root media was spreading on all kind of magnetic media (cassettes, video tapes, etc) and copying technology. However, after the apocalypse, there’s only that much of that media left, so as traction is gained, other ways have to be explored. Like mending broken telephone lines and distributing archive images of that media, still coming in editions and subscriptions. A network made of d64 floppy images distributed by (more or less) central hubs (maybe a bit like Gopher).
1 Like
Yeah, Vinge is great, and Fire Upon The Deep particularly good. But then, he’s a computer scientist! Ian M Banks’ Excession is also rather nice but less rooted in the world we know. There are surely different styles of fiction: The Martian, say, might try to lay out actual recipes, whereas Ursula K Leguin, say, or Ann Leckie, would have things be, and be used, without detailed explanation of how things work.
1 Like
You’re certainly free to do so, however I honestly don’t know any one that discusses UUCP talking about the wire protocol used between nodes. The protocols barely get 2 paragraphs of mention in the O’Reilly books about using and managing UUCP. UUCP supports several protocols, including TCP/IP, though, obviously, initially it relied on modems and serial communications.
UUCP is the overarching command set and architecture of the suite of programs, configuration files, and protocols.
Mail and News systems used UUCP to communicate not because of the wire protocol, but because of the higher level concepts of queueing, batching, routing, prioritization, scheduling, and access control. None of which have anything to do with the wire protocol.
So, when I’m talking about UUCP, I’m talking about the entire system, and it’s overall capabilities rather than some small facet of it or a specific use case.
This seems to be the core of our disagreement.
UUCP did not do routing. When you sent email via a bang path, the mailer did not and could not pass bang paths to the uucp or uux commands. (Bang paths didn’t exist on the uucp command in the early days, never existed in uux, and the uucp bang paths wouldn’t have worked anyway because almost nobody allowed remote execution of the uucp command.)
The rmail program that received mail across a single hop handled the routing at a higher level. (And often enough, even in the very early days, the mail was not routed over UUCP for at least part of its journey. Remember, sendmail’s predecessor, delivermail, was written specifically to deal with routing across multiple networks. It was shipped with 4BSD in 1979.)
1 Like
It DID do routing. Mail, however, did not USE IT for routing. Mail != UUCP.
Well, ok, I suppose we’re talking about different definitions of UUCP, probably for different purposes. I define routing as “figuring out how to get from A to B when the two are not directly connected,” and no UUCP package I’m aware of ever did that; it always had to be done by some sort of external tool that did not come with any UUCP package of which I’m aware. Perhaps you consider those external tools (rmail, rnews, a human being typing a bang path) to be part of UUCP (maybe even when they didn’t use UUCP); I don’t. (And I think it still behoves us to remember that even when the uucp command itself was given a route, it almost invariably never worked outside of a single organization, for some very good reasons.)
To bring this back to the original topic, I will also mention that I do not think your approach to analysis of this is the right one for building the protocol stack that the the OP is asking for; at least I know for certain that with your approach I could not have designed the system I suggested. Key to my scheme is to treat UUCP as purely a point-to-point transfer between directly connected machines. (There are several reasons for this, but a major one is that what you call its “routing” in practice Just Doesn’t Work for even the simplest internetworking.)
There’s a historical connection (perhaps even a parallel!) here, too: we seem to be facing a problem similar to what the ARPANET folks were facing in 1977, and my criticism and solution is pretty much exactly the same as Jon Postel’s in IEN #2. (He writes, quite dramatically, “We are screwing up in our design of internet protocols by violating the principle of layering.”)
1 Like
Been reading the victorian internet both as research on this, and a general sort of look at how a lot of social things are older than we think along with how not st all destined to be The Path morse’s code and system was.
Just trying to figure out how to integrate this information in and shy a city on a railway would agree to furlough a lot of their point to point runners in favor of a new system they have only heard of in abstract…
If anyone has a link to an article that details how the telegraph system was architected, I’d appreciate it. Just a curiosity of mine.
Point to point telegraphy is straigt forward, but how did a message from New York get to Los Angeles. How did the telegraph along rail roads work. Were messages forwarded? Did they have common operating times when to staff stations to receive messages? We’re messages coded so some stations would ignore them (as is, they hear the message, but simply ignore it).
Things like that.
1 Like
Covers optical telegraphy, the birth of electromagnetic telegraph, anticdotal bits and pieces, and a lot of the human and era element instead of a dry thing a leada to thing b here are diagrams.