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:
[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
I ran a few tests looking for various PyDECnet versions and their
responses to a SHOW NODE /xxx/:: STATUS, viz:
*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:
[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
So what is this? A newer version of PyDECnet isn't 'doing the right thing'?
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(a)lists.dfupdate.se
>>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>>
>>
>> _______________________________________________
>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se