有关构建字节协议的提示

Question

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

在低级别构建协议时的任何提示？ ..例如：

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

Answer 1

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

如果底层信道是可靠的，则CRC可能过度（假设在较低协议层完成某种形式的完整性检查）。

如果您从字节流中询问如何 描述您的有效负载，那么有几种可能性，其中一种可能只是BASE64对您的流进行编码/解码。然后，根据您的要求，BASE64可能会转化为过多的开销。

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

---

如果您正在寻找为不可靠的面向字节流的procotol构建协议，那么为什么要重新发明轮子呢？为什么不使用像PPP这样的东西？

Answer 2

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

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

Answer 3

仔细考虑您是否可以使用人类可读的协议 然后考虑是否可以使用压缩而不是原始bianry

Answer 4

重要部分取决于在较低层提供的内容。这里有一些例子来解释我认为重要的原因：

• 我曾参加过ITU H.223协议实施。数据流最糟糕的事情可能是基于字节或比特流，而较低层在原始比特旁边提供了NOTHING。协议有几个可能的层依赖于上层的传输可靠性和功能要求。

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

• 嗯，基于UDP的SIP。数据报。很有用。但那里的许多麻烦都与消息可靠性有关。因此，排序和请求/响应跟踪（事务，腿......）非常重要。

• 好的，出于某些原因我们使用了RPC协议。如果你很懒，那就好。一些与应用程序逻辑相关的限制，但我建议您只需要学习即可。

• 美国国家航空航天局IPC是不久前我看过的东西。与上层相关的好，非常简单。但它是集中的限制。

另一个关键点是：您应该首先根据需要设计协议（分析上层要求）。如果您确实需要这样做（例如），CRC-32是保护数据完整性而非分析的最佳方法？

嗯，我认为这些提及可能会帮助您以略微不同的观点来思考主题。