2009-05-19 16 views
8

Estoy escribiendo una aplicación C# que necesita poder reparar un conjunto de archivos usando paridad par2. Para C++ hay mucho por hacer que hará exactamente eso, pero para C# no puedo encontrar una implementación nativa.C# parchive/quickpar/par2 repair implementation?

Una opción sería usar una DLL de C++ desde C#, pero prefiero no hacerlo ya que no es posible usar un dll de 32bits en una aplicación x64, así que limitaría mi aplicación al modo de 32 bits.

Otra opción es guardar el par2cmdline en segundo plano en segundo plano, , pero prefiero tener más control sobre el proceso (progreso, cancelación, etc.).

¿Alguien sabe de una implementación nativa de C# que reparará archivos utilizando un conjunto de par2?

+0

¿Qué terminaste haciendo? –

Respuesta

0

No es una respuesta directa, pero creo que es una manera de cargar una DLL de 32 bits en una aplicación de 64 bits:

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

Desde el artículo:

Esta solución requiere adicional funciona como el proceso sustituto de 32 bits que carga el archivo DLL de 32 bits y expone que su API debe ser creada. Además, se necesitarán algunos cambios en el lado de 64 bits ya que el consumidor debe usar una de las técnicas de IPC en lugar de acceder directamente a la DLL de 32 bits. Vale la pena señalar que, en casos extremos, este trabajo adicional podría ser comparable al trabajo involucrado en el desarrollo desde cero de una versión de 64 bits de la DLL de 32 bits.

Una posible forma de reducir estos costos es implementar una DLL de contenedor de 64 bits que expone las mismas funciones, parámetros, tipos y demás que la DLL original de 32 bits. Esta DLL contenedora puede realizar llamadas basadas en IPC a la DLL original de 32 bits, que se ha cargado en un proceso sustituto.

+0

Gracias! Esta es una opción, aunque como el artículo menciona probablemente sea tanto trabajo como escribir completamente una implementación par2 en C# desde cero ... – Led

+0

Eso es algo que no querría escribir desde cero ... ¡nunca! :-) –

0

Hace un tiempo estaba haciendo algo así. Si miras el código fuente par2, no es trivial. Probablemente puedas portarlo a C# sin muchos problemas. Tristemente, todo el esfuerzo que tomaría le costaría caro en rendimiento (pruébelo si no me cree).

Terminé llamando par2 ejecutable a través de CreateProcess. Puede obtener identificadores para stdin, stdout y strerr. Como el ejecutable es una aplicación de consola, puede analizar el resultado para obtener el progreso. Si desea "cancelar" la operación, siempre puede matar el proceso.

Es un método descuidado.

La forma "correcta" sería tomar la fuente par2 y llevarla a un dll de 64 bits (se adhieren a la DLL no administrada de C/C++ por razones de rendimiento).

+0

Si dices que saber portarlo a C# daría como resultado un gran golpe de rendimiento, ¿puedo preguntarte cómo lo sabes? ¿Lo has portado realmente o solo es una suposición educada? No estoy tan seguro de que portarlo a C# resulte en un gran golpe de rendimiento, es solo que no es algo en lo que quiero pasar mi tiempo :) – Led

+4

Me gusta la afirmación: "no es trivial. Probablemente podrías llevarlo a C# sin muchos problemas ". – JasonRShaver

1

¿Quieres quedarte con PARs? Tengo una implementación totalmente nativa de Reed/Solomon que publicaría si me ayuda (la coincidencia en la que se basan los PAR), pero no tengo nada para todo el manejo y la separación de archivos.

Mi código es una implementación de Stream y produce una cadena con todos los datos de corrección de errores incluidos. A continuación, puede dañar esos datos y enviarlos de vuelta, y el sistema los recuperará automáticamente. Simplemente lo publicaría pero es largo y soy demasiado vago para hacer una publicación de blog y vincularla.

Para que funcione como PAR, tendría que dividirlo en archivos, luego crear un sistema que pueda identificar los volúmenes faltantes y "agregar" datos corruptos para todos los datos faltantes (las matemáticas no pueden manejar datos faltantes, solo corrupto).

Además, como una nota sobre el rendimiento, el sistema para el que se fabricó fue más bien 'ráfaga', podría recibir muchas ráfagas de 100k a la vez, pero también tiene largas esperas de no hacer nada. La versión C# de las matemáticas funcionó aproximadamente un 6% más rápido que la versión C pura. Si realicé pruebas de rendimiento usando solo carga sin parar, el C# corre alrededor de un 1-2% más lento. En mi experiencia, la mayoría de las conversiones matemáticas de C a C# tienen los mismos resultados de rendimiento.

+1

Realmente apreciaría que lo publicaras, incluso si solo fuera como referencia. ¡Puede ser útil para otras personas también! – Led

+0

Ok, intentaré encontrarlo después del trabajo de hoy y editaré esta publicación donde se puede encontrar el código. – JasonRShaver

Cuestiones relacionadas