Patcher Software (Illumina Design)

08/27/2016 01:16 rollback#16
Quote:
Originally Posted by King Sora View Post
Hoihoi :)

Also ich habe damals Tests mit einem 2012 DE Client und einem 2012 P-Server Client durchgeführt, und jeweils den einen mit dem anderen überpatcht. Da sind wie gesagt diese 90% Zeitersparnis zusammengekommen.

Aber selbst wenn die Sache mit dem Verschlüsseln bei neueren Clients so ist, dank der Eventbasierten Programmierung des Patchers hat man genügend Optionen um den Patchvorgang zu optimieren.

Eine Lösung des Problems wäre, wenn man als Admin einen Diff-Patch der nicht verschlüsselten Datei erstellt. Der Patcher zieht sich dann den Diff-Patch und entschlüsselt die lokale Datei bevor dieser angewandt wird und verschlüsselt sie wieder nachdem er angewandt wurde. Das Funktioniert natürlich nur, wenn man die benötigte Ver und Entschlüsselungsroutine hat. (Egal in welcher Sprache, vorzugsweise C++ da man C# dekompilieren kann. Man kann nämlich in C# alles aufrufen, solange man eine geeignete API hat.)

Lg. Sora

Ich weiss zwar nicht, wie du deine Diff-Dateien aufgebaut hast, aber gehen wir einfach mal davon aus, dass du Position und neuen Wert jeweils Hexadezimal in einer einfachen UTF-8 Textdatei speicherst.

In diesem Fall benötigt die 1.000.000ste Position (F4240 - 5 Zeichen) 5 Byte Speicher, folgend von einem Trennzeichen (1 Byte) und dem neuen Byte Wert zu der Position (bis zu 3 Zeichen / 3 Byte). Hinzu kommt ein Newline, welches 2 Byte Speicher benötigt.
So der Aufbau einer simplen Diff-File.

Zusammengefasst brauchst du für diesen einen geänderten Byte in deiner Diff-File 11 Byte Speicher, welche ja auch durch die Weiten des Internets vom Patchserver auf den Client wandern müssen.

Vorausgesetzt es ändert sich in einem Patch nur ein einziges Byte in der Datei (was natürlich nie der Fall sein wird), muss man natürlich nur 11 Byte statt die ganze Datei übertragen, allerdings werden sich in der Praxis wohl eher 50% aller Bytes ändern (was lange nicht heisst, dass in diesem Patch die Hälfte geändert wurde) oder bei einem verschlüsseltem Client sogar ~99%.
Die Frage, ob das Übertragen einer Diff-File in diesem Fall schneller gehen würde, als die komplette Datei zu übertragen, brauchen wir uns hier sicherlich nicht mehr stellen.


Kannst du uns evtl. mal zeigen, wie du deine Diff-Files aufgebaut hast? Ich habe mich auch schon daran versucht, eine möglichst Speichersparende Diff-File im Byte- statt Textformat zu erstellen, allerdings habe ich bisher keine Möglichkeit gefunden, genug Speicher zu sparen, um ein Diff-Patching sinnvoll zu machen.
08/27/2016 01:19 DasSchwarzeT#17
Quote:
Originally Posted by -deleted- View Post
Ich weiss zwar nicht, wie du deine Diff-Dateien aufgebaut hast, aber gehen wir einfach mal davon aus, dass du Position und neuen Wert jeweils Hexadezimal in einer einfachen UTF-8 Textdatei speicherst.

In diesem Fall benötigt die 1.000.000ste Position (F4240 - 5 Zeichen) 5 Byte Speicher, folgend von einem Trennzeichen (1 Byte) und dem neuen Byte Wert zu der Position (bis zu 3 Zeichen / 3 Byte). Hinzu kommt ein Newline, welches 2 Byte Speicher benötigt.
So der Aufbau einer simplen Diff-File.

Zusammengefasst brauchst du für diesen einen geänderten Byte in deiner Diff-File 11 Byte Speicher, welche ja auch durch die Weiten des Internets vom Patchserver auf den Client wandern müssen.

Vorausgesetzt es ändert sich in einem Patch nur ein einziges Byte in der Datei (was natürlich nie der Fall sein wird), muss man natürlich nur 11 Byte statt die ganze Datei übertragen, allerdings werden sich in der Praxis wohl eher 50% aller Bytes ändern (was lange nicht heisst, dass in diesem Patch die Hälfte geändert wurde) oder bei einem verschlüsseltem Client sogar ~99%.
Die Frage, ob das Übertragen einer Diff-File in diesem Fall schneller gehen würde, als die komplette Datei zu übertragen, brauchen wir uns hier sicherlich nicht mehr stellen.


Kannst du uns evtl. mal zeigen, wie du deine Diff-Files aufgebaut hast? Ich habe mich auch schon daran versucht, eine möglichst Speichersparende Diff-File im Byte- statt Textformat zu erstellen, allerdings habe ich bisher keine Möglichkeit gefunden, genug Speicher zu sparen, um ein Diff-Patching sinnvoll zu machen.
Du hast vergessen ihn zu zitieren.
08/27/2016 20:18 King Sora#18
Quote:
Originally Posted by Yiv View Post
Nun, die alte Standard-Verschlüsselung hat aber auch lediglich die Index-File und nicht die Data-File verschlüsselt. Aktuell verbreitete Verschlüsselungen haben keine separate Index-File mehr und verschlüsseln das gesamte Archiv, daher funktioniert das Diff-Patching hier nicht mehr.
Mit der alten Standard-Verschlüsselung hingegen ist dein Diff-Patcher natürlich einwandfrei funktionsfähig :P

Zu deiner alternativen Lösung musst du dann jedoch aufpassen und halte ich auch nicht für besonders ideal, da im Endeffekt die Datei 1. unverschlüsselt auf dem Server liegt (bzw. die Diff-File, kommt nun auf den Patch an, ob man das will) und 2. muss sich dann der Patcher gegen diverse "Angriffe" schützen, damit man damit nicht ganz simpel den Client decrypten kann.

MfG
Du kannst die Diff Datei genau so verschlüsseln wie jede andere Datei, aufpassen musst du nur, dass der Patcher sie wieder entschlüsseln und somit wieder anwenden kann :p

Gegen diverse Angriffe muss sich der Client auch schützen. Außerdem, dadurch, dass bei meinem Diff-Patching System die Datei NICHT komplett in den RAM gelesen werden muss, sehe ich auch kein richtiges Problem dabei. :)

Quote:
Originally Posted by Monsieur -deleted- View Post
Ich weiss zwar nicht, wie du deine Diff-Dateien aufgebaut hast, aber gehen wir einfach mal davon aus, dass du Position und neuen Wert jeweils Hexadezimal in einer einfachen UTF-8 Textdatei speicherst.

In diesem Fall benötigt die 1.000.000ste Position (F4240 - 5 Zeichen) 5 Byte Speicher, folgend von einem Trennzeichen (1 Byte) und dem neuen Byte Wert zu der Position (bis zu 3 Zeichen / 3 Byte). Hinzu kommt ein Newline, welches 2 Byte Speicher benötigt.
So der Aufbau einer simplen Diff-File.

Zusammengefasst brauchst du für diesen einen geänderten Byte in deiner Diff-File 11 Byte Speicher, welche ja auch durch die Weiten des Internets vom Patchserver auf den Client wandern müssen.

Vorausgesetzt es ändert sich in einem Patch nur ein einziges Byte in der Datei (was natürlich nie der Fall sein wird), muss man natürlich nur 11 Byte statt die ganze Datei übertragen, allerdings werden sich in der Praxis wohl eher 50% aller Bytes ändern (was lange nicht heisst, dass in diesem Patch die Hälfte geändert wurde) oder bei einem verschlüsseltem Client sogar ~99%.
Die Frage, ob das Übertragen einer Diff-File in diesem Fall schneller gehen würde, als die komplette Datei zu übertragen, brauchen wir uns hier sicherlich nicht mehr stellen.


Kannst du uns evtl. mal zeigen, wie du deine Diff-Files aufgebaut hast? Ich habe mich auch schon daran versucht, eine möglichst Speichersparende Diff-File im Byte- statt Textformat zu erstellen, allerdings habe ich bisher keine Möglichkeit gefunden, genug Speicher zu sparen, um ein Diff-Patching sinnvoll zu machen.
Mein Diff-Format ist binär.
Ich habe euch mal ein Video gemacht:

Zuerst mache ich einen Diff-Patch mit .DOC Files, danach einen Diff-Patch mit .EPK Files (einmal uncrypted und einmal crypted) und anschließend einen Diff-Patch mit unterschiedlichen Files, wobei das neue File 5.4GB hat (um zu zeigen, dass anders als bsp. bsdiff4 mein System mit Blöcken Funktioniert und man nicht die gesammte Datei im RAM haben muss).

Wie genau mein Diff-System Funktioniert, werde ich euch eventuell erklären wenn ich Lust habe.. (Das Video hat schon genug Zeit gebraucht)

Änderungen:
Zone.epk unbekannte Änderungen, jedoch im Bereich von 1000KB
BGM.epk eine neue Datei hinzugefügt - Yiv hat das persönlich gemacht
*.doc Datei einen neuen Satz hinzugefügt

Ergebnisse:
Zone.epk (uncrypted): DiffPatch Größe: 5000KB = 94,47% Größenersparnis
BGM.epk (uncrypted): DiffPatch Größe: 4KB = 99,95% Größenersparnis
BGM.epk (crypted): DiffPatch Größe: 8970KB = 0% Größenersparnis
*.doc Datei: DiffPatch Größe: 3KB = 86% Größenersparnis
Genauere Angaben wie die Dateigröße der neuen und alten Datei etc. seht ihr sowieso im Video.

Lg. Sora :)

P.S.: Das Signature File im Video wird nicht gebraucht, es ist nur eine Hilfestellung fürs Programm und sollte evt. ein Hint für diejendigen sein, die sich für die Fuktionsweise interessieren ;)
08/28/2016 00:07 Lord Daemon#19
Quote:
Originally Posted by King Sora View Post
Du kannst die Diff Datei genau so verschlüsseln wie jede andere Datei, aufpassen musst du nur, dass der Patcher sie wieder entschlüsseln und somit wieder anwenden kann :p

Gegen diverse Angriffe muss sich der Client auch schützen. Außerdem, dadurch, dass bei meinem Diff-Patching System die Datei NICHT komplett in den RAM gelesen werden muss, sehe ich auch kein richtiges Problem dabei. :)



Mein Diff-Format ist binär.
Ich habe euch mal ein Video gemacht:
[Only registered and activated users can see links. Click Here To Register...]

Zuerst mache ich einen Diff-Patch mit .DOC Files, danach einen Diff-Patch mit .EPK Files (einmal uncrypted und einmal crypted) und anschließend einen Diff-Patch mit unterschiedlichen Files, wobei das neue File 5.4GB hat (um zu zeigen, dass anders als bsp. bsdiff4 mein System mit Blöcken Funktioniert und man nicht die gesammte Datei im RAM haben muss).

Wie genau mein Diff-System Funktioniert, werde ich euch eventuell erklären wenn ich Lust habe.. (Das Video hat schon genug Zeit gebraucht)

Änderungen:
Zone.epk unbekannte Änderungen, jedoch im Bereich von 1000KB
BGM.epk eine neue Datei hinzugefügt - Yiv hat das persönlich gemacht
*.doc Datei einen neuen Satz hinzugefügt

Ergebnisse:
Zone.epk (uncrypted): DiffPatch Größe: 5000KB = 94,47% Größenersparnis
BGM.epk (uncrypted): DiffPatch Größe: 4KB = 99,95% Größenersparnis
BGM.epk (crypted): DiffPatch Größe: 8970KB = 0% Größenersparnis
*.doc Datei: DiffPatch Größe: 3KB = 86% Größenersparnis
Genauere Angaben wie die Dateigröße der neuen und alten Datei etc. seht ihr sowieso im Video.

Lg. Sora :)

P.S.: Das Signature File im Video wird nicht gebraucht, es ist nur eine Hilfestellung fürs Programm und sollte evt. ein Hint für diejendigen sein, die sich für die Fuktionsweise interessieren ;)
Schöne Hintergrundmusik > TrackID pls? :3
08/28/2016 09:27 King Sora#20
Quote:
Originally Posted by .Arcusa View Post
Schöne Hintergrundmusik > TrackID pls? :3
1: Final Fantasy X - Brass de Chocobo
([Only registered and activated users can see links. Click Here To Register...])

2: Kingdom Hearts II - Dance To The Death
([Only registered and activated users can see links. Click Here To Register...])

3: Final Fantasy X - Start
([Only registered and activated users can see links. Click Here To Register...])