[HECnet] MIM?

[Johnny Billquist]

Hi, Paul. We've had plenty of discussions about this in the past... :-)

On 2018-10-23 17:44, Paul Koning wrote:
> 
> 
>> On Oct 23, 2018, at 10:48 AM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>> On 2018-10-23 15:51, Paul Koning wrote:
>>>> On Oct 23, 2018, at 3:54 AM, Johnny Eriksson <bygg at cafax.se> wrote:
>>>> ...
>>>> If tcpdump knew about this, it would look somewhat like:
>>>>
>>>>   Init, 1.13 info 01 size 576 ver 2/0/0 timer 300
>>>>
>>>> Why MIM decided to restart the link is another question.
>>> I would guess that is a Multinet link, right?  A conforming DECnet implementation would not send an init message without restarting the data link layer first, which would produce a "circuit down" event.  So the unexpected packet type is indeed a reasonable complaint for it to generate.
>>
>> Yes, it's a Multinet link. In addition, it's one carried over TCP, so I'm a bit curious why you would get an init packet here. When the TCP connection was lost, the circuit should have gone down.
>> And you would not be able to get a new init packet before a new TCP connection was established.
>>
>> But then again, I do not properly know how the Multinet implementation works internally, and I have been struggling from time to time to get it all working the right way. So I might also not be doing things in a fully matching manner to what Mutlinet does. If anyone have any knowledge of the internals of the Multinet implementation, I'd love to talk with them.
> 
> I had some traces sent to me a while ago which I used to implement the Multinet over TCP code in pydecnet.  But that doesn't show what the internals of the host looks like.

Same here. And my problems are really about what Multinet might be doing 
internally, as it is not as trivial and straight forward as one might 
hope. Or at least it is not on the RSX side.

> The fundamental error in the Multinet design is that, in the UDP case, it doesn't implement the data link requirements for point to point routing circuits.  In particular, there is no notion of "data link restart", of course.  So my guess would be that your Multinet endpoint doesn't bother with that for TCP either.  The correct implementation would be for a TCP connection reset to trigger a datalink shutdown notification to routing.  If that were done things would work correctly.

Sortof. Yes, there is indeed a problem here related to UDP.
However, at least my code do handle TCP in the sane way you might think 
it should. So RSX DECnet definitely gets a line down notification when 
the TCP connection is lost. And once it is reestablished the line goes 
up and DECnet can renegotiate.
Which is why I am wondering why, on the VMS side, you see an INIT 
message out of sequence. It should only come when the line comes up, 
which naturally should only happen when the TCP connection is established.

So, what is Multinet actually doing here???

As for the UDP case, it's way more tricky, at least on the RSX side, as 
I cannot trivially detect when a link comes up. And RSX DECnet will only 
send one INIT packet when the line comes up. So I need to keep that INIT 
packet internally on my Multinet-side, and retransmit it on a regular 
basis until the other side responds with an INIT packet of its own, at 
which time I can proceed with the relaying of packets between DECnet and 
the remote side, and let the link become established. But that also 
means I need to detect if a new INIT packet happens, since that needs to 
restart the syncing. So at an INIT I need to tell DECnet that the line 
went down, and then up again, so that RSX DECnet will send a new INIT 
packet.

And at startup I need to filter out if I happen to get multiple INIT 
packets, since I only want to deliver one to DECnet.

> I have some comments in multinet.py implying that there is indeed no connection between TCP restart and Multinet restart even in TCP mode.  It's been long enough that I don't remember the details.

That would be interesting to know more of the story behind. I can't see 
how Multinet would not signal a line down when the TCP connection is 
lost. And it would be pretty obvious that the line comes back up when 
the TCP connection is established.

   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