28 Mar
2021
28 Mar
'21
9:33 p.m.
On 2021-03-28 15:48, Paul Koning wrote:
Yes. You are right.
The thing is, Multinet claims to DECnet that it is a some kind of
point-to-point link. But it's not actually DDCMP. My fault.
But it expects the same kind of service from the link as DDCMP will
provide, which is where the problem is.
Right. My bad. I was totally mixing up DDCMP with the DECnet routing
layer and link managment.
As far as using TCP, that comes down to the problem of how to establish
the link in the first place. It's outside of DDCMP itself, and is no
different than if you were to run DDCMP over a dial up line. Only one
side is supposed to dial the number, while on the other side you would
be answering the incoming call.
But yes, you need some way to tell which end should be listening, and
which end should do the connecting.
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 Mar 27, 2021, at 2:54 PM, Johnny Billquist
<bqt at softjar.se> wrote:
Paul and me have lamented over this many times.
DDCMP assumes that the underlying transport mechanism is reliable. Both in terms of the
ordering of data, the reliability of getting all data across, and no duplication, and so
on...
UDP does basically not fulfill any of these requirements, making UDP a very unsuitable
transport for DDCMP links.
No, you're confusing DDCMP and Multinet. Multinet isn't a datalink protocol; it's
merely a wrapper for the routing layer packets. In particular, it wraps routing layer
point-to-point sublayer packets. THAT assumes a reliable data link.
Well, Multinet is actually a data link protocol. Just as DDCMP is. But
it is not DDCMP, my bad.
The Multinet link layer is rather simple, though. As you know. If using
UDP, there is a sequence number to each packet, and with TCP it just
have a framing with length information.
The rest just pass through without any further processing. But multinet
do not try to actually deal with loss and retransmission anyway, so that
sequence number is of limited use. (Not sure if it is actually used at
all by the VMS Multinet.)
And at least in RSX, there is no generic "point-to-point" type of link.
The types that exist are:
. DDCMP
. Bisync
. SDLC/ADCCP/HDLC
. X.25
. Ethernet
. Hardware protocol
Where hardware is a bit like just saying that the hardware does
something, and it's good enough. No software required, and it will work.
But all except ethernet are more or less point-to-point. But DDCMP can
also be used for multidrop connections. The others would imply
point-to-point, but will have possibly have different other software
layers added to handle the specifics of that link protocol.
And in my case, I chose to claim to DECnet that the Multinet links are
DDCMP, but without having a software DDCMP layer required. But that was
just because I had to pick something in RSX. And this adds to my
occasional confusion about DDCMP and DECnet link management.
DDCMP is en entirey different beast. It provides that
reliable data link, and it sits on top of an unreliable physical layer. It handles packet
loss mostly because it handles bit error, which causes packet CRC error and is handled by
timeout and retransmit ("ARQ").
Right. Well... It handles transmission errors through CRC. It handles
packet loss also by using sequence numbers for packets. (Otherwise, a
fully lost packet would not be detected. CRC don't spot such things.)
...
But as far as DDCMP goes, you should essentially not use UDP as a transport. That is just
bad. Use TCP instead. And then you're good.
No. It's certainly ok to use DDCMP over TCP -- except that it has to deal with the
oddity of doing both connect and listen concurrently. But UDP works fine.