[HECnet] Old protocols in new ones

[Johnny Billquist]

On 2021-04-01 02:04, Paul Koning wrote:
> 
> 
>> On Mar 31, 2021, at 5:42 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>>
>>
>> On 2021-03-31 23:01, Paul Koning wrote:
>>>> 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.
>>
>> [...]
>>
>> 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.

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