cron2 wrote
Typical FEC implementations are not really helpful here, as packets do not get typically get corrupted in ways that FEC could help with, read "some bits get changed, but the packet still arrives, and FEC can be used to recover the original packet" - but if bits change, the underlying protocol (like "Ethernet") detect a broken checksum and drop the whole packet.
You didnt really understand what FEC is.Op's method is 100% workable.Try to google "erasure code" and "packet erasure channel" to make sure you understand what op talks about.
cron2 wrote
So what you could do is send the packet multiple times, in the hope that at least one of them gets through - but that would kill your bandwidth, and on a wireless link, might kill the rest of the usefulness for good...
You dont need to send packet multiple times,you can use reed solomon code,it adds m redundancy packet for every n original packets.If at least n of the m+n packets arrives,you can reconstruct the n packets. For examples,n can be 10 and m can be 3. It can significantly reduce packet loss(if packet loss isnt seriously so high that you cant get 10 out of 10+3) while the overhead is only 30%.
This is just what op meant by FEC.
Note:to use reed solomon,you may introduce a slight deplay if packets have to be reconstruct.But generally its not a big deal.
cron2 wrote
Other products do something like that if you have multiple available paths, that is, if you have 5 paths, packets are sent in 4 fragments + 1 parity fragment over the 5 links, and the receiver can reconstruct the packet as long as 4 out of 5 arrive. But this needs "multiple links" to start with...
To send redundancy data,"multiple links" is completely not necessary. In you example, 4 fragments + 1 parity can be transfer on a single channel.
