[HECnet] native Dup sync line revisited --> preliminary tests reveals problems

[Paul Koning]

> On Dec 12, 2021, at 6:28 PM, Mark Pizzolato - Info Comm <Mark at infocomm.com> wrote:
> 
> Err.. Well I stand corrected.  The logic I was referring to was for generic pack transmission through TMXR connected lines.  The APIs which provide that packet delivery functionality aren’t used for DDCMP connected circuits (I forgot this since it was 8 or 9 years ago).  Instead, as you said, the packet data itself contains the needed length information.  The APIs I was referring to are tmxr_get_packet_ln_ex()and tmxr_put_packet_ln_ex().  The DDCMP circuits have framing logic code located in pdp11_ddcmp.h and they use ddcmp_tmxr_get_packet_ln() and ddcmp_tmxr_put_packet_ln().  Another protocol which had imbedded framing logic and packet sizes could implement its own {protocol}.h which handled that particular protocol framing and length details and yet still use the TMXR layer for connectivity and transport.

There are two cases, and they may be getting mixed up

One is HDLC, where packet framing is done  by flag codes.  Those are not represented in the byte stream given to the device.  Instead, the driver in some manner tells the device that the frame is finished, and the device then generates the delimiting flag.  To represent this case in a TCP data stream, a frame size field is needed because there is no other way to know where to place the simulated flag.  A precise implementation would use a bit count for the size because HDLC permits sending of any number of bits, not just a multiple of 8 bits.  That's probably not used very often in practice, though.

The other case is any character oriented protocol, such as BISYNC or DDCMP.  In those, the frame boundaries ARE represented in the byte stream supplied and read by the software.  So for these, the right encoding is to carry just the bytes, no additional metadata.  If the device has an "insert SYN bytes" feature, that needs to be emulated (by actually sending those SYN bytes) so that a "SYN search" function at the receiving end will find those bytes to exit the search mode.  Even though emulated devices don't have byte framing (the underlying connection carries whole bytes, properly framed) you still need that search feature because software may use that for error recovery.  For example, if a DDCMP engine sees a header CRC error it would typically drop into SYN search mode to skip over the data portion of the frame (at least usually; it would stop skipping early if there happens to be a long-enough sequence of SYN bytes in the data field).

So if the plain sync device emulation were to do the above, that would give us an emulation that interoperates with the DMC emulation if the software controlling the device is running DDCMP.

Finally, as for multipoint, indeed that's not in the current emulation.  It's not clear how useful that would be, and I'm not sure how to make it work on emulated connections.  It could be done when driving real serial ports.  Minimally those ports would need transmit enable control on the tributary stations even if full duplex is used, and for half duplex you'd of course need full modem control signalling.

	paul