Nous avons un système (construit en C) en place qui effectue une communication sur UDP. Récemment, nous avons trouvé une nécessité de garantir la livraison des paquets. Ma question est la suivante: Quels seraient les ajouts minimaux à un système basé sur UDP pour assurer la livraison à l'aide de paquets ACK? Également, idéalement sans avoir à manipuler les en-têtes de paquets. Nous avons un contrôle de niveau d'application sur les paquets, y compris des numéros de séquence et des drapeaux ACK / NACK. Je me demande si c'est une cause perdue et que tout ce que nous essayons de faire sera essentiellement une version imparfaite et cassée de TCP. Fondamentalement, il y a une amélioration minimaliste que nous pouvons apporter pour obtenir une livraison garantie (nous n'avons pas besoin de nombreuses fonctionnalités de TCP telles que le contrôle de la congestion, etc.). Merci!
5 Réponses :
problème difficile. Je dirais que vous ne serez pas en mesure d'atteindre la fiabilité de TCP. Cependant, je comprends que parfois, vous devez avoir fiable UDP.
RUDP (un peu plus hardcore)
Jetez un coup d'œil au chapitre 8 et au chapitre 20 de Steven's Programmation réseau Unix, volume 1 . Il couvre un certain nombre d'approches différentes. L'article 20.5 "Ajout de fiabilité à une application UDP" est probablement le plus intéressant pour vous.
+1 pour une bonne référence. Lorsqu'elle a déjà fait quelque chose de similaire pour une mission de programmation, cette section était excellente.
J'ai une question en cours d'exécution ici qui collecte des réponses à "quoi utilisez-vous lorsque vous avez besoin fiable UDP". Les réponses sont peut-être beaucoup plus que vous ne le souhaitez que vous ne le souhaitez, mais vous pourrez peut-être consulter certains des protocoles fondés sur UDP et saisir uniquement la partie ACK dont vous avez besoin.
de mon travail avec le protocole ENet (un protocole UDP fiable), j'espère que vous avez besoin d'un numéro de séquence dans chaque datagramme UDP, un moyen d'envoyer un ACK pour les datagrammes que vous avez reçues, une manière de garder la maintenance datagrammes que vous avez envoyés jusqu'à ce que vous obteniez un ACK pour eux ou que vous sortez du temps et une façon de chronométrer les datagrammes pour lesquels vous n'avez pas encore reçu un ack ... J'ajouterais également un délai d'attente global pour quand vous décidez que Vous n'allez jamais livrer un datagramme particulier et, je suppose, un rappel à votre couche d'application pour l'informer de cette défaillance de livraison ...
TCP entrelace 3 services qui pourraient être pertinents (TCP correct fait beaucoup plus, mais je ne vais parler de 3).
Vous venez de dire que vous ne contrôlez pas ont besoin du flux, donc je ne vais pas même adresse que (comment vous annoncer une taille de fenêtre, etc. bien, sauf que vous aurez probablement besoin d'une fenêtre. Je vais à elle.)
Vous avez dit que vous avez besoin d'une livraison fiable. Ce n'est pas trop dur - vous utilisez ACKs pour montrer que l'expéditeur a reçu un paquet. livraison de base fiables ressemble à:
Ces trois étapes ne traitent pas ces questions:
Donc, pour votre application, vous avez dit que vous ne besoin livraison fiable - mais ne dit rien besoin d'eux dans l'ordre. Cela aura une incidence sur la façon dont vous mettre en œuvre le protocole.
(par exemple, où dans l'ordre n'a pas d'importance.. Vous copiez les dossiers des employés d'un ordinateur à l'autre n'a pas d'importance si le dossier d'Alice est reçue avant Bob, tant que les deux y arriver)
va sur la présomption que vous avez seulement besoin fiable (puisque c'est ce que vous avez dit dans votre post), vous pouvez réaliser cette opération plusieurs façons.
Votre expéditeur peut garder une trace des paquets non reconnus. Donc, s'il envoie # 3, 4, 5 et 6, et ne reçoit pas un accusé de réception pour 3 et 4, l'expéditeur sait qu'il doit réémission. (Bien que l'expéditeur ne sait pas si les paquets 3 et 4 étaient beaucoup, ou si leurs accusés de réception ont été perdus. De toute façon, nous devons Retransmettre.)
Mais votre expéditeur pourrait faire ACKs cumulés - donc dans l'exemple ci-dessus, il ne ferait que ack # 6 si elle avait reçu 3, 4 et 5. Cela signifie que le récepteur serait drop paquet 6 si elle n'a pas reçu les avant. Si votre réseau est très fiable, alors ce ne serait pas une mauvaise option.
Les protocoles décrits ci-dessus, cependant, ont une fenêtre - qui est, le nombre de paquets ne l'envoi de l'expéditeur à la fois? Ce qui signifie que vous avez besoin d'une sorte de fenêtrage, mais pas dans le but de contrôle de flux. How'll vous transmettez des tailles de fenêtre?
Vous pouvez le faire sans une fenêtre soit ayant la constante de la taille de la fenêtre, ou en faisant quelque chose comme stop-et-attente. La première pourrait être une meilleure option.
Quoi qu'il en soit, je n'ai pas directement répondu à votre question, mais j'espère l'ai signalé quelques-unes des choses qui méritent d'être examinés lors de cette architecturer. La tâche d'avoir « transfert fiable » sans pièces de contrôle de flux (comme fenêtrage) et sans égard à l'ordre est difficile! (Permettez-moi de savoir si je devrais donner plus de détails au sujet de certains de ce genre de choses!)
Bonne chance!
Le meilleur moyen d'implémenter ACK est de le faire dans la couche d'application. Le coap est un exemple de protocole d'application qui fonctionne sur UDP mais fournit un transfert de données fiable. Il conserve un identifiant de message pour tous les messages confirmables (CON) et envoie un récepteur envoie un paquet ACK avec le même identifiant de message. Tous les champs ACK et ID de message sont conservés à la partie de la couche d'application. Donc, si l'expéditeur ne reçoit pas de paquet ACK avec l'ID de message envoyé par lui, il transmet ce paquet. Le développeur d'applications peut modifier le protocole en fonction des besoins requis pour un transfert de données fiable.
Êtes-vous sûr que ça vaut le coup? Il suffit d'utiliser une technologie éprouvée contre un système homebrew. La performance est-elle claire ou vous optimisez-vous de manière prématurée?
Le système est en temps réel et est déjà conforme à la spécification qui appelle UDP.