我正在设计一种设备，它将加密从 PC 发送的长（假设无限）数据流并将其发回。我计划在运行全双工的设备上使用单个串行端口，并通过硬件握手来“阻止”数据，在每个块后发送一个 CRC 值。该设备只会缓冲有限数量的块 - 理想情况下，只有一个缓冲区累积正在接收的块，另一个缓冲区保存当前正在发送的块，在每个块边界处切换它们并使用硬件握手来保持同步。
我正在考虑的问题是，当接收方（可能是 PC 或设备）计算出的 CRC 值与发送的值不匹配时，会发生什么情况。如果接收器检测到错误，它会在其传输线路上设置中断条件 - 因为尽管 TX 和 RX 正在做不同的事情，但这就是我们所能做的 - 然后我们进入恢复序列。
在数据从发送方消失之前检测到错误情况时，恢复很容易，但特别是在接收端的 PC 上，可能存在大量缓冲区空间，并且当 PC 赶上并检测到损坏时，数据可能已经消失从设备，我们不能简单地重新传输。 “倒回”密码生成很困难，因此重新发送源数据并尝试在中间拾取内容很困难 - 事实上，源数据可能无法重新发送，具体取决于它的最终来源。
我考虑让每一方发送其“成功接收的最后一帧”计数器以及其发送的最后一帧的 CRC 值，并且如果有太多未确认的数据在输出处等待，则让设备丢弃 RTS，但这会死锁 - 设备永远不会确认 PC 的接收线程已赶上。
我还考虑过让 PC 发送一个块，然后在第一个块被确认处理并接收回来之前不发送另一个块，但这本质上是半双工或块同步操作，并且系统运行速度比它能做的要慢。一种折衷方案是在设备中拥有多个缓冲区，PC 知道有多少缓冲区并根据它认为设备正在执行的操作来限制自己的输出，但 PC 端所需的那种程度的“智能”似乎不优雅和老套。
串行通信是相当古老的技术。当然有一个好的方法可以做到这一点吗？
设计一个可靠的协议并不那么容易。到目前为止您所讨论的内容的一些注释：
- 仅使用 RTS 执行其设计目的，避免接收缓冲区溢出。不适合做多了。
- 强烈考虑not周围有多个未确认的帧。仅当连接出现高延迟时才重要，这对于串行端口来说不是问题。
- 通过以下方式实现全双工操作layering，使用 OSI 模型作为指导。
- 请务必将协议的输入和输出视为纯字节流。成帧只是协议实现的一个细节，实际的帧大小并不重要。如果应用程序通过使用消息发出信号，那么应该实现on top协议的。否则是适当分层的自动结果。
- 请记住，帧不仅可以传输数据，还可以包含接收帧的 ACK。换句话说，如果没有任何内容要传回，则只需要一个单独的 ACK 帧。
并且避免重新发明轮子，这以前已经做过了。我可以推荐 RATP，主题是RFC916 https://www.rfc-editor.org/rfc/rfc916。顺便说一句，它被广泛忽略，因此您不太可能找到可以复制的代码。我已经实施并取得了很好的成功。据我所知，它只有一个缺陷，它无法适应接收缓冲区中存在的多次连接尝试。打开端口时有意清除缓冲区非常重要。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
