[HECnet] DMC11 in next simh version... looks nice, and question about TOPS-10

[Rob Jarratt]

-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 05 January 2013 01:32
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DMC11 in next simh version... looks nice, and
question
about TOPS-10

Following up on my own note...

On Jan 4, 2013, at 5:14 PM, <Paul_Koning at Dell.com>
<Paul_Koning at Dell.com> wrote:


...
4. Now I see a "circuit up" message from DECnet, but that is followed by
some combination of "circuit down, listener timeout" and "circuit down,
unexpected packet type".   After staring at packet traces ("set dmc0
debug=data") for a while, the reason is obvious: when one side of the
connection is started and the other is not yet started, one side sends a
packet and the other side discards that.   You can't do that.   DDCMP is a
connection oriented protocol: if you discard a packet that's a protocol
violation, and DECnet will absolutely positively get bent out of shape
because it assumes the DDCMP implementation will not do such a thing.

What has to be done is that a transmit remains pending if the other end
is
not able to receive it.   That can happen because there is no connection,
or
because the other end hasn't turned its DMC on yet, or it's on but it
currently
doesn't have receive buffers.   Similarly, master clear then RUN (DMC
restart) needs to synchronize with the other end, to simulate the effect
of
the DDCMP initialization sequence.

More precisely, the answer depends on whether you want to be strictly
compliant with the DDCMP spec, or "compliant enough".

DDCMP guarantees the following:

1. Nothing sent prior to the most recent DDCMP restart will be received
after
that restart.
2. If packet n is received, packets 0..n-1 (counting from the most recent
restart) have also been received 3. Packet boundaries are preserved
(packet
boundaries are significant) 4. If a transmit n completes, that means that
packet was delivered to a buffer on the receiving node.

It turns out that only properties 1, 2, and 3 are required for DECnet
Phase III
and beyond; that's because the routing layer is a datagram service so the
layers above can't draw any conclusions from transmits completing.   It's
possible that DECnet Phase II requires property 4; I'm not sure and I
don't
really know how to answer that question since I haven't seen copies of the
Phase II specs online.

So... properties 1 and 2 could be obtained in the SIMH implementation by
implementing a DDCMP restart (master clear and reinitialization) as a
connection reset and re-connect.


That should be fairly easy to do.



Then property 2 amounts to sending to the
socket and holding pending anything that's not accepted, and on the
receiving end reading from the socket when there is a buffer available to
deliver the data into.   That should be pretty easy to do.


I think the code already does this.



Finally, in the DMC a buffer corresponds one to one with a DDCMP packet
(its implementation of property 3). That's required -- all DECnet
protocols
are packet oriented and packet boundaries are meaningful.   There are no
byte stream protocols in DECnet -- TCP is the only protocol among all the
networking protocols I know of that made that horrible design error.   So
it's
not a matter of making a few diagnostics work as the comments in
pdp11_dmc.c say; each transmit buffer is a single DDCMP packet, and must
be delivered exactly to one receive buffer.   If you transmit an oversized
message, that's an error: the DMR manual on Bitsavers says that in such a
case, you get a Control Out with bit 4 set in SEL6 ("message too long")
and
at that point the DMC has already halted (DDCMP is stopped).


The code already does this. Each buffer is sent with a length prefix. The
code at the other end reads the length prefix so that the received buffer
only ever contains exactly what was in the transmit buffer. However, if the
message is too long I actually set the LOST DATA bit instead - see calls to
dmc_set_lost_data().

Regards

Rob


	paul