On Apr 10, 2023, at 8:41 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 02:19, Paul Koning wrote:
...
RSTS is L1 only, but my point is that you'd see it if you happen to have a RSTS node
in your path. For HECnet, not all that likely. According to my notes, one RSTS bug is
that it reports node type even if the node isn't adjacent (no idea what it is
reporting in that case) and in addition it encodes that value incorrectly. The mapper
would like to use that data but given that bug it doesn't currently.
Hmm. Yeah, not sure I know of any RSTS/E acting as any kind of router. Maybe someone else
knows of one?
As for node type, right. Checked RSX now, and it only reports this for adjacent nodes.
Empty field for others.
But not sure how the mapper would use it. The mapper is talking to each node anyway,
right? And getting type from there.
Or would you use this to not even go talking to endnodes?
Yes. And also to know the type of nodes that don't accept NICE connections.
> Also, note
that this will give the forward path, which in DECnet most certainly might be different
than the return path...
And more precisely, it gives one forward path; if a router does path splitting that
isn't represented in the data you get back.
True. In that case, you get one answer, but there might be another with the same cost,
which you will not find out.
One small issue, more for the HECnet mapper than
for a traceroute service: RSTS nodes get some of this stuff wrong. I annotated some of it
in the mapper code. I think next node may not come back all the time, and I know for sure
that adjacent node type is encoded incorrectly.
Maybe time for you to fix that too? :-)
I should look for it again. That code
isn't too easy to grok.
Not sure any hints from the RSX code would help, but let me know if you want me to dig
around.
Probably not. The code's very early ancestry is RSX, I think, but the details of
getting the data out of the kernel are all specific to RSTS of course.
paul