26 Feb
2020
26 Feb
'20
2:33 a.m.
On 2020-02-25 02:17, Paul Koning wrote:
I'm signalling to the DECnet layer when a TCP connection is established
or lost. So it's not impossible to do this.
However, Multinet is doing weird things, which I think are carryovers
from their UDP implementation. Which means I have to do some really
strange stuff in order to properly interoperate with VMS Multinet from
RSX. As an alternative, I can run TCP links in the more straightforward
form as well, which is way simpler and makes more sense.
But that obviously only works against other RSX systems. Might be that
it could also work towards PyDECnet, or else this would at least be easy
to implement.
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
On Feb 24, 2020, at 8:01 PM, G. <gerry77 at
mail.com> wrote:
Probably I'm missing something else, but wouldn't the TCP flavor be of
comparable reliabilty to other solutions, given that TCP would present to
the point-to-point link a dependable error-free path?
It would be possible to build something similar to the Multinet protocol, over TCP, that
is architecturally correct. But what Multinet actually does isn't, so no, it does NOT
provide reliability comparable to other solutions.
Take a look at the DECnet routing layer spec, the list of requirements it gives for
"point to point data links". That's what Multinet pretends to be, but it
fails to implement many of the stated requirements.
For the TCP case, a correct design would tell the routing layer about the establishment
of a new connection and the loss of that connection. Multinet does not do this. So the
synchronization services that Routing expect the data link to provide are missing.