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

[Peter Lothberg]

And for those who do Tops10, a DN87 has by default DQ11 for speaking SYNC ddcmp. 

-P 

> From: "Mark Pizzolato - Info Comm" <Mark at infocomm.com>
> To: "hecnet" <hecnet at Update.UU.SE>
> Sent: Sunday, December 12, 2021 6:28:25 PM
> Subject: RE: [HECnet] native Dup sync line revisited --> preliminary tests
> reveals problems

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sonic.net/mailman/private/hecnet-list/attachments/20211212/67dccaf3/attachment.htm>