3 Mar
2026
3 Mar
'26
5:42 p.m.
On 03/03/2026 15.58, Paul Koning wrote:
Ah. I had the broken understanding that DDCMP also restarted at that
point. Ok, so it resyncs and gets back in order on its own? That's nice.
I haven't looked at DDCMP in years...
Johnny
On Mar 3, 2026, at 4:40 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 03/03/2026 03.22, Paul Koning wrote:
DDCMP will notice and handle out of order packets, but it still means it have to restart
the circuit, so UDP in this case is still not a great idea. The better option would be to
use the same datalink mode/protocol as ethernet does, which is designed for the occasional
dropped packet or out of order packet.
Not true. DDCMP does not restart the link on out of order packets. Instead, it drops
the out of order packet, and then timeout of the ACK willcause it to be retransmitted.
On Mar 2,
2026, at 7:23 PM, Johnny Billquist <bqt(a)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 -- atleast 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.