Regarding its performance, I don't think netpth
was ever a candidate for full productization, apparently being
more of an internal tool for DECnet specialists. However, this is
only a guess.
From the edit history, it looks like it started out life in 1982 being put together by Stu Grossman, who I thought was working on Stanford at the time. That would be surprising as I had thought Stanford didn't run Tops-10. But maybe I'm wrong on both counts. It then appears to have been adopted by Bill Davenport, Gunnar Lindell and Carl Appellof. I don't know about Bill or Gunnar, but I'm pretty sure I remember Carl being at DEC.
I would guess netpth was part of
a Tops-10 SWSKIT and was then partially ported to Tops-20. It
only uses those Tops-20 JSYi that are necessary to do its job.
Since Phase IV DECnet on the PDP-10 was first developed under
Tops-10 (where it could run in user mode) and then ported to
Tops-20 (it's all under conditional assembly), the API's are
remarkably similar. What I mean by that is the Tops-10 UUO and
Tops-20 JSYS calling interface are nearly plug compatible with the
exception of the UUO having more flexible register scheduling.
So, I think the crashing is due to error conditions that weren't anticipated in those early days, that is, that you would never not get told what the adjacent nodes were. It is also not impossible that some of the fixes that I put into Tops-20 to report secondary error conditions could be triggering this.
I do remember netpth working at some point, Peter Lothberg
demonstrated it about a year and a half ago on 10/21/21, viz:
I ran a few tests looking for various PyDECnet versions and their responses to a SHOW NODE xxx:: STATUS, viz:[Routing path from MRC (59.41) to LEGATO (2.1)] From Via Back Thru Cost Hops MRC (59.41) =>NI-0-0 / TAP-0 <= OPS1VA (59.59) -1 -1 OPS1VA (59.59) =>GRE-3 / GRE-4 <= IAD2 (59.1020) -1 -1 IAD2 (59.1020) =>DMC-0 / MUL-59-1020 <= A2RTR (2.1023) -1 -1 A2RTR (2.1023) =>TAP-0 / QNA-1 <= LEGATO (2.1) -1 -1
Node
PyDECnet Version
Next Node?
A2RTR::
V1.0-596
Yes
PYRTR::
T1.1-640
No
STORTR::
*** Not Reported ***
Yes (Numeric, Only)
DEC000::
V1.0-583
No
NOVA::
V1.0-596
Yes
A29RT2::
T1.1-648
No
This suggested running a test through the older versions, which worked, viz:
So what is this? A newer version of PyDECnet isn't 'doing the right thing'?[Routing path from VENTI2 (2.522) to SAMV02 (2.152)] From Via Back Thru Cost Hops VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) 10 3 A2RTR (2.1023) =>MUL-2-150 / MUL-1 <= SAMISH (2.199) 9 2 SAMISH (2.199) =>ETH-0 / UNA-0 <= SAMV02 (2.152) 4 1
netpth should probably have some more robust error recovery. Doing the same thing for SAMT20:: got me almost the same thing except when netpth got to the last part, it died with:
?NETPTH Connection rejected, reason: Reject or disconnect by object
So that's something to look at. Also, although this shouldn't matter, I'm not sure if SAMT20:: is in a funny state or is perhaps misdocumented. A connection attempt with the just released Kermit-20 shows:
Kermit-20>connect samt20:: /stay % Kermit-20: Can't enable ^C capability--use ^G instead [Remote system SAMT20:: is running VMS] ?SAMT20:: does not support Tops-10/Tops-20 Network Remote Terminal protocol Kermit-20>
Again, as per Paul's recommendation, Kermit-20 only reports the
remote operating system, it makes its connection decision based on
which NRT transports the remote node offers.
On 4/10/23 9:09 PM, Johnny Billquist wrote:
:-)
On 2023-04-11 03:04, Thomas DeBellis wrote:
Yes, I was catching up on that, but perhaps not keeping up with it...
Seems unlikely that any code in netpth would be based on the behavior of PyDECnet, but anyway, that detail will improve soon.
So what's the bottom line here? Is netpth rolling over and dying actually legitimate or is there a better algorithm to use?I don't think there any better algorithm. Why netpth throws errors is also unclear. Maybe it has a more rigid idea on how circuit names should look? PyDECnet allows pretty much anything as a circuit name. DEC was a bit more conservative... I think you need to dig around on that maybe.
Johnny
_______________________________________________
On 4/10/23 9:00 PM, Johnny Billquist wrote:
That's what the thread between me and Paul right now is about. And Paul have this fixed in his code now. Next
version should have it fixed.
Johnny
On 2023-04-11 02:54, Thomas DeBellis wrote:
I don't have an informed opinion yet, as I only just started looking. The code is kind of odd in that it is half Tops-10 andhalf Tops-20, but not in a GLXLIB sort of way.
That being said, what you've pointed out strikes me as correct. Now, if I just look at the show node /xxx/status, I was wondering about something:
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
Isn't pyrtr:: supposed to be telling me what the next node is?
Maybe that's why netpth is asking about circuits?
On 4/10/23 8:42 PM, Johnny Billquist wrote:
Obviously, there is no good reason to ask for the circuit information. You already got all you needed from the show node xx status, right?
Johnny
On 2023-04-11 02:37, Thomas DeBellis wrote:
It sits in a loop doing the following:
show node xxx:: status
From that it picks out the appropriate circuit and does a
show circuit xxx status
So, to show the path from venti2:: to twenex::, the first few commands would be
NCP>*shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Active Links = 0
Delay = 1
Circuit = NI-0-0
Next Node = 2.1023 (A2RTR)
NCP>*shoW cirCUIT ni-0-0 staTUS *
Circuit State Loopback Adjacent Block
Name Node Size
NI-0-0 On 2.1023 (A2RTR) 591
Designated Router = 2.1023 (A2RTR)
NI-0-0 2.520 (TOMMYT) 1476
NCP>*tell a2rtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
Circuit = DMC-31
Next Node = 31.3 (PYRTR)
NCP>*tell a2rtr:: shoW cirCUIT dmc-31 stATUS *
Circuit = DMC-31
State = On
Adjacent Node = 31.3 (PYRTR)
Block Size = 576
NCP>*telL pyrtr:: shoW noDE twenex:: statUS *
Remote Node = 31.29 (TWENEX)
State = Reachable
Delay = 1
Cost = 24
Hops = 2
Circuit = MUL-31-32
NCP>*telL pyrtr:: shoW cirCUIT mul-31-32 statUS **
*
Circuit = MUL-31-32
Adjacent Node = 31.32 (PIPY)
Block Size = 576
State = On
NCP>*telL pipy:: shOW noDE twenex:: statUS **
*
Remote Node = 31.29 (TWENEX)
State = Reachable
Type = Nonrouting IV
Cost = 4
Hops = 1
Circuit = VDE-31
NCP>*tell pipy:: shoW cirCUIT vde-31 staTUS*
Circuit = VDE-31
Adjacent Node = 31.1022 (AHIMSA)
Block Size = 591
State = On
Adjacent Node = 31.1020 (MOKSHA)
Block Size = 591
Adjacent Node = 31.13 (FEDACH)
Block Size = 1498
Adjacent Node = 31.19 (MACOS9)
Block Size = 1498
Adjacent Node = 31.14 (FOMFOR)
Block Size = 1498
Adjacent Node = 31.26 (W2000S)
Block Size = 1498
Adjacent Node = 31.18 (RAPTOR)
Block Size = 1498
Adjacent Node = 31.21 (WXPEE2)
Block Size = 1498
Adjacent Node = 31.22 (TRU64)
Block Size = 1490
Adjacent Node = 31.20 (WFW311)
Block Size = 1498
Adjacent Node = 31.16 (WEXPEE)
Block Size = 1498
Adjacent Node = 31.11 (CLOUDY)
Block Size = 1498
Adjacent Node = 31.10 (QCOCAL)
Block Size = 1498
Adjacent Node = 31.12 (JUICHI)
Block Size = 576
Adjacent Node = 31.23 (XLVII)
Block Size = 1498
Adjacent Node = 31.24 (TSTVAX)
Block Size = 1498
Adjacent Node = 31.28 (RST101)
Block Size = 598
Adjacent Node = 31.31 (XLIV)
Block Size = 1498
Adjacent Node = 31.33 (XL)
Block Size = 1498
Adjacent Node = 31.34 (NANAJU)
Block Size = 576
Adjacent Node = 31.35 (NJEVX1)
Block Size = 1498
Adjacent Node = 31.36 (NJEVX2)
Block Size = 1498
Adjacent Node = 31.41 (KDJ11E)
Block Size = 576
Adjacent Node = 31.44 (XLVI)
Block Size = 1498
Adjacent Node = 31.39 (ROUT20)
Block Size = 1498
Adjacent Node = 31.38 (LV)
Block Size = 1498
Adjacent Node = 31.15 (OSTARA)
Block Size = 1498
Adjacent Node = 31.30 (VAXSTN)
Block Size = 1498
Adjacent Node = 31.42 (XXXV)
Block Size = 1498
Adjacent Node = 31.1021 (PYDNET)
Block Size = 591
Adjacent Node = 31.27 (MACOS7)
Block Size = 1498
/Adjacent Node = 31.29 (//TWENEX//)//
// Block Size = 576/
------------------------------------------------------------------------
On 4/10/23 6:30 PM, Johnny Billquist wrote:
Could you tell in detail which NICE messages you are generating?
In general, if I were to do such a tool, I would normally do the NICE message that generates the same request as NCP SHO NOD do.
To give an example from JOCKE to A2RTR:
.ncp sho nod a2rtr
Node summary as of 11-APR-23 00:26:52
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.15 (PONDUS)
.ncp tell pondus sho nod a2rtr
Node summary as of 11-APR-23 00:27:05
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 1.13 (MIM)
.ncp tell mim sho nod a2rtr
Node summary as of 11-APR-23 00:27:21
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR) 31.3 (PYRTR)
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure if it's just an old version of PYRTR, or if there is something for Paul to improve. But you should get the idea...
Also, note that this will give the forward path, which in DECnet most certainly might be different than the return path...
Johnny
On 2023-04-10 23:58, Thomas DeBellis wrote:
Now that I'm done with Kermit-20, I wanted to get back to finishing up some other work that I had been doing. FAL, DAP and NFT are in good enough shape for me to leave them alone for the moment, so that's another rabbit hole I've gotten myself out of.
I'm now looking fix an error that I somehow introduced into MMAILR (SMTP over DECnet). Fixing this required modifying DDT, whichIhad to do to fix another issue I had introduced into Kermit. I wanted to have a quick look at what Tops-20 hosts might be up on HECnet and wrote up a little batch job to use NETPTH to test connectivity.
NETPTH is a nifty utility to find paths between DECnet nodes. It builds a connection the NCU's of various nodes to determine the path that a message might take to get there. Think of it like traceroute or ping -R (RECORD_ROUTE option).
It almost never works...
Before I roll up my sleeves and jump into this I was wondering if anybody had any observations about the errors I'm seeing?
------------------------------------------------------------------------
*TINA*::*PAMINA*::*KLIO*::*TWLGHT*::*RARITY*::*FLUSHY*::*RBDASH*::*APPLEJ*::*PINKIE*::*DISCRD*::*TWENEX*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>DMC-31 /
?NETCFO Can't find Output Circuit parameter
*SAMT20*::
?NETURN Unreachable node
*TOMMYT*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /NI-0-0 <= TOMMYT (2.520) 1 1
*BITXT2*::*BITXT0*::*MINDY*::*FALLON*::*JOSHUA*::*OLAF*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>
?NETCFO Can't find Output Circuit parameter
*WALACH*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>DMC-29-206 /
?NETCFO Can't find Output Circuit parameter
*SOL*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016) -1 -1
STORTR (59.1016) =>GRE-16 /
?NETCFO Can't find Output Circuit parameter
*FENCER*::
From Via Back Thru Cost Hops
VENTI2 (2.522) =>NI-0-0 /BRG-0 <= A2RTR (2.1023) -1 -1
A2RTR (2.1023) =>MUL-59-1016 / DMC-1 <= STORTR (59.1016) -1 -1
STORTR (59.1016) =>GRE-16 /
?NETPTH NTMAN failed, reason:
Parameter missing
$
_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se