[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