3 Mar
2026
3 Mar
'26
3:58 p.m.
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 will cause it to be retransmitted.
paul
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. 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.