关于构建字节协议的提示

1. 在设置结构之前,明智地考虑所有情况。
2. 使头稍大一点,即使在其中发送零字节。
3. 将收割台分成几个部分。当然,这取决于您的需求,例如控制字节、消息长度字节、格式字节…等等。

关于校验和,取决于底层协议。但是你可以自己实现一个。encrypt、hash、crunch、flip、2s补充消息并将结果存储在一个检查字节中

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

如果底层通道是可靠的,那么CRC可能是杀伤力过大的(假设在较低的协议层进行某种形式的完整性检查)。

如果你问 怎样 到 勾画 您的有效负载来自一个字节流,然后有几种可能,其中一种可能只是对您的流进行base64编码/解码。然后,根据您的需求,base64可能会转化为过多的开销。

当然,您可以使用一个头段(唯一序列+有效载荷长度+CRC),在您的有效载荷中出现的概率很低,但是您需要在有效载荷上应用一个扰频器,以最小化复制头段的概率等。

如果您希望为不可靠的面向字节流的Procotol构建一个协议,那么为什么要重新发明轮子呢?为什么不使用像购买力平价这样的东西?

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

重要部分取决于 下层有什么 . 以下是一些例子来解释为什么我认为重要:

• 我曾经参加过ITU H.223协议的实施。最糟糕的是,数据流甚至可能是基于字节或位流的,而底层除了原始位之外什么也没有提供。协议有几个可能的层依赖于上层的传输可靠性和功能性需求。

• 另一个例子是TCP上的ITU H.225协议,其中传输是可靠的,但它是字节流。因此,必须实现良好的消息定界逻辑。

• 嗯,基于UDP的SIP。数据报。非常有用。但是很多问题都与消息传递的可靠性有关。因此,排序和请求/响应跟踪(事务、LEG…)非常重要。

• 好的,出于某些原因,我们使用了RPC协议。如果你懒惰,那就好了。与应用程序逻辑相关的一些限制,但我建议您甚至只是为了了解这个问题。

• NASA的IPC是我不久前看到的。很好,与上层相关非常简单。但它集中了什么是限制。

另一个关键点是: 你应该先根据自己的需要设计一个协议 ( 分析上层需求 )如果您真的需要这样做的话(例如),您在知识CRC-32中会给出什么是保护数据完整性而不是分析的最佳方法?

好吧,我认为这些提到可能有助于你用稍微不同的观点来思考这个主题。