But the biggest difference for me was that record boundaries survived the stream so all the “how am I going to frame this data” part of protocol design was already handled. You got to skip all the “newline delimits, except if you escape it, or maybe a CR counts or maybe it is ignored, or only ignored if next to a NL”, or its evil twin “a two byte integer precedes the data, in a byte order that might be reversed or not and if your machine is in the right order you will never realize you missed or included an extra byte order reverser”.
And more a VMS specific DECnet feature, all IO had completion routines so for high efficiency servers it was a lot like programming in a modern async environment with “.then()” style. (Thought they ran at an interrupt level rather like signal delivery in Unix, so you had to be a little careful. )
As someone that used to work as a network engineer supporting IP, IPX, DECnet, Vines IP, and SNA over Ethernet, token ring, arcnet, FDDI, ATM, 100VG-Anylan, X.25, frame relay, ISDN and a variety of dedicated circuit types I am grateful that IP and Ethernet have killed almost everything else off. The network protocols were not always easy to have living together on the same network.
You can do that with IP as well (just not the 'well known' ports <1024).
> But the biggest difference for me was that record boundaries survived the stream so all the “how am I going to frame this data” part of protocol design was already handled.
You might want to look into RPC for IP then instead of HTTP.
> DECnet is a suite of network protocols created by Digital Equipment Corporation. Originally released in 1975 in order to connect two PDP-11 minicomputers, it evolved into one of the first peer-to-peer network architectures
