<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">DDCMP was originally designed to run over intelligent synchronous controllers, such as the DMC-11 or the DMR-11, although it could also be run over async serial lines. Either of these could be local or remote. If remote, they were connected to a modem to talk over a circuit provided by a common carrier and async modems had built in error correction. From the DMR-11 user manual describing its features:<div class="">DDCMP implementation which handles message sequencing and error correction by automatic retransmission</div><div class=""><br class=""></div><div class="">In other words, DDCMP expected the underlying hardware to provide guaranteed transmission or be running on a line where the incidence of data loss was very low. UDP provides neither of these.</div><div class=""><br class=""></div><div class="">DDCMP via UDP over the internet is a very poor choice and will result in exactly what you are seeing. This particular connection choice should be limited to your local LAN where UDP packets have a much higher chance of surviving.</div><div class=""><br class=""></div><div class="">GRE survives much better on the internet than does UDP and TCP guarantees delivery. If possible, I would recommend using one these encapsulations for DECnet packets going to any neighbors over the internet rather than UDP.</div><div class=""><br class=""></div><div class="">Mark Berryman<br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 27, 2021, at 4:40 AM, Keith Halewood <<a href="mailto:Keith.Halewood@pitbulluk.org" class="">Keith.Halewood@pitbulluk.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Hi,<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I might have posted this to just Paul and Johnny but it’s probably good for a bit of general discussion and it might enlighten me because I often have a lot of difficulty in separating the layers and functionality around tunnels of various types, carrying one protocol on top of another.<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I use Paul’s excellent PyDECnet and about half the circuits I have connecting to others consist of DDCMP running over UDP. I feel as though there’s something missing but that might be misunderstanding. A DDCMP packet is encapsulated in a UDP one and sent. The receiver gets it or doesn’t because that’s the nature of UDP. I’m discovering it’s often the latter. A dropped HELLO or its response brings a circuit down. This may explain why there’s a certain amount of flapping between PyDECnet’s DDCMP over UDP circuits. I notice it a lot between area 31 and me but but much less so with others.<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">In the old days, DDCMP was run over a line protocol (sync or async) that had its own error correction/retransmit protocol, was it not? So a corrupted packet containing a HELLO would be handled at the line level and retransmitted usually long before a listen timer expired?<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Are we missing that level of correction and relying on what happens higher up in DECnet to handle missing packets?<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I’m having similar issues (at least on paper) with an implementation of the CI packet protocol over UDP having initially and quite fatally assumed that a packet transmitted over UDP would arrive and therefore wouldn’t need any of the lower level protocol that a real CI needed. TCP streams are more trouble in other ways.<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Just some thoughts<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Keith</div></div></div></blockquote></div><br class=""></div></div></body></html>