25 Feb
2020
25 Feb
'20
3:44 a.m.
I would not recomend DDCMP over TCP, as you have no idea what the
TCP implementaion does for timers etc and TCP is streams, you need
to identify the packet boundaries.
DDCMP over UDP gives DDCMP full control over retransmit timers etc
for making the connection reliable and what the actual netwrk is doing
is visible to the DDCMP layer.
-P
25 Feb
25 Feb
3:31 p.m.
On Feb 24, 2020, at 9:44 PM, Peter Lothberg <roll
at Stupi.SE> wrote:
I would not recomend DDCMP over TCP, as you have no idea what the
TCP implementaion does for timers etc and TCP is streams, you need
to identify the packet boundaries.
DDCMP over TCP has been part of SIMH for quite some time.
The stream nature is not an issue, of course. DDCMP over wires also has a stream physical
layer and knows how to do packet framing perfectly well. The answer is the same in both
places: header CRC framing.
DDCMP over UDP gives DDCMP full control over
retransmit timers etc
for making the connection reliable and what the actual netwrk is doing
is visible to the DDCMP layer.
That's true. Then again, DDCMP does not have any congestion control or timer
adjustment or other things that are useful when sending frames over IP network as opposed
to fixed delay wires that don't congest.
As I mentioned, if you have PyDECnet at both ends, you can use DDCMP over UDP. If
you're using SIMH, you're limited to what it implements, which is DDCMP over TCP.
paul
3:43 p.m.
On Tuesday, February 25, 2020 at 6:31 AM, Paul Koning wrote:
It is not merely TCP:
PDP-11 simulator V4.0-0 Current git commit id: 146f05d1
sim> help dmc attach
Device DMC is currently disabled
DMC device attach commands:
DMC help. Type <CR> to exit, HELP for navigation help
Attach
The device must be attached to a receive port, use the ATTACH command
specifying the receive port number.
sim> ATTACH DMC0 port
The Peer host:port value must be specified before the attach command.
The default connection uses TCP transport between the local system and
the peer. Alternatively, UDP can be used by specifying UDP on the
ATTACH command:
sim> ATTACH DMC0 port,UDP
DMC Configuration?
The commits that added this help (and the related functionality) were in late 2013.
- Mark
On Feb 24,
2020, at 9:44 PM, Peter Lothberg <roll at Stupi.SE> wrote:
I would not recomend DDCMP over TCP, as you have no idea what the TCP
implementaion does for timers etc and TCP is streams, you need to
identify the packet boundaries.
DDCMP over TCP has been part of SIMH for quite some time.
The stream nature is not an issue, of course. DDCMP over wires also has a
stream physical layer and knows how to do packet framing perfectly well. The
answer is the same in both places: header CRC framing.
DDCMP over UDP gives DDCMP full control over
retransmit timers etc for
making the connection reliable and what the actual netwrk is doing is
visible to the DDCMP layer.
That's true. Then again, DDCMP does not have any congestion control or timer
adjustment or other things that are useful when sending frames over IP
network as opposed to fixed delay wires that don't congest.
As I mentioned, if you have PyDECnet at both ends, you can use DDCMP over
UDP. If you're using SIMH, you're limited to what it implements, which is
DDCMP over TCP. 
4:29 p.m.
FWIW, on LEGATO I currently have 8 defined Multinet DECnet links. Three
are TCP and the rest are UDP. Historically I've had 18 different remote
links, although not all were in use at the same time. Again, some were TCP
and some UDP.
The TCP and UDP links both exhibit the occasional "adjacency down" then
"adjacency up" behavior. I haven't analyzed the relative frequency, but I
can conclusively say that TCP doesn't fix the problem, at least for
Multinet. I don't see it as a serious problem, although it is an annoyance.
Searching my OPERATOR.LOG files just now, I'm going to say there are around
2 or 3 "flaps" per day.
The UDP links are significantly easier to administer, however, and I've
stopped adding new TCP links.
1) Multinet has no ability to configure the TCP option for you, and you
have to manually edit the DECNET-CIRCUITS file to create one. And once you
manually edit this file, you can no longer use the MULTINET CONFIGURE/DECNET
tool (or rather, you can, but it'll erase all your hand edits!).
2) UDP is symmetrical - both ends are configured the same. TCP is
inherently asymmetrical because you need an active (connecting) and passive
(listening) end. Multinet does both, but you have to coordinate with the
other end about who will play which role
3) All UDP connections can share the same port; all TCP connections
require a unique port. This is another issue that has to be coordinated for
each link.
4) Since each TCP link needs a unique port, that means each TCP link needs
another rule added to my firewall. All the UDP links share one port and one
rule. (Actually if you're the active end and your firewall allows outgoing
connections then this doesn't apply, but everybody can't be active.
Somebody has to lose the coin flip and be the listening end.)
Admittedly #1 is unique to Multinet, but the rest are just consequences of
a connection oriented vs non-connection oriented protocol.
Bob
1525
days inactive
1525
days old
3 comments
4 participants
participants (4)
-
bob＠jfcl.com -
Mark＠infocomm.com -
paulkoning＠comcast.net -
roll＠Stupi.SE