我不知道要寻找什么，因为我从“纠错代码”中得到的只是与您不知道错误位置的情况相关的内容。因此，这些代码比我需要的要复杂得多，而且效率低下。
在下文中，请注意位等于数据包(因为只有整个数据包可能会丢失，因此位类比非常适合)。
是否有 ECC 考虑到您已经知道缺少哪些 k 位，并且只为您提供了一种在这 k 个位置重建数据流的方法？此外，ECC 添加的位应该是独立的(最好是)。这样，如果数据的 ECC 部分内部发生丢包，它仍然可以重建一些原始数据(并非总是会有 k 个错误，大多数情况下不会有错误。所以重要的是 ECC 对自己的容错添加了 ECC 位)。
这是 IMO 的一个很大区别。对于缺少的一位很简单，我可以只使用一个 XOR 位。但我不够聪明，无法将其推广到 n 位。
再说一次，我有一个 n 位流，我知道最多缺少 k 位(我真的很清楚哪些是哪些，哪些是缺失的，不可能发生损坏)。现在我需要一个编解码器，它可以在尽可能少地向数据流中添加开销的情况下重建它们。我梦想有 (n+k) 位来纠正 n 位流中的 k 个随机位错误:)。最重要的是，理想情况下，如果添加到 n 位数据流的 k 个 ECC 位中的任何一个被破坏，比如说 k 位的 c 位被破坏，那么它仍然应该能够重建 (kc) 位错误n 位流。
请注意ofc，虽然xD我不知道错误位置。
例子:
我能想到的一种算法是这个。要防止错误的 n 位数据流。
设 p 是 n 的最小相对素数。然后用 i = (p * j) mod n 迭代数据流，通过增加 j，对通过选择每个偶数 j 的位获得的子流进行异或。这个子流有 n/2 个元素。迭代后，我们获得了 n/2 个元素的奇偶校验。我们可以用同样的方式获得另一半的另一个奇偶性(取奇数 j)。
对于 2 位丢失，这可以减少 50% 的错误。
好的一面是我们现在可以任意变得更好。只需取下一个更高的相对素数，然后再做同样的事情。现在我们有 25% 的错误率。基本上，每次我们添加两个额外的奇偶校验位时，我们可以将错误机会减少一半。
最佳答案
您需要一个 擦除 代码(不是错误检测代码)。错误检测由链路层和传输层负责。由于您正在尝试减少 UDP 数据包丢失，您已经知道丢失了哪些部分——丢失的数据包丢失了。
在字节(或位)级别上没有擦除或错误这样的事情，至少没有任何合理的可能性(至少有两个底层协议(protocol)，有时是三个，每个都有一个校验和，以确保这一点) .您要么收到一个完整的、完整的数据报，要么没有。从来没有介于两者之间。
Cauchy Reed Solomon 码是您可能会考虑的一类算法，这些算法将 k 个一定长度的数据块转换为 k+m 个块，并允许恢复最多给定的原始数据。这种算法的一个特例是奇偶校验，其编码和解码都是一个简单的异或运算，m=1。这正是 Raid-5 中使用的算法，在上面的评论中提到过。
一句话，你想要 longhair 。
作为替代方案，如果您有大量数据要传输给多方，并且想要花哨，则可以考虑喷泉代码。这些更复杂(因此更慢)并且位效率更低，但它们允许您创建任意数量的数据包，其中任何 k 将重建 k 长度的原始消息。如果您能够向需要一组大量数据但不一定同时开始下载的许多客户端进行多播，则这可以让您节省大量带宽。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
关于c++ - 丢包纠错码 (UDP)，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/28924342/