28 Mar
2021
28 Mar
'21
11:08 p.m.
On Mar 28, 2021, at 4:40 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-03-28 22:10, Paul Koning wrote:
That list was pulled out from the actual DECnet/RSX sources. It's not any arbitrary,
or generic description of DECnet or links, but trying to tell you what is in RSX.
Sorry, I wasn't clear what I meant. The comment was not directed at the list you gave
but a general observation about data link layer protocols.
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. ...
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.
Technically, TCP should work just fine. But yes, Multinet even have some funny specific
behavior making even TCP a bit tricky. It's really annoying how they seem to have gone
out of their way to make it harder. But we've talked about this before.
There are two ways to make a "data link similar to Multinet that actually
works". One is to run it over TCP and include some mechanism to deliver the
"restart detection" requirement. The other is to run it over either TCP or UDP
and call it a broadcast link, i.e., a GRE lookalike.
The former would be vaguely like the old "DDCMP emulation" in SIMH 2.9 that I
once had in PyDECnet but removed -- the one that sends DMC payloads over TCP. That might
be worth doing if people were interested in deploying it. I could dust of that old code
to serve as the template to follow.
The latter would be like GRE, but it wouldn't really do anything that GRE doesn't
do just as well so there wouldn't be a whole lot of point in it.
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.
Right.
And we can't do it anyway, since the existing VMS implementation is the way it is,
and won't change.
If I want to, I could do something on the RSX side which would be more appropriate, and
you could obviously do that also in PyDECnet. But we'd still have to deal with the
broken VMS ways...
But I wouldn't actually model it according to ethernet. For a TCP connection, a ptp
link is the perfect way to look at it.
And I wouldn't probably use UDP at all. But if I would, then yes, it would be
modelled as a broadcast link, even though there would only ever be two points to it.
...
True, and if it weren't for the fact that SIMH set the rule differently that's
what I would have done.
Actually, the SIMH implementation, and therefore
the PyDECnet one, does not do so. That's different from Multinet, which comes with a
connect vs. listen setting. In the case of DDCMP, both endpoints connect and both listen.
If a connection is made the other pending one is abandoned. If both connections are made
at essentially the same time, things get a bit messy, which is why I don't really like
this technique.
Yeah. I wouldn't do it that way. That is ugly.
Better to designate one as the connector and the other as the listener. I mean, really. This was already regarded in that same
way already in the real world back then. Dial up modems as well as X.25 are the exact same
type of thing.
Both sides cannot initiate the connection. One is the initiator, and the other the one
accepting the connection.
X.25 requires it because it has what many of us consider a protocol design error, 2-way
connection handshake. DDCMP (and others) uses a 3-way handshake and deals just fine with
simultaneous startup. The only reason the SIMH scheme has a problem is that you don't
want to have two connections remain open. But you can see that DDCMP doesn't mind
from the fact that over UDP it has no problem with simultaneous startup. The rules of the
startup state machine explicitly cover that case.
paul