2016-08-04 41 views
1

Ich entwickle derzeit ein OTA/FOTA-Update-System, das in einem Embedded-Gerät mit einem ARM CORTEX M0 + laufen muss. Mein Hauptproblem ist die FLASH Platzmangel und die Netzwerk-Netzwerk-Bandbreite, die ich habe, so dass die Delta-Patches kleiner sein sollten, desto besser.bsdiff ohne Komprimierung erzeugt große Delta-Patch-Dateien

Um dieses Ergebnis zu erhalten, habe ich einige Nachforschungen angestellt und einige binäre Diff-Algorithmen und Werkzeuge wie bsdiff, xdelta oder Zucchini gefunden. Mein Problem mit allen von ihnen war die Größe, weil ich dies für den Betrieb eine sehr kleine kompilierte Anwendung haben müssen, so habe ich eine bsdiff Standalone-Version (eigentlich waren sie zwei Versionen: bsdiff Standalone und minibsdiff):

https://github.com/Cheedoong/bsdiff

https://github.com/thoughtpolice/minibsdiff

Die erste benutzt noch bzip2 aber eigenständige und am besten geeignet für ein eingebettetes System, aber ich wollte 2 Dinge testen:

  1. Wie ist die Größe des unkomprimierten Delta. Also habe ich versucht, die gesamte bzip2-Logik zu entfernen und das zu bekommen. Ich war sehr überrascht, als ich bemerkte, dass die Größe des Deltas der Größe der vollständigen Originaldatei entsprach, also sprang ich zur zweiten Quelle, der Minibsdiff.

  2. Das Minibsdiff ist das Bsdiff, aber ohne jegliche Komprimierung, sodass Sie die gewünschte Komprimierung verwenden können. Es diente mir auch zu überprüfen, dass ich nicht falsch lag und dass der erzeugte unkomprimierte Deltapatch die gleiche Größe hatte (oder ein bisschen mehr, weil der Header und andere ich vermute) als die ursprüngliche Datei, die ich patchen wollte.

Also ... Was ist hier los? Ich lese etwas googeln, dass sehr ähnliche Dateien größere Patches generieren, aber ... während der Tests habe ich 8 KB große Dateien verwendet, 8KB unkomprimierte Patches zu bekommen ist keine Lösung, denn dann wäre es vielleicht besser, nur die Datei zu komprimieren und die alte zu ersetzen Einer durch den Neuen. Ich fühle, dass mir etwas fehlt.

Jede Idee wird sehr geschätzt.

Danke euch allen.

Mit freundlichen Grüßen,

Iván.

+0

Nicht sicher, was Ihre eigentliche Frage ist. Du hast bereits beschrieben "was hier passiert". Aber wenn Sie diff, müssen Sie auf das Ziel mit dem tatsächlichen Inhalt mergen, bevor Sie blinken. Wie auch immer, ohne weitere Details ist es schwer, eine nützliche Antwort zu geben. Sie müssen möglicherweise zuerst ein wenig länger nachdenken. – Olaf

+0

Hallo Olaf. Meine Frage ist, warum dies geschieht, weil ich vorhabe, kleine Deltas zu bekommen, nicht solche mit derselben Größe wie die ursprüngliche Datei. Ich versuche, die Suffixsortierung zu studieren, die bsdiff implementiert, weil möglicherweise nicht für eine 250K oder weniger Dateien verwendbar ist. Und ja, wenn ich diff muss ich zusammenführen, aber die Diff-Datei ist riesig und sollte klein sein, zumindest kleiner als das Original. Wenn ich nicht weiter gehe, dann tue ich so, als würde ich meinen eigenen Algorithmus nicht entwickeln, sondern einen benutzen, der bereits benutzt wird. Danke trotzdem. – Fulgor3

+0

Es gibt verschiedene Möglichkeiten, Diffs zwischen Dateien zu kodieren. Jeder hat seine Anwendung. Alles hängt davon ab, was Sie erwarten. Wenn Ihre Erwartung nicht erfüllt ist, können Sie das Konzept sprengen. Darauf gibt es keine einfache Antwort und die Frage wäre - selbst nachdem alle Informationen gegeben wurden - zu weit gefasst. Machen Sie einen Test, schauen Sie sich die Dateien an und definieren Sie möglicherweise Ihr eigenes Format/Werkzeuge. Wenn Sie nicht herausfinden und/oder die Erfahrung fehlt, mieten Sie einen Berater, für den sich nichts zu schämen ist. Stack Overflow ist jedenfalls keine Beratungsseite. – Olaf

Antwort

1

Wenn Sie Diffs zwischen zwei komprimierten Disk-Images berechnen, führt jeder kleine Unterschied nahe dem Anfang des Bildes dazu, dass die Bilder fast vollständig unterschiedlich sind, was zu einem langen Diff führt.

Sie könnten den Unterschied zwischen den unkomprimierten Versionen berechnen und diesen für die Übertragung komprimieren, aber die eingebettete Routine müsste genügend RAM haben, um das diff in eine unkomprimierte Kopie des Flash-Bildes zu mischen und diese zum Flashen erneut zu komprimieren.

+0

Hallo. Ich berechne die Diffs zwischen zwei unkomprimierten Bildern, weil ich zuerst die Deltas nicht komprimieren wollte. Später habe ich die Deltas mit Notepad ++ und HexDif verglichen, und sie sind nicht völlig verschieden, deshalb war ich wirklich überrascht, als ich bemerkte, dass der Patch die gleiche Größe hatte wie die Originaldatei. Eine andere Frage wäre, ob ich den Patch (nur anwenden, weil die Generierung auf einem Desktop-PC durchgeführt werden würde) durch Teile im Embedded mit 32KB RAM übernehmen würde. Mit freundlichen Grüßen – Fulgor3

+0

Können Sie versuchen, die Bilddateien zu komprimieren? Wenn die komprimierte Größe nahe an der unkomprimierten Größe liegt, bedeutet dies, dass die Bilder bereits komprimiert sind. das Berechnen eines Deltas zwischen komprimierten Dateien erzeugt normalerweise eine große Datei. – chqrlie

+0

Hallo chqrlie. Ich habe das schon einmal versucht und nein, sie waren nicht schon komprimiert. 8KB (wie die ursprüngliche Dateigröße) uncompressed Patch und 1.8KB der komprimierte Patch ist, was ich bekomme, so scheint es, als ob nur die Komprimierung nützlich ist :(. Vielleicht in der Minibsdiff-Projekt die verpasste etwas, aber ich habe ähnliche Ergebnisse zu modifizieren die bsdiff standalone (ohne die bszip2 in usr/bin) version Vielen Dank für deine Ideen !!! Hast du jemals einen dieser binären diff Algorithmen mit einem erfolgreichen Ergebnis implementiert? Ich bin nur neugierig. – Fulgor3

2

Ich habe einige Schlussfolgerungen gelesen mehr über bsdiff und wie es sortiert die Suffixe. Es scheint, dass Nullen zwischen Orten hinzugefügt werden, deshalb scheint es, die Patch-Größe zu erhöhen, aber die Nullen sind leicht komprimiert und deshalb ist Bsdiff effizient. Wenn ich dies also in einem System mit sehr wenig verfügbarem Speicher implementieren möchte, wäre es empfehlenswert, einen anderen Komprimierungsalgorithmus, wie zum Beispiel lzw, zu verwenden und den Patcher zu modifizieren, um in Blöcke wie I zu patchen (FLASH schreiben) Blöcke dekomprimieren, weil ich in einer ARM CORTEX M0 + eine große Datei (32KB RAM und 8 oder 16KB ROM für den komprimierten Patch) nicht verarbeiten kann.

Mit freundlichen Grüßen und ich werde mehr posten, wenn ich irgendein interessantes Ergebnis bekomme.

Danke an alle.

Iván.