13 Dec
2021
13 Dec
'21
3:15 p.m.
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