1 Apr
2021
1 Apr
'21
2:04 a.m.
On Mar 31, 2021, at 5:42 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-03-31 23:01, Paul Koning wrote:
[...]
Ah. Now I understand you. Basically, the actual VMS Multinet implementation is the
problem. Not running DECnet over TCP as such.
Then I fully agree with you. The VMS Multinet is just strange. And you mentioned another
thing that I have also observed. If the TCP link goes down, it appears as if the VMS side
actually don't get a circuit down, and then things behave strange when the link comes
up, with init packets coming at strange points. This all leads to it taking longer than I
would expect should be required to reestablish the link when VMS Multinet is involved.
That's why I said "Technically Multinet over TCP should work fine".
It should work fine, but in reality it don't because VMS Multinet is doing strange
things for no good reason (that I can figure out). Had they just used what TCP provides,
and signaled the information to DECnet, it would have worked without a hitch.
Yes. And furthermore, Multinet over UDP cannot possibly do it right. My hypothesis for
why the TCP mode does this "strange thing for no good reason" is because it
simply follows the broken UDP model, and does so because the authors had no clue that what
they did was wrong.
A lot of DECnet is simple and obvious. A few parts are subtle and not so obvious, but
important. One example I had pounded into my head early on is the bit of strangeness
called the "subroutine check" in the routing spec. It basically translates to
"it is very important to remember which node you are; if you ever mess that up the
network is in deep trouble. So make extra sure and verify periodically that you still
have this correct."
paul
On Mar
29, 2021, at 2:25 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2021-03-28 23:08, Paul Koning wrote:
If that were done by the other implementations things would indeed be
ok. > On Mar 28, 2021, at 4:40 PM, Johnny Billquist
<bqt at softjar.se> wrote:
>
> ...
> Technically, TCP should work just fine. But yes, Multinet even have some funny
specific behavior making even TCP a bit tricky.
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.
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.