C# parchive / quickpar / par2 repair implementation?

Question

I'm writing a C# app that needs to be able to repair a set of files using par2 parity files. For C++ there is lots to be found that'll do exactly that, but for C# I can't find a native implementation.

One option would be using a C++ DLL from C#, but I'd rather not do that since it's not possible to use a 32bits dll in an x64 app so I'd be limiting my app to 32bits mode.

Another option is to shellexecute par2cmdline in the background, but I'd rather have more control over the process (progress, cancelling etc.).

Does anyone know of a native C# implementation that'll repair files using a par2 set ?

Kenney

Answer 1

Do you want to stick with PARs themselves? I have a fully native Reed/Solomon implimentation I would post if it will help (the match that PARs are based on), but I don't have anything for all the file handling and breakup.

My code is an implementation of Stream and produces a string with all the error correcting data included. You can then corrupt that data and send it back and it system will automatically recover it. I would just post it but it is long and I am too lazy to make a blog post and link to it.

To make that work like PAR, you would have to break that up into files, then build a system that can identify missing volumes and 'adds in' corrupt data for all the missing data (the math cannot handle missing data, only corrupt).

Also, as a note on performance, the system this was built for was rather 'bursty', it would get in lots of 100k streams at a time, but also have long waits of doing nothing. The C# version of the math worked about 6% faster then the pure C version. If I did performance testing using just non-stop load, the C# runs about 1-2% slower. In my experience, most C to C# math conversions have the same performance results.

Belshin

I would really appreciate it if you'd post it, even if it just was for reference. It might be useful for other people too ! – Kenney

Ok, I will try to find it after work today and will edit this post with where the code can be found. – Belshin

Answer 2

It's not a direct answer but I think there is a way to load a 32 bit dll into a 64bit app:

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

From the article:

This solution requires additional work as the 32-bit surrogate process that loads the 32-bit DLL and exposes its API must be created. Also, some changes will be necessary on the 64-bit side as the consumer must use one of the IPC techniques instead of directly accessing the 32-bit DLL. It is worth noting that, in extreme cases, this additional work could be comparable to the work involved in developing a 64-bit version of the 32-bit DLL from scratch.

One possible way of reducing these costs is to implement a 64-bit wrapper' DLL that exposes the same functions, parameters, types and so forth as the original 32-bit DLL. This wrapper DLL can then make IPC-based calls to the original 32-bit DLL, which has been loaded into a surrogate process.

Contrabass

Thanks! This is an option, although as the article mentions it's probably just as much work as completely writing a par2-implementation in C# from scratch.. – Kenney

That's one thing I wouldn't want to write from scratch...ever! :-) – Contrabass

Answer 3

I was doing something like this a while back. If you look at the par2 source code, it's not trivial. You could probably port it to c# without much trouble. Sadly, all the effort that would take would cost you dearly in performance (try it if you don't believe me).

I ended up calling par2 executable via CreateProcess. You can get handles to stdin, stdout and strerr. Because the executable is a console app, you can parse the output to get the progress. If you want to "cancel" the operation you can always kill the process.

It's a sloppy method.

The "right" way would be to take the par2 source and port it to a 64-bit dll (stick with unmanaged C/C++ DLL for performance reasons).

Aplasia

If you claim to know porting it to C# would result in a major performance hit, may I ask how you know ? Have you actually ported it or is it just an educated guess ? I'm not so sure that porting it to C# would result in a major performance hit, it's just that that's not something I want to spend my time on :) – Kenney

I like the statement: "it's not trivial. You could probably port it to c# without much trouble". – Belshin