On Aug 17, 2023, at 12:40 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-08-17 18:36, Paul Koning wrote:
On Aug
17, 2023, at 12:25 PM, John H. Reinhardt <johnhreinhardt(a)thereinhardts.org> wrote:
...
I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP. That seems the
most reasonable place to start.
Yes, though DDCMP over UDP also works well;
it's become my default choice.
Say what? Did you think something in reverse here, Paul?
I thought we had agreed that DDCMP over UDP is the worst idea. TCP makes total sense, but
UDP means you can get reordering, duplication and lost packets galore.
Or are you thinking of using something that addds the whole DDCMP protocol on top of UDP?
Doable. Maybe something in PyDECnet I have forgotten?
DDCMP in SIMH and in PyDECnet is the whole DDCMP data link protocol. It handles all those
things you mentioned, though just like any ARQ protocol the performance will drop a lot
if those problems occur at significant rates. BTW, UDP (or more precisely, IP) should not
normally duplicate packets, and reordering may be rare for many topologies.
Maybe you're thinking about an early "DDCMP data service" that was in SIMH,
and existed for a while in PyDECnet. That only works over TCP since it carries the
payload, not the DDCMP protocol messages (DLSDU rather than DLPDU, in
"Internationalbureaucratspeak" as Andrew Tanenbaum phrased it).
The "known very bad" choice is Multinet over UDP. And even Multinet over TCP is
iffy, though I admit that part of the reason I avoid it is on architectural purity
principles -- the people who designed Multinet clearly demonstrated their lack of
interest, or lack of ability, to understand the DECnet protocol specifications. So while,
with some care and feeding, it can be made to operate, it just is not and never can be
"correct".
paul