28 Mar
2021
28 Mar
'21
10:10 p.m.
On Mar 28, 2021, at 3:33 PM, Johnny Billquist <bqt
at softjar.se> wrote:
...
And at least in RSX, there is no generic "point-to-point" type of link.
The types that exist are:
. DDCMP
. Bisync
. SDLC/ADCCP/HDLC
. X.25
. Ethernet
. Hardware protocol
Where hardware is a bit like just saying that the hardware does something, and it's
good enough. No software required, and it will work.
But all except ethernet are more or less point-to-point. But DDCMP can also be used for
multidrop connections. The others would imply point-to-point, but will have possibly have
different other software layers added to handle the specifics of that link protocol.
It's certainly possible to define any number of data link types, with a wide variety
of services. Some are useable with DECnet, others are not.
DECnet puts data links into two categories, from the point of view of the routing layer:
"point to point" and "broadcast". Those names are deliberately
generic, but a good way to think of them is "like DDCMP" and "like
Ethernet". DECnet also specifies what services it requires from the data link layer,
for each of these two subtypes.
For broadcast, Ethernet, FDDI, 802.11, and 802.4 all meet the requirements. 802.5 does
not because of its bogus addressing and bad implementation of multicast, but there is a
modified version of Phase IV (called "IV prime") that was hacked to make it work
with 802.5.
For point to point, DDCMP and X.25 are both DNA standard and work. Among the others you
mentioned, I would think that Bisync and SDLC/HDCL/ADCCP would work since they have
comparable semantics. "Hardware" does not appear to meet the stated
requirements, not unless it has some sort of control wires like the modem control signals
of RS-232 to deliver the "restart detection" requirement.
Then there is GRE, which was done as a broadcast datalink but differs in that it
doesn't have addresses. It works reasonably well because for a two-station connection
you can live without having real addresses. It does have the Ethernet protocol type
field; living without that would be more painful though in theory still possible.
Multinet is quite another matter. It claims to be a point to point datalink, but it
doesn't obey any of the clearly written requirements of a point to point datalink.
That failure to conform is the reason it doesn't work right. In the UDP case that is
more obvious, but both versions are broken, it's just that the TCP flavor doesn't
show it quite so often.
It would have been easier and far more correct to model the Multinet datalink as a
broadcast link, just like GRE did. Unfortunately we can't do that unilaterally
because the routing layer behavior for those two subtypes is different -- different hello
protocols and different data packet headers. So we're stuck with the bad decision the
original fools made.
And in my case, I chose to claim to DECnet that the
Multinet links are DDCMP, but without having a software DDCMP layer required. But that was
just because I had to pick something in RSX. And this adds to my occasional confusion
about DDCMP and DECnet link management.
I understand, and that makes sense.
DDCMP is en
entirey different beast. It provides that reliable data link, and it sits on top of an
unreliable physical layer. It handles packet loss mostly because it handles bit error,
which causes packet CRC error and is handled by timeout and retransmit ("ARQ").
Right. Well... It handles transmission errors through CRC. It handles packet loss also by
using sequence numbers for packets. (Otherwise, a fully lost packet would not be detected.
CRC don't spot such things.) ...
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.
No. It's certainly ok to use
DDCMP over TCP -- except that it has to deal with the oddity of doing both connect and
listen concurrently. But UDP works fine.