3 Mar
2026
3 Mar
'26
3:22 a.m.
On Mar 2, 2026, at 7:23 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2026-03-02 19:00, Paul Koning wrote:
...
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
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.