27 Mar
2021
27 Mar
'21
7:54 p.m.
Paul and me have lamented over this many times.
DDCMP assumes that the underlying transport mechanism is reliable. Both
in terms of the ordering of data, the reliability of getting all data
across, and no duplication, and so on...
UDP does basically not fulfill any of these requirements, making UDP a
very unsuitable transport for DDCMP links.
TCP, on the other hand, perfectly match these requirements.
Unfortunately, Multinet is basically using UDP as a transport for a
DDCMP link. Which is obviously bad and wrong. Multinet can also use TCP,
in which case you're good.
My bridge implementation is carrying DECnet traffic as well, but is then
appearing no different than an ethernet link, in which delivery is no
longer guaranteed. And there I use UDP, and in this case, it does make
sense. DECnet over ethernet behaves differently than DECnet over DDCMP.
(The bridge have a scaling problem on the other hand, so you don't want
the bridge to span a too larger virtual ethernet, since a lot of traffic
will go everywhere.)
But as far as DDCMP goes, you should essentially not use UDP as a
transport. That is just bad. Use TCP instead. And then you're good.
Johnny
On 2021-03-27 11:40, Keith Halewood wrote:
Hi,
I might have posted this to just Paul and Johnny but it?s probably good
for a bit of general discussion and it might enlighten me because I
often have a lot of difficulty in separating the layers and
functionality around tunnels of various types, carrying one protocol on
top of another.
I use Paul?s excellent PyDECnet and about half the circuits I have
connecting to others consist of DDCMP running over UDP. I feel as though
there?s something missing but that might be misunderstanding. A DDCMP
packet is encapsulated in a UDP one and sent. The receiver gets it or
doesn?t because that?s the nature of UDP. I?m discovering it?s often the
latter. A dropped HELLO or its response brings a circuit down. This may
explain why there?s a certain amount of flapping between PyDECnet?s
DDCMP over UDP circuits. I notice it a lot between area 31 and me but
but much less so with others.
In the old days, DDCMP was run over a line protocol (sync or async) that
had its own error correction/retransmit protocol, was it not? So a
corrupted packet containing a HELLO would be handled at the line level
and retransmitted usually long before a listen timer expired?
Are we missing that level of correction and relying on what happens
higher up in DECnet to handle missing packets?
I?m having similar issues (at least on paper) with an implementation of
the CI packet protocol over UDP having initially and quite fatally
assumed that a packet transmitted over UDP would arrive and therefore
wouldn?t need any of the lower level protocol that a real CI needed. TCP
streams are more trouble in other ways.
Just some thoughts
Keith
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol