24 Dec
2011
24 Dec
'11
12:50 p.m.
Thanks, Kenneth.
Good stuff in there.
Since I'm thinking of this in terms of a PDP-11, byte ordering is not an issue. :-)
I have a dump of some packets between to VMS machines as well. With your information, I
think this should now not be much trouble getting working. I'll just have to find some
time (as always the biggest problem). :-)
Johnny
On 2011-12-24 07.37, Kenneth Adelman wrote:
Hunter Goatley would have the access to the code to give you a
definitive answer, but I'm the one who reverse-engineered and coded
the first version. It has been over 15 years since I had access to the
source code, so all of this is from memory.
Basically, I wrote a VMS device driver that looked like a
point-to-point line card to the operating system and transported the
packets over UDP (or TCP), where they were delivered into DECnet on
the other end. I didn't know (or care) anything about the DECnet
protocols at the time, presumably some of which are implemented in the
line card and some in the host software, so I'm not sure where you
might "hook in" to the stack in another implementation.
For the UDP implementation each side did a bind() to a local IP
address and port and a connect() to "fix" the remote IP address and
port (the ports were all the same, but I don't recall the number
anymore). Datagrams were one-for-one with the data received from
DECnet, except a very thin header was added. My recollection is that
the header had a two-byte sequence count (more on this later) which
was incremented by the sender for each packet and may have had a
two-byte length. Be suspicous that these are in VAX byte order
(little endian) instead of network byte order (big endian). It should be
easy to reverse-engineer if you have a packet trace from two VMS
machines communicating.
For the TCP implementation one end was always passive and the
other the active connector. This was chosen by a comparison of the IP
addresses to see which was "smaller". The DECnet packets were framed
inside the TCP stream by prefixing them with a length and I suspect
also they may or may not have had a sequence count for "uniformity".
The receiver read the length and then used the length to know how much
data to read and deliver upstream.
Early versions of DECnet (I think this was fixed in the early 4.x
timeframe, but I may be wrong) made an assumption of point-to-point
line cards that packets would never arrive out-of-order, and if they did,
it would drop synchronization on the line and reset. The purpose of the
sequence count (transmitted by all implementations) was to allow
the receiving driver (I believe it checked if it was one of the buggy
versions of DECnet) to drop out-of-order packets (which DECnet was
happy to recover from) rather than deliver them upstream. Obviously
this wasn't an issue with TCP as a transport.
TCP wasn't used frequently as a transport, but worked on
long-haul links because TCP's retransmission algorithems at the
time were substaintially better than DECnets.
I don't think there was anything else in the header (eg, a
protocol version number), but there probably should have been.
Now more interesting would be to do a DECnot implementation.
This was the wholesale replacement of the DECnet stack with a
mapping layer that mapped requests directly into TCP connections.
This gave you DECnet functionality over TCP without any DECnet routing,
eg,
$ set host kaos.tgv.com
The protocol for this was a LOT more complex and would require source
code to jog my memory...
Ken