On Mar 2, 2020, at 1:56 PM, Robert Armstrong <bob
at jfcl.com> wrote:
First of all, unless PyDECnet is somewhat
limited, it should be fine
using the standard Multinet port for all incoming connections
I don't see how you can have multiple Multinet TCP connections all listening on port
700 at the same time. Yes, you can have multiple outgoing connections all to port 700 on
some remote machine, but that's not the same. And for UDP it's no problem for
everybody to share the same port, but again that's not the same.
Bob
PyDECnet right now has a listening port per circuit, and allows one connection on that (of
course, since circuits are point to point). The "any address allowed" case just
means that at connect time the connection will not have its remote address checked.
That said, as Johnny points out, it's certainly possible to have a design where a
listener socket accepts several connections, associating those with several circuits.
That would translate into "multiple connections to a given listener port". By
TCP rules, connections are identified by a "five-tuple" (source and dest IP
address, IP protcocol, and source and dest port numbers). So that all works.
I could have PyDECnet feed connections into a pool of circuits, or have circuits created
on the fly up to some limit, but neither of these options is in the current design.
Going back to the security discussion, I think "node verification" (the password
exchange that optionally happens at the point to point initialization handshake in DECnet)
would be adequate. All the DEC products have this in one way or another, as does PyDECnet
(though the documentation is not really there, I should fix that). The one complication
is that while the protocol is standardized, the management of it isn't, so each DECnet
has its own way of doing it.
paul