On Mar 2, 2026, at 7:23 PM, Johnny Billquist <bqt@softjar.se> wrote:
On 2026-03-02 19:00, Paul Koning wrote:...Did you really mean that you have a Multinet header followed by a DDCMPheader? Or did you just mean that you use the point to point datalink dependent routing sublayer, passing it the Multinet payload or the DDCMP payload depending on which datalink is used? That second option is what Iwould expect, and for Multinet over TCP will work tolerably well -- at least if you use disconnect and reconnect at the TCP layer to do the datalink reinitialization that's a required point to point service the Multinet "designers" didn't bother to implement.
The latter. Sorry.But just to point out something else that should be somewhat obvious - multinet over TCP is better than DDCMP over TCP. You don't need the DDCMP layer processing, since TCP is already guaranteeing what DDCMP otherwise provides. So using DDCMP just adds extra processing and bytes to transfer compared to Multinet, without any actual gain.
Mostly true, for DDCMP over TCP. DDCMP also runs very well over UDP, and typically set it up that way.
As I mentioned, one datalink layer service the routing layer requires is notification of remote restart. DDCMP does that, Multinet doesn't. At least, not unless it passes an underlying restart of the TCP connection up to routing. PyDECnet does that, I don't know if VMS or RSX do. The fact that Multinet over UDP doesn't (can't) do it is the main defect; it means that a restart of one side messes up the other, potentially for a long time, because the routing init handshake falls apart without the datalink layer support.
paul