[Info-vax] VMS process communication

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Tue Sep 13 16:41:55 EDT 2022


On 2022-09-13 09:29:19 +0000, Bob Gezelter said:

> As has been observed, mailboxes are not included.
> 
> DECnet Task-to-Task would also make a useful addition. While DECnet 
> does not include encryption, an omission that I have been quietly 
> outraged by for decades, when tunneled over an encrypted IP tunnel OR 
> used locally, it is quite useful. DECnet logical links are 
> message-based, unlike stream-based TCP sockets, which does simplify 
> programming to an extent.
> 
> Both network-based techniques have a significant synchronization 
> advantage over shared memory techniques. When either partner of a TCP 
> socket or a DECnet logical link exits, the corresponding partner is 
> automatically notified, allowing the appropriate steps to be taken. 
> Detecting a failed correspondent is far more complex with shared memory 
> techniques. Network links are also atomic. A message is sent or not, 
> there are no partial messages. Shared memory approaches have the 
> inherent danger that an update may be incomplete, corrupting the shared 
> data structure.
> 
> My normal recommendation has been to implement using message-passing 
> techniques, unless one can conclusively demonstrate that the 
> performance increment achieved by shared memory can be justified.

Network message-passing and shared-file communcations code is usually a 
win, as it's common code for either local operations or for local and 
remote operations, and it avoids all the "fun" with shared memory cache 
coherency. If the performance of shared memory is necessary, it's best 
treated as an add-on or an addition to network transfers.

OpenVMS lacks any sort of consistent communications API, with a whole 
box of easy-to-make-mistakes some-assembly-required parts including 
mailboxes, DECnet and IP, shared memory, DCE RPC and (IIRC) SunRPC, the 
ever-popular TLS, intracluster communications services, IRPs and ACPs, 
shared files, a couple of different message-passing add-on frameworks 
including MQTT, etc.

Missing features here include IP and TLS integration with DCL and with 
OpenVMS more generally, and preferably with frameworks intended to deal 
with communications including IPv4 and IPv6, DNS, and with UDP, TCP, 
QUIC, etc., support for REST, and the rest. Writing this code for 
OpenVMS really reminds me of writing assembler. It's absolutely 
possible to write this stuff for OpenVMS (including writing that code 
in now-compiled VAX assembler), but other platforms abstract all this 
for the developer. Which makes this stuff easier and faster to deploy, 
and with fewer mistakes.

And preferably with connection security, data encryption, logging, and 
authentication—that might not be necessary entirely locally, but I've 
seen more than a few of these local YOLO pre-Y2K designs re-used for 
remote connections, and where sadness ensued.

I've seen more than a few mistakes made with mailbox and DECnet and IP 
communications, too. Mailboxes and DECnet and IP all have a 
backpressure design which ~everybody gets wrong when they first 
encounter it in production, too. Voice Of Experience: do NOT leave a 
session in the debugger and head out to lunch.

And eightcubed has a wealth of source code examples.




-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list