构建字节协议的技巧
我正在设备之间传输数据，并且必须将协议编程为字节数组。
在底层构建协议时有什么技巧吗？ .. 例如：
- 使用 2 字节标头，在数据字节之前发送消息长度。
- 使用 CRC/数据验证方案。 （我该怎么做？有简单的校验和吗？）
I'm communicating data between devices, and I have to program the protocol as an array of bytes.
Any tips when building protocols at a low-level? .. Eg:
- Use a 2 byte header, to send the length of the message before the data bytes.
- Use a CRC/data validation scheme. (How do I do this? Any simple checksums?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
它取决于底层传输层的 QoS（服务质量）特性。
如果底层通道是可靠的，那么 CRC 可能就有点过分了（假设某种形式的完整性检查是在较低协议层完成的）。
如果您询问如何从字节流中描述您的有效负载，那么有几种可能性，其中之一可能只是对您的流进行 BASE64 编码/解码。不过，根据您的要求，BASE64 可能会转化为过多的开销。
当然，您始终可以使用有效负载中出现概率较低的标头（唯一序列+有效负载长度+CRC），但是您需要在有效负载上应用加扰器以最大限度地减少重复标头等的可能性。
如果您是希望为不可靠的面向字节流的协议构建一个协议，那么为什么要重新发明轮子呢？为什么不使用 PPP 之类的东西呢？
It depends on the QoS (Quality Of Service) characteristics of the underlying transport layer.
If the underlying channel is reliable, then a CRC is probably overkill (assuming some form of integrity checking is done at the lower protocol layer).
If you are asking about how to delineate your payload from a byte stream, then there are several possibilities one of which might be just to BASE64 encode/decode your stream. Then again, depending on your requirement, BASE64 might translate to too much overhead.
Of course you can always use a HEADER (Unique Sequence+payload length+CRC) with a low probability of occurence in your payload but then you need to apply a scrambler over your payload to minimize the probability of duplicating your HEADER etc.
If you are looking to build a protocol for an unreliable byte-stream oriented procotol, then why reinvent the wheel? Why not use something like PPP?
关于校验和，取决于底层协议。但您可以自己实施一个。 Encrypt、Hash、Crunch、Flip、2s 对消息进行补全并将结果存储在一个 Check 字节中
About the checksum, depends on the underlying protocol. But you can implement one yourself. Encrypt, Hash, Crunch, Flip, 2s Complement the message and store the result in one Check byte
仔细考虑是否可以有一个人类可读的协议
然后考虑是否可以使用压缩而不是原始二进制文件
Think carefully whether you can have a human readable protocol
Then consider if you can use compression rather than raw bianry
重要部分取决于较低层提供的内容。以下是一些例子来解释我认为重要的意义和原因：
我曾经参与过 ITU H.223 协议的实施。最糟糕的是数据流甚至可能是基于字节或比特流的，并且较低层除了原始比特之外什么也不提供。协议有几个可能的层，具体取决于上层的传输可靠性和功能要求。
另一个例子是基于 TCP 的 ITU H.225 协议，其中传输是可靠的，但它是字节流。因此，它必须实现良好的消息定界逻辑。
嗯，基于 UDP 的 SIP。数据报。非常有用。但其中的很多问题都与消息传递的可靠性有关。因此排序和请求/响应跟踪（事务、分支...）非常重要。
好的，由于某些原因我们使用了 RPC 协议。如果你很懒的话那是件好事。一些与应用程序逻辑相关的限制，但我建议看看这个，即使只是为了学习。
NASA IPC 是我不久前看过的东西。很好，与上层相关非常简单。但它是中心化的，这有什么限制。
另一个关键点是：您应该首先根据您的需求来设计协议（分析上层需求）。如果您确实需要这样做（例如），您会根据 CRC-32 的知识给出什么是保护数据完整性而不是分析的最佳方法？
好吧，我认为这些提及可能会帮助您以略有不同的观点思考主题。
Significant part depends on what is provided on lower layers. Here are examples to explain what an why I count significant:
I once took part in ITU H.223 protocol implementation. The worst thing there was data stream could be even byte or bit stream based and lower layers provided NOTHING beside raw bits. Protocol had several possible layers in dependence on transport reliability and functionality requirements for upper layers.
Another example is ITU H.225 protocol over TCP where transport was reliable but it was stream of bytes. So it MUST be good message delimitation logics implemented.
Well, UDP based SIP. Datagrams. Very useful. But lot of troubles there were related to messaging reliability. So sequencing and request / response tracking (transaction, leg ...) was very significant.
OK, for some reasons we used RPC protocol. Good thing if you are lazy. Some limitations related to applications logics but I'd recommend to look on this even just to learn.
NASA IPC was thing I looked on not so long time ago. Good, very simple related to upper layers. But it is centralized what is limitation.
Another key point is: You should design protocol looking at first on your needs (analyze upper layer requirements). What would you given with knowledge CRC-32 is best way to protect data integrity over analyze if you really need to do this (as example)?
Well, I think these mentions might help you think about subject with slightly different point of view.