-----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