OpenRQ is an open source project, which implements the RaptorQ FEC scheme described in RFC 6330. Our aim is to provide to developers a library that is easy to use and incorporate on their applications, whilst maintaining RaptorQ’s acclaimed performance and resillience. For a (very) general idea on FEC, fountain codes and Raptor codes keep reading the next few paragraphs.
Forward error correction (FEC) is a technique for the recovery of errors in data disseminated over unreliable or noisy communication channels. The central idea is that the sender encodes the message in a redundant way by applying an error-correcting code, which allows the receiver to repair the errors. An erasure code is a FEC code with the capability to recover from losses in the communications. The data is divided into K source symbols, which are transformed in a larger number of N encoding symbols such that the original data can be retrieved from a subset of the N encoding symbols. One immediate benefit of this approach is that the receiver gains the ability to amend the errors without needing a reverse channel to request the retransmission of data, but at the cost of a fixed, higher bandwidth forward channel. FEC is therefore applied in situations where retransmissions are costly, such as when broadcasting data to multiple destinations, or when communication links are one-way.
Fountain codes are a class of erasure codes with two attractive properties: an arbitrary number of encoding symbols can be produced on the fly, simplifying the adaptation to varying loss rates; and the data can be reconstructed with high probability from any subset of the encoding symbols (of size equal to or slightly larger than the number of source symbols). A typical use case scenario for fountain codes appears when a single source multicasts a file to many destinations. In such a scenario, resorting to TCP channels would not be scalable because the sender needs to keep track of which packets arrive at each receiver. Multicasting with UDP would solve this limitation, but would lack the reliability offered by TCP. Coding the file with a fountain code and disseminating over UDP addresses both problems — each receiver would be able to recover the (different) erasures affecting its own channel, without the need for retransmissions.
Raptor codes (or Rapid Tornado)  are the closest solution to an ideal digital fountain code. They have the capability of achieving constant per-symbol encoding/decoding cost with an overhead near to zero. Up to this point, two versions of Raptor codes have been standardized by the Internet Engineering Task Force (IETF), called R10 and RaptorQ. R10 appeared first, and over the years was adopted into a number of different standards, covering areas related to the transmission of data over cellular networks, satellite communications, IPTV and digital video broadcasting.
RaptorQ is the most recent Raptor code to be described, and it provides a greatly enhanced reliability with efficient encoding and decoding functions. For this reason, in the future it may obsolete R10. Currently, RaptorQ has been standardized in RFC 6330, but there is the expectation that other standards will also adopt it. In addition, it has been employed with various kinds of applications, including in the military for critical operations, and in settings where communication may be intermittent and/or with high loss rates (e.g., after natural disasters).
From the work made on top of OpenRQ, a publication was made regarding the resilience of the RaptorQ code when facing malicious (selective) network faults.
• J. Lopes and N. Neves, “Stopping a Rapid Tornado with a Puff”, 35th IEEE Symposium on Security and Privacy, May 2014.
For his masters’ thesis, José proposed studying the resilience of the RaptorQ code against malicious faults. Confronted with the inexistence of any free/open implementation of the standard, part of José’s work was implementing RFC 6330.
After completing his study on RaptorQ’s resilience, José thought it would be a shame to let all the time and effort put in implementing RFC 6330 go to waste. Given the lack of open RaptorQ implementations, the obvious choice was to make it an open source project.
You can contact José via e-mail or twitter:
As one of the tasks in his masters’ thesis, Ricardo developed a working LT Code  implementation. Afterwards, Ricardo became interested in fountain codes in general, and Raptor codes in specific.
Currently, Ricardo is helping maintain the project, adding new/better functionalities and improving the encoding and decoding performance.
You can contact Ricardo via e-mail: