[HECnet] More NRT

[Paul Koning]

> On May 5, 2020, at 1:21 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
> 
> Thanks Paul,
> 
> As usual, very informative.  What you've verified is Tops-20's monitor based NRT server implementation, which is good.  Therefore, for the moment, I think it reasonable to assume that the monitor client implementation is also not suspect.
> 
> NI1D displayed the same failure mode as Tron: report of a successful connection and then, nothing, viz:
> 
> % Do not have Control-C capability, proceeding...
> Escape character(^Y):
> Host name: NI1D
> [Connecting to remote host: NI1D]
> [Remote system is running RSTS/E]
> [Connected: type ^Y to return to node VENTI2]
> 
> This shows that the client had a successful connection and handed off to the monitor.  This was verified by further investigation (with SYSDPY which showed SETHOST in a WAIT%, pending interrupt from the MTOPR%).  Since the NRT client implementation eventually hands off to the monitor for all the data flow, for Initial investigation, I'll have a look at some that pre-MTOPR% post-connection open logic.  I'll try to do a little more trouble shooting tonight and see what might be happening.

I noticed that the server at my end (the application that answers the NRT connection) had gone into a hard loop.  I restarted it.  

> You mention four 'flavors' (?) of NRT; are these documented anywhere?  (I mean, other than in the code...)

I don't know of any official documentation.  You could use the Linux source code as a reference; that implements all four flavors, I think, and it's probably more readable.  In working on that I did some protocol reverse engineering; I may be able to find the notes for that.

>From the messages you quoted, it looks like SETHOST knows it's talking to a RSTS system, which should mean it knows to speak that protocol, but apparently something goes wrong in there somewhere.  The fact that the RSTS end breaks is of course a bug at that end -- it violates rule 1 of distributed systems, "if your code fails because of a received message, it is always your fault, not the sender's".

	paul