Möglichst Redundanz vermeiden bei Updater

Hallo zusammen,

Angespornt durch das updateSystem.NET von Maximilian will ich mich gerne mal an einem eigenen Updater-Projekt probieren.

Nun stellt sich mir die Frage, wie behalte ich die Struktur auf den FTP-Servern möglichst übersichtlich & wie vermeide ich eine grosse Redundanz?

Meines erachtens sind das genau 2 Gegensätze die einander 'ausbremsen'.
Zum einen könnte ich pro File aus dem Projekt was aktualisiert werden muss, beispielsweise eine Textdatei mit der Version o.ä. erstellen & die dann überprüfen & gegebenfalls herunterladen.
Zum anderen könnte ich komprimierte Download-Container erstellen die alle benötigten Dateien beinhalten.

Bei dere 1ten Variante stellt sich das Problem der Übersichtlichkeit.
Bei der 2ten das Problem der Redundanz - Beispiel:

Die Applikation ist momentan auf dem Stand der Version 1.03.
Es gibt ein Updatepacket 1.04 und ein Updatepacket 1.05

1.04 beinhaltet eine neue Library & die aktualisierte .exe Datei.
1.05 beinhaltet nur die aktualisierte .exe Datei.

Da im Container 1.04 noch eine benötigte Library steckt muss ich zuerst 1.04 & dann 1.05 runterladen.
Ergo ich lade .exe Datei 2x runter -> Redundanz.

Um das möglichst in Grenzen zu halten könnte ich in jedem Update eine Version einsetzen die benötigt wird um das Update zu installieren.
So werden nur die vorherigen Packete runtergeladen die auch wirklich gebraucht werden.

Habt ihr noch andere Vorschläge wie Updates möglichst Effizient vollzogen werden können?

Gruess,
Regenwurm

Hallo Regenwurm,

beides unter einen Hut bekommst du wohl nur, wenn du das eine aus dem anderen berechnest. Du könntest also das Speicherformat von Variante 1 verwenden, aber die Daten im Format der Variante 2 ausliefern. Dazu müsste dann entsprechend der Anforderung das benötigte Paket zusammengestellt werden. Natürlich muss man das nicht bei jeder einzelnen Anforderung tun, sondern kann auch einen Cache für die häufigsten Anforderungen verwenden.

herbivore

Hallo herbivore,

Danke für die Antwort!
Die Frage stellt sich jetzt wie soll der Client dann die Variante 2 'erstellen'?
Die Daten liegen nur auf einem FTP Server bereit.

Ich habe gerade mit einem Kollegen die Thematik besprochen.
Wir sind zu folgenden 2 weiteren Möglichkeiten gekommen.

Möglichkeit a)

Auf dem Server liegt immer nur eine 'aktuelle Version' der Applikation auf dem Server (komplett).
Der client überprüft nun welche Dateien er schon lokal auf dem neusten Stand hat & welche nicht.
Diejenigen die nicht aktuell sind werden vom FTP-Server heruntergeladen & ersetzt.

Möglichkeit b)
... ist eigentlich komplett unüberlegt wenn ich mir Möglichkeit a) nochmals durchlese. 😉

€: Möglichkeit a) macht dann aber auch nur bei kleineren Programmen sinn.
Alles andere ist reiner Speicherverbrauch.

Hallo Regenwurm,

Die Frage stellt sich jetzt wie soll der Client dann die Variante 2 'erstellen'?

ich bin davon ausgegangen, dass der Server das tut ...

Die Daten liegen nur auf einem FTP Server bereit.

... aber auf einem normalen/passiven FTP-Server geht das natürlich nicht. Aber muss es ein FTP-Server sein? Jeder Web-Server (der aktive Inhalte unterstützt, also so gut wie jeder) könnte das tun.

herbivore

Hallo herbivore,

Meine Applikation soll sich nur auf passive FTP-Server beschränken. 😃

Gruess

Hallo Regenwurm,

grundsätzlich könnte man natürlich auch einen FTP-Server schreiben, der nicht einfach nur bestehende Dateien liefert, sondern bei einem Request erst aktiv Schritte ausführt, um die Datei zu erstellen. Das wäre aber unüblich. Und man könnte keinen Standard-FTP-Server einsetzen.

Wenn du partout keinen aktiven Server haben willst, dann musst du einen Tod (Variante 1 oder Variante 2) sterben. Ein Client kann sich bei Variante 1 natürlich zusammensuchen, was er braucht, und jede Datei könnte für sich gezippt sein, aber unübersichtlich ist es dann trotzdem. Bei Variante 2 hat ein Client keine Chance, die bestehenden Redundanzen zu vermeiden, dafür ist es übersichtlicher.

Ich verstehe aber nicht, warum es unbedingt ein FTP-Server sein muss. Klar ist das einfach. Aber wer einen FTP-Server hat, hat normalerweise auch einen Web-Server. Und dort ein kleines Stück Software einspielen zu müssen, ist auch keine besonders hohe Hürde.

herbivore

Oder du nimmst Version 3, und arbeitest mit Deltas.

Ein Programm wie VisualPatch z.b. speichert nur die binären deltas, hat aber trotzdem die gesamte Historie im letzten Patch.

Beim durchlesen drängt sich mir eine Frage auf
Wer soll wann entscheiden, welche Version er runterladet
1.04 oder die neuere 1.05?

Wenn ich es richtig verstanden habe geht es nicht darum sich als User beim Update zwischen mehreren Versionen zu entscheiden, sondern die Update-SW soll entscheiden welche Dateien aktualisiert werden müssen.

Obiges Beispiel:
Update 1.03 -> 1.05 Library und .exe müssen heruntergeladen werden
Update 1.04 -> 1.05 Nur die .exe muss heruntergeladen werden

//Jörg

aso
Ich hatte am Server immer das ganze Programm und das UpdateProgramm hat einfach alle Files durchgesehen welches neuer ist.
allerdings hatte ich keine Kontrolle darüber was in welcher Version erneuert wurde.

Für solche Dinge hatte ich mir einen kleinen Updater geschrieben, der sich holt, was er gerade braucht. Allerdings habe ich für die möglichen Versionssprünge jeweils eigene Update-Pakete gemacht. Sprich, ich habe ein Paket für die User von z.B. v1.03 gemacht, ein anderes für v1.04 und wieder ein anderes für 1.04b. Der Updater hat seine Version geprüft und auf dem Webserver jeweils das für ihn passende Paket abgeholt. Auf dem Server selbst sind dann natürlich Redundanzen vorhanden, allerdings juckt das nicht wirklich, wenn sie richtig organisiert sind. Jedenfalls musste wenigstens der Client nicht für ein Update 1-3x ein beinahe-komplett-Update herunterladen.