Provided by: liblcrq0.0_0.2.1-2_amd64 bug

NAME

       LCRQ - C library implementation of RFC6330 (RaptorQ) for Librecast

DESCRIPTION

       IP  Multicast is based on UDP, which is inherently unreliable. Packets may arrive out of order, or not at
       all. TCP provides unicast with a reliable messaging layer  on  top  of  this  unreliable,  connectionless
       medium.

       Unicast, however, is one-to-one only. Multicast could, in theory, use all of the same reliability options
       (ACKs etc.) as TCP, at the cost of not being scalable any more.

       Fortunately  there  are  other  ways to achieve similar reliability.  RFC3208 describes Pragmatic General
       Multicast (PGM) based on NAKs (negative acknowledgements). This, too, has scaling issues.

       Forwards Error Correction (FEC) offers us another approach.

       Thanks to parity checking in the network stack, we don't generally need  to  worry  about  errors  within
       packets.  Every packet has a checksum, and if that doesn't match, the packet is dropped before it reaches
       us. Our encryption provides further checking of data received.   We  need  only  concern  ourselves  with
       erasures.  ie. dropped packets.

       RaptorQ is an implementation of a class of systematic erasure codes called fountain codes.

       The  data  we want to send is split into blocks, and then pre-encoded into a set of intermediate symbols.
       From these intermediate symbols we can generate both our original source  symbols,  and  also  additional
       repair symbols.

       Provided  the  recipient receives at least a minimum value K' of these symbols (any unique combination of
       source and repair) the intermediate symbols can be reconstituted, and the original data recovered.

       RaptorQ is what is called a systematic encoding, because the set of symbols we send includes our original
       data as plain text. Provided all source symbols are received, the original data has been transmitted with
       no decoding overhead.  It is only in the case where we need to supplement the source symbols with  repair
       symbols that we must perform the decoding process.

CONFORMING TO

       RFC6330  (IETF)  describes  the  RaptorQ  proposed standard, which LCRQ more-or-less follows. The primary
       focus has been on building a fast, simple and dependency-free FEC implementation for use with  Librecast,
       and not on strict standards compliance. The code does, however, fairly closely follow the RFC.

EXAMPLES

       There is example code in the examples/ directory of the source repository.

BUGS

       If you find one, email bugs@librecast.net

SEE ALSO

       rq_init(3),   rq_free(3),   rq_query(3),   rq_encode(3),   rq_decode(3),   rq_symbol(3),   rq_pid2sbn(3),
       rq_pid2esi(3), rq_pidsetsbn(3), rq_pidsetesi(3)

       https://datatracker.ietf.org/doc/html/rfc6330

LCRQ                                               2022-07-15                                            LCRQ(7)