From my POV having NCP only on a node where pyDECNET runs is not a huge limitation. As it is in line with what we have today, I can only run NCP on RSX, VMS, etc. where I have DECNET running as well so that matches the current behavior for me.

 

Mike

 

Sent from Mail for Windows

 

From: Paul Koning
Sent: Wednesday, March 2, 2022 06:31
To: Dave McGuire
Cc: HECnet
Subject: [HECnet] Re: PyDECnet T1.1 beta 2

 

 

 

> On Mar 2, 2022, at 12:58 AM, Dave McGuire <mcguire@neurotica.com> wrote:

>

> On 3/1/22 20:16, Paul Koning wrote:

>> Question for PyDECnet users: as I mentioned, there's a new API, cleaner than the old one.  A major addition is access to the Session Control layer, in other words external programs can talk to the API to use DECnet communication services, inbound or outbound.  This is how I implemented a simple subset NCP and NFT.

>> That API runs over a Unix domain socket, in connection mode.  It's quite similar to TCP but inherently local to the machine where PyDECnet is running.  That's nice for security, of course.  But on the other hand, it means that there isn't a way for a PyDECnet running on one machine to offer a portal into DECnet for nearby machines.  If you keep a DECnet router in the basement, your laptop can't run NCP since it has no access to that socket.

>> It would not be all that difficult to add an option for running that same API over a TCP port, possibly with some sort of access filtering.  Is there interest in such a thing?

>

>  I'm not a PyDECnet user yet, but I will say this, remote manageability is almost always a good thing.

 

True.  That's not exactly what I meant, though.

 

On the one hand, remote viewing of management type state is already around and has been for a while.  There's NML support, so you can ask a PyDECnet node questions about its state via NCP.  There is also web based status info; you can see this at the HECnet map server.  None of that offers manageability in the sense of remotely *changing* things, and at the moment I'm not working on that.

 

The API I was talking about offers some of the same capabilities as NML, but its more sigificant function is to let you open and use DECnet NSP (session control) connections.  So if I bring up a PyDECnet node on my laptop I can then run NCP on that same laptop, and connect to HECnet nodes via the API to ask them things.  Ditto with NFT, and potentially other protocols like CTERM or whatever else anyone may want to implement.  Requiring the application to be on the same host as a PyDECnet node is a bit of a limitation.  For what I do it isn't a big concern, but I was wondering if others would want to be able to run things like NFT or NCP on a host different from where the PyDECnet instance is active. 

 

                paul

 

_______________________________________________

HECnet mailing list -- hecnet@lists.dfupdate.se

To unsubscribe send an email to hecnet-leave@lists.dfupdate.se