29 Mar
2021
29 Mar
'21
8:25 a.m.
On 2021-03-28 23:08, Paul Koning wrote:
I'm not sure what you think the problem is here. This would be
interesting to explore.
Restart notification, in my ears, seems to be about informing DECnet if
the link had to be restarted. Which, I would say, obviously can be done
with Multinet over TCP, because this is detected/handled by TCP just
fine. And if the TCP connection is lost, all you need to do is just
inform DECnet that the link went down. And I do exactly that with TCP
connections.
What else is there, that you think is a problem?
My problem, on the other hand, is that Multinet isn't just setting up
the TCP connection, and then let things run. Multinet seems to
explicitly want also one side to be the first to start communicating,
and seems to drop packets if things don't happen in the order Multinet
thinks they should happen. Which is really annoying, since DECnet should
just be let alone to sort it out. So I've had to start trying to play
more like Multinet, designating one as the active, and the other as the
passive, and at connection time, delay signalling based on this, in
order to play nicely with VMS.
Well, your restart mechanism is something I do not understand.
I would just run the TCP connection straight as it is. If the connection
is closed, for whatever reason, this should be signalled to DECnet just
like DDCMP signals link errors, and when the connection is established,
data just flows again.
It should work just fine without any further stuff. This is pretty close
to what I do today, with the unfortunate extra fluff required since
Multinet don't like if the "wrong" side talks first.
So much baggage...
This led me to realize that Multinet more or less tries to do a 2-way
handshake.
But sure, X.25 is nobodys favorite. :-D
Johnny
--
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
On Mar 28, 2021, at 4:40 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2021-03-28 22:10, Paul Koning wrote:
No, technically Multinet TCP does NOT work fine. The issue is that Multinet, whether
over TCP or over UDP, fails several of the requirements imposed on point to point
datalinks by the DECnet routing spec. In particular, it fails the requirement of
"restart notification". In the TCP case, it can be hacked to make it work most
of the time, but architecturally speaking it's flat out wrong.
The issue is that there is more to a point to point datalink that merely delivering a
packet stream from point A to point B. That's the main job, of course, but that by
itself is not sufficient in the DECnet architecture. On Mar
28, 2021, at 3:33 PM, Johnny Billquist <bqt at softjar.se> wrote:
... 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. 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.
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.
I would not send DMC payloads. Seems like an unnecessary extra
step/layer with no added value.
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.
GRE basically just encapsulate ethernet packets anyway. (Yes, I know it
can encapsulate other things, but anyway...)
...
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.