28 Nov
2022
28 Nov
'22
12:25 a.m.
Tops-20 NFT, FAL and NRT will do something called Poor Man's Routing (or
PMR, for short). The Tops-10 NRT client will also do it. PMR is
something I dimly recall from Phase II or III; this was back before 36
bit hosts could do full routing. Here is some background:
On CCnet, we had enough 20's that not all could be connected to each
other in a star network. Not even Columbia had enough KMC's to 'star'
our 20's; the closest we got was a ring. CMU had even more. When a 20
wasn't next door to whatever system you wanted to get to, you had SET
HOST to one that did and then do another SET HOST accordingly. Or maybe
you had to do that a few times.
The manual procedure and all the accounts involved was clunky enough
that pretty much only systems staff did this. It was out of the
question for researchers and paying customers.
So I /think/ some site on CCnet came up with the idea of automating it
to a certain extent. It was called "Poor Man's Routing" and the way it
worked is that you specified the route to the system in question. Let's
say you were on NODE*A*:: and wanted to go to NODE*C*:: yet did not have
direct connectivity. If both NODE*A*:: and NODE*C*:: had connectivity
to NODE*B*::, then the relevant part of the configuration looked
something like this:
NODE*A*:: ↔NODE*B*:: ↔NODE*C*::
If NODE*B*:: was a PMR host, then you could do something like SET HOST
NODE*B*::NODE*C*:: and the parser would convert this to some
intermediate string. Instead of opening a connection on DECnet object
23, it would use object 123 and NODE*B*:: was responsible for taking the
rest of the string and getting you to the right place.
It worked well enough if the systems in question weren't excessively
loaded (which was invariably /never/ the case) and it saved us when the
dates for version 6 slipped. I had been under the impression that some
site on CCnet had done this and remember eagerly flushing all of it when
we finished the field test.
Much to my surprise an acquaintance of mine at Marlboro (Larry Campbell)
formalized this with a separate module called DNCONN.MAC. I put this
into a conditional assembly in part to save some address space (only to
get blown out of the water by some vestigial code that had never been hit).
Does anybody remember PMR? Did it exist for the other systems which
supported DECnet? Just curious whether I should turn this on for anyone.
PS: So much for my silly subject line of the day...
28 Nov
28 Nov
3:21 p.m.
On Nov 27, 2022, at 6:25 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
Tops-20 NFT, FAL and NRT will do something called Poor Man's Routing (or PMR, for
short). The Tops-10 NRT client will also do it. PMR is something I dimly recall from
Phase II or III; this was back before 36 bit hosts could do full routing. Here is some
background:
On CCnet, we had enough 20's that not all could be connected to each other in a star
network. Not even Columbia had enough KMC's to 'star' our 20's; the
closest we got was a ring. CMU had even more. When a 20 wasn't next door to whatever
system you wanted to get to, you had SET HOST to one that did and then do another SET HOST
accordingly. Or maybe you had to do that a few times.
The manual procedure and all the accounts involved was clunky enough that pretty much
only systems staff did this. It was out of the question for researchers and paying
customers.
So I think some site on CCnet came up with the idea of automating it to a certain extent.
It was called "Poor Man's Routing" and the way it worked is that you
specified the route to the system in question. Let's say you were on NODEA:: and
wanted to go to NODEC:: yet did not have direct connectivity. If both NODEA:: and NODEC::
had connectivity to NODEB::, then the relevant part of the configuration looked something
like this:
NODEA:: ↔ NODEB:: ↔ NODEC::
If NODEB:: was a PMR host, then you could do something like SET HOST NODEB::NODEC:: and
the parser would convert this to some intermediate string. Instead of opening a
connection on DECnet object 23, it would use object 123 and NODEB:: was responsible for
taking the rest of the string and getting you to the right place.
It worked well enough if the systems in question weren't excessively loaded (which
was invariably never the case) and it saved us when the dates for version 6 slipped. I
had been under the impression that some site on CCnet had done this and remember eagerly
flushing all of it when we finished the field test.
Much to my surprise an acquaintance of mine at Marlboro (Larry Campbell) formalized this
with a separate module called DNCONN.MAC. I put this into a conditional assembly in part
to save some address space (only to get blown out of the water by some vestigial code that
had never been hit).
Does anybody remember PMR? Did it exist for the other systems which supported DECnet?
Just curious whether I should turn this on for anyone.
I remember it well. It was indeed used in Phase II, and also in the DEC internal network
for Phase III nodes to reach out of area. And later, when "hidden areas"
appeared, to reach those.
RSTS has an implementation called PMR; VMS also, called PSTHRU I think. The PyDECnet
implementation was reverse engineered from the RSTS version; my Macro-10 is too feeble to
read the TOPS-20 version. And yes, it's compatible with the others; I have tested
TOPS-20 talking via my implementation. The protocol is really quite simple, you can see
the reverse engineered protocol spec in doc/protocols/pmr.txt in the PyDECnet source
tree.
Since it just does a simple repeating of incoming traffic it should be quite a simple
program and not much of a performance issue. The RSTS version is single threaded (one
process per PMR connection). The same goes for the PyDECnet version, though it would not
be hard to make it multi-threaded (not much reason to do so, though).
As mentioned in the document, the various implementations seem to differ a little.
Support or lack of it for interrupt messages is one detail; connect data is another. An
interesting omission is the lack of support (in any version I know of) for returning
connect confirm data, which means that it gets in the way of some protocols that rely on
that data for version number exchange.
By the way, while the node::node2:: ... syntax appears in a bunch of places, that
isn't necessarily PMR. For example, VMS supports that for file access, when the
intermediate nodes are VMS; that works simply because of RMS-32 transparent network
access. And MAIL11 does the analog of PMR internally; I haven't studied the details.
paul
6:03 p.m.
PSTHRU is jogging a memory... Hum.
I had a look at pmr.txt and was wondering where you found the Tops-20
stuff? I found SWSKIT V21 BB-H348C-RM_1982, but the stuff looks like
nothing I remember. In particular, pmr.mac looks suspiciously
incomplete but appears to just fork a program called pts. That
executable appears to be built from pts.sno, which is in SNOBOL, of all
things.
We were big fans of SNOBOL, but I don't remember using it except for
reformatting scanned user id sheets during registration for bulk user
creation. Running SNOBOL as a daemon would probably struck us as being
too memory and computationally intensive (it's an interpreted language).
Is there any interest on actually trying to resurrect this stuff? NFT
and FAL wouldn't need pmr.mac nor pts.sno, but I would need to reverse
engineer the format of the DNCONN configuration file. DNCONN is a nice
idea; you give it a node name and it builds the appropriate forwarding
string for you. What's missing appears to be other NRT PMR daemons.
The SNOBOL code doesn't appear to forward interrupt messages. I don't
know about DNCONN.
Regarding the node::node2:: ... syntax, I wasn't aware (or had
completely forgotten) that VMS would do this, but I'm not surprised.
One thing that impressed we Tops-20 folks at Columbia was the degree of
integration of DECnet. There are hooks in Tops-20 to do something
equivalent, but they never made it all the way into the EXEC. There is
a vestigial driver in the monitor, but I don't see any code for it.
I was aware of node::node2:: ... being used for MAIL11 because that has
to get transmogrified for SMTP (which runs over DECnet as well as TCP
and some other transports). It is handled in roughly the same way as
the Unix 'bang' format, meaning node!node1. I forget where the @ goes
(or if there is one) for Unix. We standardized on SMTP and would route
MAIL11 for any host that wanted it. We also rewrote the mailing client
in C so it could run on Unix. I don't remember if that made it over to
VMS, but it very well could have.
------------------------------------------------------------------------
On 11/28/22 9:21 AM, Paul Koning wrote:
I remember it well. It was indeed used in Phase II, and also in the
DEC internal network for Phase III nodes to reach out of area. And
later, when "hidden areas" appeared, to reach those.
RSTS has an implementation called PMR; VMS also, called PSTHRU I
think. The PyDECnet implementation was reverse engineered from the
RSTS version; my Macro-10 is too feeble to read the TOPS-20 version.
And yes, it's compatible with the others; I have tested TOPS-20
talking via my implementation. The protocol is really quite simple,
you can see the reverse engineered protocol spec in
doc/protocols/pmr.txt in the PyDECnet source tree.
Since it just does a simple repeating of incoming traffic it should be
quite a simple program and not much of a performance issue. The RSTS
version is single threaded (one process per PMR connection). The same
goes for the PyDECnet version, though it would not be hard to make it
multi-threaded (not much reason to do so, though).
As mentioned in the document, the various implementations seem to
differ a little. Support or lack of it for interrupt messages is one
detail; connect data is another. An interesting omission is the lack
of support (in any version I know of) for returning connect confirm
data, which means that it gets in the way of some protocols that rely
on that data for version number exchange.
By the way, while the node::node2:: ... syntax appears in a bunch of
places, that isn't necessarily PMR. For example, VMS supports that for
file access, when the intermediate nodes are VMS; that works simply
because of RMS-32 transparent network access. And MAIL11 does the
analog of PMR internally; I haven't studied the details.
paul
> ------------------------------------------------------------------------
>
> On Nov 27, 2022, at 6:25 PM, Thomas DeBellis
> <tommytimesharing(a)gmail.com> wrote:
>
> Tops-20 NFT, FAL and NRT will do something called Tops-20 NFT, FAL
> and NRT will do something called Poor Man's Routing (or PMR, for
> short). The Tops-10 NRT client will also do it. PMR is something I
> dimly recall from Phase II or III; this was back before 36 bit hosts
> could do full routing. Here is some background:
>
> On CCnet, we had enough 20's that not all could be connected to each
> other in a star network. Not even Columbia had enough KMC's to
> 'star' our 20's; the closest we got was a ring. CMU had even more.
> When a 20 wasn't next door to whatever system you wanted to get to,
> you had SET HOST to one that did and then do another SET HOST
> accordingly. Or maybe you had to do that a few times.
>
> The manual procedure and all the accounts involved was clunky enough
> that pretty much only systems staff did this. It was out of the
> question for researchers and paying customers.
>
> So I /think/ some site on CCnet came up with the idea of automating
> it to a certain extent. It was called "Poor Man's Routing" and the
> way it worked is that you specified the route to the system in
> question. Let's say you were on NODE*A*:: and wanted to go to
> NODE*C*:: yet did not have direct connectivity. If both NODE*A*::
> and NODE*C*:: had connectivity to NODE*B*::, then the relevant part
> of the configuration looked something like this:
>
> NODE*A*:: ↔NODE*B*:: ↔NODE*C*::
>
> If NODE*B*:: was a PMR host, then you could do something like SET
> HOST NODE*B*::NODE*C*:: and the parser would convert this to some
> intermediate string. Instead of opening a connection on DECnet
> object 23, it would use object 123 and NODE*B*:: was responsible for
> taking the rest of the string and getting you to the right place.
>
> It worked well enough if the systems in question weren't excessively
> loaded (which was invariably /never/ the case) and it saved us when
> the dates for version 6 slipped. I had been under the impression
> that some site on CCnet had done this and remember eagerly flushing
> all of it when we finished the field test.
>
> Much to my surprise an acquaintance of mine at Marlboro (Larry
> Campbell) formalized this with a separate module called DNCONN.MAC.
> I put this into a conditional assembly in part to save some address
> space (only to get blown out of the water by some vestigial code that
> had never been hit).
>
> Does anybody remember PMR? Did it exist for the other systems which
> supported DECnet? Just curious whether I should turn this on for anyone.
>
> PS: So much for my silly subject line of the day...
>
523
days inactive
524
days old
2 comments
2 participants
participants (2)
-
Paul Koning -
Thomas DeBellis