On Feb 24, 2020, at 8:01 PM, G. <gerry77 at
mail.com> wrote:
On Mon, 24 Feb 2020 19:28:41 -0500, Paul Koning wrote:
Multinet over UDP is especially evil. Multinet
over TCP isn't quite as bad,
so if you must use Multinet, be sure to use the TCP flavor.
However, anything else is better. GRE and Johnny's bridge software are two
good options. Another one, if you use SIMH, is to use a DDCMP connection.
If I'm not wrong, Multinet over UDP does not work well at all because it
makes use of a point-to-point connection which in turn implies an underlying
error-free link that UDP could not actually offer.
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.
GRE avoids this issue by acting as a broadcast (LAN-like) link, which has simpler
requirements that GRE indeed meets. And DDCMP, of course, also works correctly because
its data link layer delivers the necesary signals up to the routing layer.
paul