构建字节协议的技巧

Question

我在设备之间传递数据，我必须将协议编程为字节数组。

在低级别构建协议时有什么提示？ ..例如：

• 使用一个2字节的头，在数据字节之前发送消息的长度。
• 使用CRC /数据验证方案。 （我该怎么做？任何简单校验和？）

Answer 1

1. 在设置结构之前明智地考虑所有情况。
2. 使头部稍大一点，即使发送零字节。
3. 将标题拆分为几个部分。这当然取决于您的要求，例如控制字节，消息长度字节，格式字节等。

关于校验和，取决于基础协议。但是你可以自己实现一个。加密，哈希，紧缩，翻转，2s补充消息并将结果存储在一个校验字节中

Answer 2

它取决于底层传输层的QoS（服务质量）特性。

如果底层通道是可靠的，那么CRC可能是矫枉过正的（假设某种形式的完整性检查在较低的协议层完成）。

如果你问如何到描出您的有效载荷从一个字节流，那么有几种可能其中一个可能只是为Base64编码/解码的流。再次，根据您的要求，BASE64可能会转化为过多的开销。

当然，您总是可以在有效载荷中使用HEADER（唯一序列+有效载荷长度+ CRC），发生概率较低，但您需要在有效载荷上应用扰频器以最大限度地减少重复HEADER的可能性等。

---

如果您正在寻找建立一个协议不可靠的面向字节流的网络协议，那么为什么另起炉灶？为什么不使用像PPP这样的东西？

Answer 3

仔细想想你是否可以有一个人类可读的协议
然后考虑是否可以使用压缩，而不是原始bianry

Answer 4

重要部分取决于设置在下层什么。这里有一些例子来解释我为什么重要：

• 我曾经参与过ITU H.223协议的实现。数据流最糟糕的地方可能是基于字节或比特流，而低层只能在原始数据旁边提供。协议有几个可能的层次，取决于上层的传输可靠性和功能要求。

• 另一个例子是基于TCP的ITU H.225协议，其中传输是可靠的，但它是字节流。所以它必须是很好的消息定界逻辑。

• 那么，基于UDP的SIP。数据报。很有用。但很多麻烦都与消息传递的可靠性有关。因此，排序和请求/响应跟踪（交易，支付......）非常重要。

• 好的，由于某些原因，我们使用RPC协议。好，如果你懒惰。一些与应用程序逻辑有关的限制，但我建议看看这个，甚至只是为了学习。

• NASA IPC是我不久前看过的东西。好，很简单，与上层相关。但它是集中的限制。

另一个关键点是：您应该设计方案看第一您的需求（分析上层要求）。如果您真的需要这样做，例如，CRC-32是保护分析过程中数据完整性的最佳方法？

那么，我认为这些提到可能会帮助你思考稍有不同的观点。