C# parchive / quickpar / par2 Reparatur Implementierung?

Question

Ich schreibe eine C#-App, die in der Lage sein muss, eine Reihe von Dateien mithilfe von Par2-Paritätsdateien zu reparieren. Für C++ gibt es viele Lösungen, die genau das tun, aber für C# finde ich keine native Implementierung.

Eine Option wäre die Verwendung einer C++-DLL in C#, aber das würde ich lieber vermeiden, da es nicht möglich ist, eine 32-Bit-DLL in einer x64-App zu verwenden und ich meine App auf den 32-Bit-Modus beschränken würde.

Eine weitere Option ist, par2cmdline im Hintergrund über ShellExecute auszuführen, aber ich hätte lieber mehr Kontrolle über den Prozess (Fortschritt, Abbruch usw.).

Weiß jemand von einer nativen C#-Implementierung, die Dateien mithilfe eines par2-Sets repariert?

Answer 1

Möchten Sie bei den PARs bleiben? Ich habe eine vollständig native Reed/Solomon-Implementierung, die ich veröffentlichen würde, wenn es hilfreich wäre (die Übereinstimmung, auf der die PARs basieren), aber ich habe nichts für die gesamte Dateiverwaltung und -aufteilung.

Mein Code ist eine Implementierung von Stream und erzeugt einen String mit allen enthaltenen Fehlerkorrekturdaten. Sie können dann diese Daten beschädigen und zurückschicken, und das System stellt sie automatisch wieder her. Ich würde es einfach veröffentlichen, aber es ist lang und ich bin zu faul, um einen Blogbeitrag zu schreiben und darauf zu verlinken.

Um das wie PAR funktionieren zu lassen, müssten Sie das in Dateien aufteilen und dann ein System erstellen, das fehlende Volumes identifizieren kann und korrupte Daten für alle fehlenden Daten 'hinzufügt' (die Mathematik kann mit fehlenden Daten nicht umgehen, nur mit korrupten).

Auch als Hinweis zur Leistung: Das System, für das dies entwickelt wurde, war ziemlich 'sprunghaft'. Es gab viele 100.000-Streams auf einmal, hatte aber auch lange Wartezeiten, in denen nichts passierte. Die C#-Version der Mathematik funktionierte etwa 6% schneller als die reine C-Version. Wenn ich Leistungstests nur mit ununterbrochener Last durchgeführt habe, lief die C#-Version etwa 1-2% langsamer. Meiner Erfahrung nach haben die meisten C- zu C#-Mathematikumwandlungen die gleichen Leistungsergebnisse.

Answer 2

Es ist keine direkte Antwort, aber ich denke, es gibt einen Weg, eine 32-Bit-DLL in eine 64-Bit-App zu laden:

http://dnjonline.com/article.aspx?ID=jun07_access3264

Von dem Artikel:

Diese Lösung erfordert zusätzliche Arbeit, da der 32-Bit-Surrogatprozess, der die 32-Bit-DLL lädt und ihre API freigibt, erstellt werden muss. Auch auf der 64-Bit-Seite sind einige Änderungen erforderlich, da der Verbraucher eine der IPC-Techniken anstelle des direkten Zugriffs auf die 32-Bit-DLL verwenden muss. Es ist erwähnenswert, dass in extremen Fällen diese zusätzliche Arbeit mit der Arbeit vergleichbar sein könnte, die bei der Entwicklung einer 64-Bit-Version der 32-Bit-DLL von Grund auf erforderlich ist.

Eine mögliche Möglichkeit, diese Kosten zu reduzieren, besteht darin, eine '64-Bit-Wrapper'-DLL zu implementieren, die dieselben Funktionen, Parameter, Typen usw. wie die Original-32-Bit-DLL freigibt. Diese Wrapper-DLL kann dann IPC-basierte Aufrufe an die Original-32-Bit-DLL machen, die in einem Surrogatprozess geladen wurde.

Answer 3

Ich habe vor einiger Zeit etwas ähnliches gemacht. Wenn Sie sich den Quellcode von par2 ansehen, ist es nicht trivial. Sie könnten es wahrscheinlich ohne viel Aufwand nach c# portieren. Leider würde all die Mühe, die das kosten würde, Sie in der Leistung teuer zu stehen kommen (probieren Sie es aus, wenn Sie mir nicht glauben).

Am Ende habe ich das par2-Programm über CreateProcess aufgerufen. Sie können Handles für stdin, stdout und strerr erhalten. Da es sich bei dem ausführbaren Programm um eine Konsolenanwendung handelt, können Sie den Output analysieren, um den Fortschritt zu ermitteln. Wenn Sie den Vorgang "abbrechen" möchten, können Sie den Prozess immer beenden.

Es ist eine schlampige Methode.

Der "richtige" Weg wäre, den par2-Quellcode zu nehmen und ihn in eine 64-Bit-DLL zu portieren (bleiben Sie aus Leistungsgründen bei unmanaged C/C++ DLL).