Yes, ANF10 also uses Ddcmp.
On simh Anf10 also uses the Dmr/Dmc implementations.
RV
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Saturday, 27 March, 2021 20:06
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Old protocols in new ones
On 2021-03-27 18:59, John Forecast wrote:
>
>> On Mar 27, 2021, at 11:06 AM, Mark Berryman <mark at theberrymans.com
>> <mailto:mark at theberrymans.com>> wrote:
>>
>> 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:
>> DDCMP implementation which handles message sequencing and error
>> correction by automatic retransmission
>>
>
> No. DDCMP was designed way before any of those intelligent controllers.
> DDCMP V3.0 was refined during 1974 and released as part of DECnet Phase
> I. The customer I was working with had a pair of PDP-11/40?s, each
> having a DU-11 for DECnet communication at 9600 bps. DDCMP V4.0 was
> updated in 1977 and released in 1978 as part of DECnet Phase II which
> included DMC-11 support. The DMC-11/DMR-11 included an onboard
> implementation of DDCMP to provide message sequencing and error
> correction. Quite frequently, customers would have a DMC-11 on a system
> communicating with a DU-11 or DUP-11 on a remote system.
Right. Smart controllers with DDCMP in firmware on the controller itself
was definitely not the first implementation.
But I don't have the full history of DDCMP as such. But it sounds
reasonable that the original DECnet could have been using DDCMP already.
But was that the first implementation of DDCMP? You mentioned V3.0,
which would imply that there were even older versions since before DECnet.
Did ANF-10 use DDCMP?
Johnny
>
> John.
>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Mark Berryman
>>
>>> On Mar 27, 2021, at 4:40 AM, Keith Halewood
>>> <Keith.Halewood at pitbulluk.org <mailto:Keith.Halewood at pitbulluk.org>>
>>> wrote:
>>>
>>> Hi,
>>> 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.
>>> 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.
>>> 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?
>>> Are we missing that level of correction and relying on what happens
>>> higher up in DECnet to handle missing packets?
>>> 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.
>>> Just some thoughts
>>> Keith
>>
>
--
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
I just fixed a bug in PyDECnet that produces wrong routes if you use the --latency parameter on circuit configuration entries.
The fix is rev 580.
paul
HI,
My VAX is now back online again (so am I) - looks like my "Hecnet-hub"
is no longer accepting my node 29.400.
I would like to get back on-line.. anyone has an idea how to get back on
the line ?
Regards,
Ales
I received an RX4640 for my birthday today (ok a few weeks early). 4 cpu, 12Gb ram, 2x 72Gb discs. It also appears to have 2 smart array controllers and some fibre channel cards (pci-x)
I put VSI VMS on it.
It?s going to be ANBUS on the HECnet.
Boy is it loud!
And warm....
:)
Right, now back to that CI for SIMH that I parked a while back....
Buzzing!
? I'm tinkering with putting together a MicroVAX I system. They only
ran on a few versions of VMS.
? Does anyone have a copy of VMS handy for any version between V4.1 and
V5.1? On HECnet would be great.
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
Hello everyone,
I am trying to get DECnet working on a simulated VAX 780 (with simh) with a
3.x version of VMS. This is largely for nostalgic reasons.
I have the version of VMS 3.0 from John Dundas that Supratim posted nearly
a year ago. I have also built a VMS 3.0 system by installing VMS from the
VMS 3.0 distribution tape. Both of those systems seem to work well.
However I am failing to find a way of getting DECnet working. I have a
DECnet end node key (and a routing key, come to that) from
http://iamvirtual.ca/VAX11/VAX-11-software.html but that says that it only
works for VMS 3.4 or later. I did try it on 3.0 anyway, but it did not get
DECnet to work. It complains about needing a license.
Can anyone help me either upgrade my VMS 3.0 system to VMS 3.4 or higher
(or just install the higher version from scratch), or help me find a DECnet
key that works with VMS 3.0.
Cheers
Peter Allan
In playing with DECnet I built a DDCMP implementation which deals with a byte stream, normally from a UART. So that works nicely with async link DDCMP as found in RSX and several other operating systems. But the speed is limited.
The other option would be synchronous links, which would enable connections to DMC11 or the like at speeds up to 1 Mb/s. But synchronous comm devices that connect to modern computers aren't so easy to find, though I have seen a few.
After playing with Arduino for LK201 keyboard emulation I started to wonder if one could be made to be a synchronous comm link with a USB back end, with low level things like byte framing and maybe DDCMP packet format handling in there, but the protocol state machine in the host behind the USB interface. For moderate speeds that seems entirely practical. For 1 Mb/s, probably not, though perhaps one of the fast ARM based units with its built-in SPI could be warped into that.
The alternative would be something like a BeagleBone Black (or Green) such as David Gesswein used as the engine for his MFM hard disk emulator. That clearly could do the job without any strain.
So I'm wondering: would there be interest in such a thing? If yes, should it be a modem-connected one (RS232 signaling, bit clock supplied externally by a modem or modem-eliminator)? Or should it be the "integral modem" short distance type, the ones that used a pair of coax with 4-pin AMP connectors like this https://www.digikey.com/en/products/detail/te-connectivity-amp-connectors/2… ?
paul
The Raspberry Pi that I have been using for at least 10 years to run the
hecnet bridge has finally died so I need to setup a new one.
In the meantime my area will be offline as far as hecnet is concerned.
Regards, Mark.
--
https://www.qrz.com/db/M0NOM/P
For all those who have tunnels to my Cisco 1841, I have switched ISPs and
as such my static IP address has changed. In my configuration I have the
following endpoints configured:
David Moylan (Area 35)
Tomas Prybil (Area 34)
Supratim Sanyal (Area 31)
Brian Hechinger (Area 52)
Ian McLaughlin (Area 42)
Cory Smelosky (Area 9)
Dave McGuire (Area 61)
Peter Lothberg (Area 59)
Mark Darvill (Area 22)
Mark G Thomas (Area 23)
If you are on that list could you please update your tunnel to use my new
address, which is 163.47.57.118.
Mark Berryman, my IPv6 address is unchanged, for the moment.
Regards, Tim.
