mmm... l'idée n'est pas conne. En réseau, il y a de la perte de paquets, que ce soit purement des problèmes de routage IP, ou des problèmes liés au média (WiFi, etc.). C'est (entre autres) pour cela que TCP existe: il envoie une confirmation des paquets reçus, et permet la ré-émission des paquets perdus. Mais cela a un coût: demander les retransmissions, les attendre, être limité par la fenêtre TCP...   Alors voilà l'idée: Plutôt que redemander les paquets perdus, on calcul en permanence des codes genre Reed-Solomon qui sont transmis avec les données.
S'il manque un paquet, on le reconstruit à l'aide des codes correcteurs déjà reçu (à la manière de PAR2).

Pas con du tout. Avec ce principe, on pourrait (certains vont hurler) ré-inventer TCP à l'aide de paquets UDP: Transmettez les données en UDP plein pot (on évite la négo TCP et son fenêtrage) en entremêlant des paquets contenant des codes correcteurs. Les paquets UDP manquants ne sont pas redemandés, ils sont calculés à partir des codes correcteurs.
On pourrait même imaginer que le taux de paquets "code correcteurs" s'adapte automatiquement, ou alors prévoir juste l'envoi d'un paquet demandant l'augmentation de la proportion des paquets correcteurs.

Intéressant.

C'est assez similaire au protocole Avalanche de Microsoft, sauf que ça se situe plus bas dans les couches réseau.

(J'ai un article en préparation sur les codes correcteurs, et un exemple pratique avec PAR2. Je publierai ça un de ces jours.)