c#中长度前缀二进制流的优雅恢复答案

【问题标题】：Graceful recovery of length prefixed binary streams in c#c#中长度前缀二进制流的优雅恢复
【发布时间】：2021-03-02 03:10:52
【问题描述】：

所以我正在考虑将二进制“消息”写入磁盘。目前我选择在“消息”的开头加上前缀长度，所以我可以很容易地说从流中读取 x 字节然后反序列化它等等。

这是一个特殊情况，我希望能够继续阅读过去的消息，这些消息无法解析和恢复序列中进一步存在的任何消息。

在研究按字节序列分隔二进制数据的方法时，似乎通常不建议这样做（因为序列总是有可能自然地出现在流中），但是对于长度标头前缀，我不确定如何如果您不只是阅读，直到您遇到一些魔术序列然后阅读下一个长度等，您就可以从流中恢复阅读记录。

我正在专门研究 c# 和 protobuf，但它似乎是一个更笼统的话题。

关于如何可靠地用字节序列定界，或从长度与写入磁盘的内容不匹配的损坏数据包中恢复的任何建议？

【问题讨论】：

如果您预期“长度可能有误”，您是否不需要同等地预期“分隔符可能有误”并遇到同样的问题？请注意，您可能有一条格式错误的消息，但它的长度仍然正确 - 因此在这种情况下您仍然可以跳过它。我个人建议相信长度并从那里开始。您也可以始终为以长度为前缀的数据包含一个哈希，这样您就可以检测发生了绝对致命的事情，即使您无法超越它。
我的意思是那些是有效点，但确定存在的字节是否无效，它找到下一个长度标头的开头等问题并不大。我也没有预料到会发生这种情况但是我们已经看到磁盘流，不完整的写入，然后拾取附加到同一文件的流。永远无法访问新附加的内容，因为数据包错误，并且无法知道下一个标头从哪里获取

【解决方案1】：

所有音频格式都使用帧同步（您的魔术序列）+ 长度标头 + CRC 检查，因此音频解码器可以从损坏的流中恢复。您应该在 protobuf 反序列化器之前执行相同的操作。

【讨论】：

是的，我认为魔术序列是关键……如果我能判断这是标题的开始，或者这是记录的开始，我可以轻松容纳其余部分。我只是好奇这些音频编解码器中的魔法序列是什么。 Ogg 显然使用OggS。有趣的。考虑到 ogg 编解码器的性质，我认为风险较小，但我认为这样的事情很容易实现。