17 Aug
2023
17 Aug
'23
7:25 p.m.
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(a)softjar.se> wrote:
On 2023-08-17 18:55, Paul Koning wrote:
> On Aug 17, 2023, at 12:40 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
>
> On 2023-08-17 18:36, Paul Koning wrote:
>>> On Aug 17, 2023, at 12:25 PM, John H. Reinhardt <
johnhreinhardt(a)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(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se