[HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> MarkP

[Mark Pizzolato - Info Comm]

On Friday, November 19, 2021 at 1:02 PM, Paul Koning wrote:
> > On Nov 19, 2021, at 3:52 PM, Mark Pizzolato - Info Comm
> <Mark at infocomm.com> wrote:
> >
> > On Friday, November 19, 2021 at 12:33 PM, Reindert wrote:
> >> I updated the remark by Bob with this in my update and could not find
> that
> >> back in your copy of the mail transcript:
> >>
> >> Before I get a storm this from Pdp11_dup.c should accompany it:
> >>
> >>   The wire protocol implemented is native DDCMP WITHOUT the DDCMP
> >> SYNC
> >>   characters both initially and between DDCMP packets.
> >
> > I still don't understand your problem.  The wire protocol is PACKETS, NOT
> bytes.
> > The packets are transported over either UDP (as UDP packets) OR via TCP
> with
> > a 2 byte packet header indicating the data length.  Any packet length is NOT
> > presented across the simulator<->pdp11_dup device, just the data.  On
> transmit
> > any interpacket bytes that are the DDCMP_SYNC character are stripped
> BEFORE
> > the packet data is presented to UDP or TCP for outbound delivery.
> >
> > - Mark
> 
> But how does that process know how to turn a sequence of bytes written to
> the DUP transmit register into a packet?  To do so, it must know what the
> particular packet format is.  If a driver is sending BISYNC data, your packet
> framing algorithm is entirely different from what it is for DDCMP.

There is a DUP parameter Control/Status register bit (bit 15) which is defined 
as DECMODE.  The pdp11_dup uses this to presume DDCMP packet behavior.

The DUP transmit data buffer has a bit (9) which says that this is the end of a 
transmitted message.  This triggers an outbound packet send.

As I said previously, if the DUP were to be used for other protocols (which it 
doesn't currently know about), then the logic could be extended as needed.  
I would hope that useful - not just theoretic test cases would exist to drive 
such extensions.

- Mark