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.
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.
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
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-
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
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
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:
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
[Release] Patcher Design für DE Patcher 09/14/2020 - Metin2 PServer Designs, Websites & Scripts - 24 Replies Abend,
habe dieses Design, wie dort angekündigt, für den DE-Patcher (Offi-Patcher, etc.) gecoded.
Screen vom Patcher (bisschen anders, musste sein)
http://i.epvpimg.com/OcNCh.png
Was alles im Anhang ist:
Die benötigten geslicten Bilder
[Release]Altes Solaria2 Patcher Design & Board Design 10/19/2015 - Metin2 PServer Guides & Strategies - 13 Replies Hey Leute.
Ich release heute noch einbischen Solaria2-Stuff, den ich von Dark bekommen habe. Also es ist ein Patcher-Design, welches gecoded werden müsste & dazu noch das Board-Design, welches bereits fertig ist. Aber wichtig: Das Board-Design muss als Paket hochgeladen/installiert werden. Erstellt wurde es von KingCLou. So ich wünsche euch noch Viel Spaß damit, Downloads im Anhang.
Patcherdesign-Screen:
http://i.imgur.com/N43rYA2.jpg
und Board-Design:
http://i.imgur.com/BP3ByTV.png...
