On 2025-07-16 18:42, Johnny Billquist wrote: I've been aware of the MultiNet implementation since it was known as Phase-IP during its field test. I can't speak to the specific reasons for the design decisions TGV made back then. I'd assume that they did it that way so that DECnet itself could handle both routing (packet comes in via TCP/IP, goes back out over a synchronous link) and do all of the validation / retry / whatever stuff in DECnet. Remember, this was before Phase V reared its ugly head. We had (at least) CMU/Tek, MultiNet, TCPware and Wollongong all competing with each other (and with UCX once it reared its ugly head). Having said that, MultiNet is an odd mishmash of a thin layer of VMS veneer on top of other code that looks vaguely TOPS-ish - the "?Not confirmed" stuff, the fact that ^Z doesn't exit in a lot of places, and so on. It had the UCXDRIVER and UCX emulation library so that things that depended on DEC C library networking routines would still work*, like X11 transport over IP. PMDF also has the same sort of weirdnesses, even though it originated elsewhere. Both PMDF and MultiNet are developed/supported by Process Software. This also led to what essentially amounted to forks of BIND, SSH, etc. as none of the MultiNet changes were accepted upstream. MultiNet was still running BIND 4.9.7 long after the rest of the world moved on, for example. When Process took over MultiNet from TGV, apparently large portions of the code are the equivalent of the famous Dennis Ritchie "You are not expected to understand this". I was tasked with building an IP cluster of Itaniums for a client and asked Process how to set it up from scratch, and they said "We have no idea, everybody we know of was replacing UCX", so I had to figure it out for myself as I didn't want to install UCX just to re- place it with MultiNet immediately after doing CLUSTER_CONFIG. That project was eventually abandoned as the RX2620s were some of the most unreliable, power-hungry pieces of <bleep> I'd ever run into. Major components failed and needed to be replaced during development. That project is now running on a single rx2800. * For quite some time MultiNet provided its own C header files which would be #include-ed in user source to directly call the rel- evant MultiNet library functions directly. At some point, they got rid of those and now use the normal C library functions. This has broken quite a bit of SIG tape software and I'm slowly slogging through it (starting with my own packages) to get stuff working with the DEC C library routines.