bsdiff без сжатия генерирует большие файлы дельта-патчей

Question

В настоящее время я разрабатываю систему обновления OTA/FOTA, которая должна запускаться во встроенном устройстве с ARM CORTEX M0 +. Моя основная проблема - нехватка места FLASH и пропускная способность сети с низкой пропускной способностью, поэтому дельта-патчи должны быть меньше, тем лучше.

Чтобы получить этот результат, я провел некоторое исследование и нашел несколько алгоритмов и инструментов двоичного типа, таких как bsdiff, xdelta или courgette. Моя проблема со всеми из них был размер, потому что мне нужно иметь очень небольшое собранное приложение для запуска, поэтому я получил bsdiff автономную версию (на самом деле они были 2 версии: bsdiff автономные и minibsdiff):

https://github.com/Cheedoong/bsdiff

https://github.com/thoughtpolice/minibsdiff

Первый до сих пор использует bzip2, но является автономным и наиболее подходит для встраиваемых систем, но я хотел бы проверить 2 вещи:

1. Как размер несжатой дельта. Поэтому я попытался удалить всю логику bzip2, получив это. Я был очень удивлен, когда заметил, что размер дельты был похож на размер полного исходного файла, поэтому я подпрыгнул во второй источник - мини-диск.

2. Minibsdiff - это bsdiff, но без какого-либо сжатия вообще, позволяя вам использовать любое сжатие, которое вы хотите. Это помогло мне также проверить, что я не ошибаюсь и что созданный несжатый дельта-патч был того же размера (или немного больше, потому что заголовок и другие, как я полагаю), чем исходный файл, который я хотел установить.

Итак ... Что здесь происходит? Я читал немного по-разному, что очень похожие файлы генерируют большие патчи, но ... во время тестов я использовал файлы размером 8 КБ, получение несжатых патчей размером 8 КБ не является решением, потому что тогда, возможно, лучше всего сжать файл и заменить старый один за новый. Я чувствую, что что-то упускаю.

Любая идея будет очень оценена.

Спасибо всем.

С уважением,

Iván.

Answer 1

Если вы вычисляете diff между двумя изображениями с сжатым диском, любая небольшая разница, близкая к началу изображения, приведет к тому, что изображения будут почти полностью разными, создавая длинный diff.

Вы можете вычислить разницу между несжатыми версиями и сжать это для передачи, но для встроенной подпрограммы потребуется достаточное количество ОЗУ для объединения diff в несжатую копию флэш-изображения и повторное сжатие для мигания.

Answer 2

Я сделал некоторые выводы, чтобы узнать больше о bsdiff и о том, как он сортирует суффиксы. Кажется, что он добавляет нули между местоположениями, поэтому он увеличивает размер патча, но нули легко сжимаются, и именно поэтому bsdiff эффективен. Поэтому, если я хочу реализовать это в системе с очень небольшой доступной памятью, было бы целесообразно использовать другой алгоритм сжатия, например lzw, например, и изменить патчер для исправления (записать во FLASH fw) в блоках, поскольку я я декомпрессию блоков, потому что я не могу обрабатывать ARM CORTEX M0 + большой файл (32 КБ оперативной памяти и 8 или 16 КБ ROM для сжатого патча).

С уважением, и я напишу больше, если у меня получится какой-нибудь интересный результат.

Спасибо всем.

Iván.