Supposons que vous ayez déjà un canal avec perte non fiable entre 2 homologues. Quelles méthodes pouvez-vous suggérer pour transférer des données de manière fiable et sans perte de performance? Le protocole sous-jacent n'est pas TCP (qui est déjà fiable). (Je canal avec perte de généraliser la question.)Transfert de données fiable sur un canal avec perte
(AFAIK, certaines méthodes existent comme TDR (rfc-908), Go Back-N.)
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission
Parce que quelqu'un a déjà résolu le problème et il y a une bibliothèque (TCP/IP) ou dix qui le fait dans toutes les langues qui existent.
Est-ce une question de philosophie?
+1 réponse simple mais très correcte. Rien de plus que cela est nécessaire. Je vous recommande de lire attentivement les spécifications et de comprendre pourquoi chaque bit dans un en-tête TCP est réellement là. Vous allez vous répondre très rapidement. – Poni
Eh bien, oui en effet toute la pile TCP peut être lue et on peut redécouvrir la méthode. Mais plutôt que de mettre en œuvre le protocole TCP, comme je l'ai dit, il existe d'autres méthodes. Ce que je demande est au niveau de l'application en effet, pas de protocole. – whoi
Assez juste. Je recommanderais de chercher des articles scientifiques sur ce sujet, dans les endroits habituels tels que l'IEEE. Il devrait y avoir une abondance sur la technologie WLAN. –
Sans perte de performance signifie généralement réduire la dépendance sur le canal arrière, à partir du récepteur envoyant des ACK à l'expéditeur. Cela signifie généralement un protocole personnalisé utilisant des datagrammes et utilisant une forme de correction d'erreur directe (FEC). Notez que FEC est une échelle mobile qui peut souvent être une pénalité de performance significative car, par définition, vous envoyez des données redondantes supplémentaires de manière préemptive afin que le destinataire n'ait pas à le demander.
http://en.wikipedia.org/wiki/Forward_error_correction http://udt.sourceforge.net/
Comme Steve-o dit, FEC et comme suggéré Kdansky Retransmission, sont de bons points de départ. Le principal goulet d'étranglement de Retransmission est le temps d'aller-retour, ce qui provoque le retard dans la réception d'un paquet perdu. Cependant, FEC est un sujet totalement différent et applicable au niveau du paquet. Comme Steve l'a dit à nouveau, le goulot d'étranglement devient le surcoût de bande passante que vous provoquez en générant un flux redondant. Bien que cela semble si simple, différents systèmes FEC tels que Parity FEC, Reed-Solomon, Turbo Codes, Raptor Q, etc ... ont des effets différents sur le délai, la bande passante, etc. selon leurs paramètres. (Surtout sur le taux d'encodage que vous utilisez pour générer le flux redondant)
Même après votre vérification indiquant que vous n'utilisez pas TCP - essayez d'imiter le comportement de TCP sur ce canal avec perte et vous obtiendrez un transfert de données fiable. – Poni
Poni, j'essaie de trouver d'autres protocoles au niveau de l'application. – whoi