没有压缩的bsdiff正在生成大的增量补丁文件

Question

我目前正在开发一个OTA / FOTA更新系统，该系统必须在带有ARM CORTEX M0 +的嵌入式设备中运行。 我的主要问题是FLASH空间不足以及我所拥有的网络网络带宽较低，因此delta补丁应该越小越好。

为了得到这个结果，我做了一些研究，发现了一些二元差异算法和工具，如bsdiff，xdelta或courgette。 我的所有问题都是大小，因为我需要一个非常小的编译应用程序来运行它，所以我有一个bsdiff独立版本（实际上它们是2个版本：bsdiff standalone和minibsdiff）：

https://github.com/Cheedoong/bsdiff

https://github.com/thoughtpolice/minibsdiff

第一个仍然使用bzip2，但它是独立的，最适合嵌入式系统，但我想测试两件事：

1. 未压缩增量的大小如何？所以我试图删除所有的bzip2逻辑，得到它。当我注意到三角形的大小与完整原始文件的大小相似时，我非常惊讶，所以我跳到了第二个来源，即minibsdiff。

2. minibsdiff是bsdiff但没有任何压缩，让你使用你想要的任何压缩。它也帮我检查我没有错，并且生成的未压缩增量补丁与我想修补的原始文件的大小相同（或者更多，因为标题和其他我想的）。

   < / LI>

   所以...这里发生了什么？我读谷歌搜索有点非常相似的文件生成更大的补丁但是...在测试期间我使用8 KB大小的文件，获得8KB未压缩的补丁不是一个解决方案，因为那样可能更好的只压缩文件并替换旧的一个是新的...我觉得我错过了什么。

   任何想法都将非常感激。

   谢谢大家。

   致以最诚挚的问候，

   伊万。

Answer 1

我得到了一些结论，阅读更多关于bsdiff以及它如何对后缀进行排序。它似乎在位置之间添加了零，这就是为什么它似乎增加了补丁大小，但是零很容易被压缩，这就是bsdiff有效的原因。因此，如果我想在一个内存很少的系统中实现它，建议使用另一种压缩算法，例如lzw，并修改修补程序以便在块中修补（在FLASH中写入fw）我正在解压缩块，因为我无法处理ARM CORTEX M0 +一个大文件（压缩补丁的32KB RAM和8或16KB ROM）。

最好的问候，如果我得到任何有趣的结果，我会发布更多。

感谢大家。

伊万。

Answer 2

如果要计算2个压缩磁盘映像之间的差异，那么靠近图像开头的任何小差异都会导致图像几乎完全不同，从而产生长差异。

您可以计算未压缩版本之间的差异，并将其压缩以进行传输，但嵌入式例程需要有足够的RAM将diff合并到Flash映像的未压缩副本中并重新压缩以进行闪存。