Update: RaptorQ

Since this blog is less used than I would like to, I have decided to start writing about the other projects I am working on, all somehow connected to the Fenrir Project.

So I will start writing about libRaptorQ and Tyr (not public yet).
Both these projects are related to error correction, and while libRaptorQ will be used in Fenrir, but I will talk about Tyr in a second post.

libRaptorQ

If you have followed a bit the Fenrir Project you should now that the first project I started in this series was this Forward Error Correction library.

It is an open source (LGPL3) implementation of RFC6330.
The main idea behind FEC is that instead of sending X packets, waiting for the other end to acknowledge them, resend lost/corrupted packets, you can just send more packets (repair packets) and the receiver will somehow combine those to get the original data, without any ACK mechanism.

This is really useful in high-latency networks, or in wireless scenarios where the medium is really noisy and causes lots pf lost/corrupted packets.

…So, what has been boing on here?

lRQ news

libRaptorQ stable version v0.1.10 is out, and the work done in the last month makes it both incompatible with previous versions (the algorithm was implmented incorrectly) and RFC conformant.

I was aiming for compatibility with OpenRQ, but that is still unlikely.
Right now OpenRQ as a (simple?) bug to fix to fix their compliancy, but even then it does not mean we will ever be compatible.

The reason is that OpenRQ uses lots of hashsets and then iterates over he elements in those, and that gives you an almost-random starting point, which is not reproducible in other ways.
It does not mean that we are not compatible actually, since both behaviours are RFC compliant things might work out, but I have not tested it yet.

The new stable of libRaptorQ is also coming along nicely, and things are generally much more stable, we entered a beta release.
The documentation is still written only for the RFC API, and not for the new, simpler, faster RAW API yet, so I will not release it although it’s basically ready.

Future of libRaptorQ

libRaptorQ 0.1.X at this point is bugfix-only. Version 1.0 will not receive additional features, except for handling RFC packets (which contain multiple symbols in a specific way).

After this work will start on version 1.1 which should maintain the same API but increase performance by a big margin. The internal matrices will be handled by hand to leverage AVX/SSSE and we will be able to use different libraries for that (maybe Blaze). We should also be able to compile different parts with different optimizations so that your CPU will use the fastest code even with packaged distribution.

I have been contacted by a company who was interested in that, and has written some patches which I did not pull yet due to the commits being too big and the code style being too closer to C than to C++11. But the patches are there so either they will fix it or I will slowly import things The Right Way™

When will this happen? Don’t know. When it’s ready. As always, I am not getting paid for this so if you want to see a speedup, consider donating via or

…or hiring, that works, too ;)

-Luker