流文件增量编码/解码答案

【问题标题】：Streaming File Delta Encoding/Decoding流文件增量编码/解码
【发布时间】：2017-03-01 03:46:24
【问题描述】：

这是问题所在 - 我想在服务器上生成二进制文件（> 1 MB 大小）的增量，并通过 HTTP 将增量发送到内存受限（RAM 不足且没有动态内存）的嵌入式设备。 Delta 是首选（而不是从服务器发送完整的二进制文件），因为通过线路传输数据涉及的成本很高。

问题在于，嵌入式设备无法解码增量并在内存中创建新文件的内容。我研究了各种二进制增量编码/解码算法，如 bsdiff、VCDiff 等，但无法找到支持流式传输的库。

也许，与其询问是否有合适的库，我是否可以采取其他方法来解决原始问题（通过网络发送最少的数据）？虽然如果有合适的增量库支持流式解码（用 C 或 C++ 编写，不使用动态内存），那肯定会有所帮助。

【问题讨论】：

您是否同时控制服务器和嵌入式设备上的软件？嵌入式设备是否有文件的副本开始？它保存在哪里？（如果文件大于 1MB，则不太可能将其保存在 RAM 中！）嵌入式系统需要对文件做什么？
是的，我控制两端的软件。是的，它确实有原始（参考）文件的副本。由于内存限制，它必须将其流式传输到文件系统上的文件中。嵌入式设备需要通过“修补”原始（参考）文件来创建新文件。
另外，这些增量的应用是为了降低嵌入式设备的OTA升级成本。
我的第一次尝试是使用一个简单的 diff 算法来解决常见的子序列问题 (en.wikipedia.org/wiki/Longest_common_subsequence_problem)。从此生成差异仍然是顺序的，如果您想流式传输差异，这是一个很好的质量。
如果您不需要经常访问文件（或者可以容忍适度的延迟），您可以将差异与原始文件一起存储，并在-fly 修补嵌入式设备上的文件读取 shim。 shim 将提供标准的read( buf, len ) 接口，但会通过首先进入原始文件，然后通过影响文件该部分的每个差异来填充缓冲区，并适当地修改返回缓冲区。对于覆盖类型的差异，这很容易。但是，对于删除和插入，它会很复杂。

【解决方案1】：

在服务器上维护由嵌入式设备保存的当前文件的副本。当您要发送更新时，将文件的新版本与旧版本进行异或，并使用任何合理的压缩器压缩生成的流。（允许高成本编码以允许低成本解码的算法在这里将特别有用。）将压缩流发送到嵌入式设备，该设备读取流，动态解压缩并直接异或（副本）目标文件。

如果您的更新使得文件内容随时间变化不大并保持固定结构，则 XOR 流将主要为零，并且压缩得非常好：传输的字节数将很少，解压缩的工作量将很低，嵌入式设备的内存需求将是最小的。你的模型离这些假设越远，这种方法对你的好处就越少。

【讨论】：

【解决方案2】：

由于您说增量可以是任意随机的（从零增量到完全不同的文件），因此压缩增量可能是一个失败的原因。理论上，随机二进制数据的无损压缩是不可能的。此外，由于嵌入式设备的内存有限，使用复杂的库来压缩/解压缩偶尔的“简单”增量可能是不可行的。

我建议只需将新文件以原始字节格式发送到设备，然后覆盖现有的旧文件。

【讨论】：

【解决方案3】：

正如 Kevin 所说，压缩随机数据不应该是您的目标。关于您使用的数据类型的更多信息会有所帮助。上下文是压缩的关键。

您使用的术语“图像”听起来像是经典的视频编解码器挑战。如果您曾经看到奇怪的视频混叠效果会影响已更改的帧部分，然后突然间一切都清楚了。您可能已经目睹了关键帧的概念以及一系列增量帧。增量帧未正确应用的地方。

在这个模型中，服务器决定什么更便宜：

delta 命令作为一系列写入指令进行通信，可以覆盖客户端现有缓冲区。

示例格式：

可能有多种方法可以计算这些增量命令。蛮力方法是：

【讨论】：