I'm curious if I understand the suggestions correctly?  If I was to have connections from several DECnet capable machines on my home network connecting to a PyDECnet/HECnet router hosted elsewhere with each one configured to use DDCMP over the slower WAN/VPN link, then any local machine to machine traffic would end up traversing the WAN link twice - that is unless the home systems are configured with multiple circuits?  While I'm sure this is quite possible, I suspect it would be a more complex configuration.  Having a PyDECnet router on the home LAN and just using standard ethernet circuits for DECnet would simplify the configuration for all the local nodes.  You could still have the choice of whether the HECnet destined traffic is routed directly out over the dynamic IP of the home circuit, or the fixed IP of the business circuit (via the VPN)?  Just some thoughts...   :)

Cheers - Brian

On Thu, Aug 17, 2023 at 1:03 PM Johnny Billquist <bqt@softjar.se> wrote:
On 2023-08-17 18:55, Paul Koning wrote:
>
>
>> On Aug 17, 2023, at 12:40 PM, Johnny Billquist <bqt@softjar.se> wrote:
>>
>> On 2023-08-17 18:36, Paul Koning wrote:
>>>> On Aug 17, 2023, at 12:25 PM, John H. Reinhardt <johnhreinhardt@thereinhardts.org> wrote:
>>>>
>>>> ...
>>>>
>>>> I don't have Multinet anywhere (yet) so I will try the DDCMP via TCP. That seems the most reasonable place to start.
>>> Yes, though DDCMP over UDP also works well; it's become my default choice.
>>
>> Say what? Did you think something in reverse here, Paul?
>> I thought we had agreed that DDCMP over UDP is the worst idea. TCP makes total sense, but UDP means you can get reordering, duplication and lost packets galore.
>>
>> Or are you thinking of using something that addds the whole DDCMP protocol on top of UDP? Doable. Maybe something in PyDECnet I have forgotten?
>
> DDCMP in SIMH and in PyDECnet is the whole DDCMP data link protocol.  It handles all those things you mentioned, though just like any ARQ protocol the performance will drop a  lot if those problems occur at significant rates.  BTW, UDP (or more precisely, IP) should not normally duplicate packets, and reordering may be rare for many topologies.

Ah. You were thinking of the full DDCMP over the link. Ok.
But yes, both lost, reordered and duplicated packets in IP are unusual,
but it can happen, for various reasons.

> Maybe you're thinking about an early "DDCMP data service" that was in SIMH, and existed for a while in PyDECnet.  That only works over TCP since it carries the payload, not the DDCMP protocol messages (DLSDU rather than DLPDU, in "Internationalbureaucratspeak" as Andrew Tanenbaum phrased it).
>
> The "known very bad" choice is Multinet over UDP.  And even Multinet over TCP is iffy, though I admit that part of the reason I avoid it is on architectural purity principles -- the people who designed Multinet clearly demonstrated their lack of interest, or lack of ability, to understand the DECnet protocol specifications.  So while, with some care and feeding, it can be made to operate, it just is not and never can be "correct".

I was more thinking of the latter. But it was probably a bit of mixum
from my side. Multinet pretends to be DDCMP, but don't actually do
DDCMP. Which is where things go bad.

   Johnny

--
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se