17 Aug
2023
17 Aug
'23
8:05 p.m.
Correct.
And I agree, why would you ever want to have your "central" router
located somewhere else, and have individual links from every machine to
there. Makes no sense.
Ethernet for the local network. One router (or maybe a couple) on the
local network that provides links to the rest of HECnet.
Johnny
On 2023-08-17 19:25, Brian Angus wrote:
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
<mailto:bqt@softjar.se>> wrote:
On 2023-08-17 18:55, Paul Koning wrote:
--
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
> On Aug 17, 2023, at 12:40 PM, Johnny Billquist <bqt(a)softjar.se
<mailto: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(a)thereinhardts.org
<mailto: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(a)softjar.se <mailto:bqt@softjar.se> ||
Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se