1 Apr
2021
1 Apr
'21
8:15 p.m.
On 2021-04-01 02:04, Paul Koning wrote:
Yeah. Multinet pretending to be PtP using UDP is just plain broken. It
should have been obvious to everyone.
And I agree that the most likely explanation why the TCP alternative
seems broken would be because they just extended their UDP solution,
which was a hack to start with.
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 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. On Mar
29, 2021, at 2:25 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2021-03-28 23:08, Paul Koning wrote:
>> 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.
If that were done by the other implementations things would indeed be
ok.