LCRQ(7)

💖 LCRQ — the glow-up edition 💖

okay bestie, welcome to the Librecast Programmer's Manual page for LCRQ, aka section 7, aka the vibes page. yes it's LCRQ(7) if you're being formal about it, but we're not. sit down, grab a strawberry 🍓, and let's talk about making multicast not fall apart.

---

✨ NAME ✨

LCRQ — a C library implementation of RFC6330 (RaptorQ) for Librecast. that's the whole name, that's the whole job, and honestly? iconic. 👑

---

🌈 DESCRIPTION 🌈

so here's the tea. IP Multicast is built on top of UDP, and UDP is inherently unreliable. no cap. packets may show up out of order, or like… not show up at all. ghosted. 💀

meanwhile TCP gives unicast a whole reliable messaging layer stacked on top of that unreliable, connectionless medium. she's doing the work, she's carrying the team, she's got receipts.

but bestie, unicast is one-to-one only. and multicast could, in theory, use all of the same reliability options (ACKs etc.) as TCP — at the cost of not being scalable any more. and like, scalability is the entire point, so that's a no. 🙈

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. sad! 😭
• Forwards Error Correction (FEC) offers us another approach. and this is our girl. this is the one.

here's why FEC gets to be the main character: 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 ever reaches us. our encryption provides further checking of data received. so we need only concern ourselves with erasures — ie. dropped packets. that's it. that's the whole enemy. 🎯

---

🦋 RaptorQ, explained while I do my nails 🦋

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. two for one, we love a multitasker. 💅

provided the recipient receives at least a minimum value K' of these symbols — and it can be any unique combination of source and repair — the intermediate symbols can be reconstituted, and the original data recovered. periodt. ✨

RaptorQ is what's 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. no wasted effort, no extra homework, she's efficient. 🔥

---

📜 CONFORMING TO 📜

RFC6330 (IETF) describes the RaptorQ proposed standard, which LCRQ more-or-less follows.

real talk though: 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. so like, she's not a rule-follower, she's a results girlie. 💁

---

🎀 EXAMPLES 🎀

there is example code in the examples/ directory of the source repository. go look, it's right there, it's giving tutorial energy. 🫶

---

💀 BUGS 💀

if you find one, email bugs@librecast.net

(not me manifesting a bug-free codebase 🙏 but if you do catch one, tell us, we wanna know fr fr)

---

🔍 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)

and also, for the lore:

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

---

💜 cute sign-off: this page is brought to you by LCRQ, dated 2022-07-15, living in section 7 of the Librecast Programmer's Manual. go forth and multicast responsibly, bestie. bye!! 🌸🦋✨