It's actually the Linux DECnet suite, all running as part of the user process on the
(OpenBSD) host, as part of the Multics FNP simulation - new incoming CTERM connections
(yes, using the essentially unmodified Linux DECnet implementation) are treated as dial-in
connections over simulated serial lines ... the whole thing is rather odd, but essentially
the setup is the same way a foreign network of this type would would have been accessed
via protocol converters on real iron.
There surely are still bugs of my own, especially in the part creates Ethernet frames and
provides a TAP interface. I know there are some ways to make the whole thing crash that
don't happen in the Linux code, but those situations are impossible to trigger by end
users.
Unfortunately, it seems the particular bug I'm looking for exists in the original
Linux DECnet as well, so it's in code I'm not overly familiar with and probably
haven't even looked at.
None of those issues are related to performance, however. I'm going to actively
investigate moving to that Python-based DECnet implementation at some point in the future.
There is also the possibility of a hardcore/ring-0 based implementation in the further
future as well, provided I continue to get more comfortable with PL/I - such an
implementation would be able to be more efficient.
Right now, however, my main concern is it being a good citizen on the network.
--
Jeffrey H. Johnson
jhj at
trnsz.com
https://ban.ai/multics