Qu'utilisez-vous lorsque vous avez besoin d'un UDP fiable?

Si vous avez une situation où une connexion TCP est potentiellement trop lente et une «connexion» UDP est potentiellement trop peu fiable, qu'utilisez-vous? Il existe différents protocoles UDP standard fiables, quelles expériences avez-vous avec eux?

Veuillez discuter d'un protocole par réponse et si quelqu'un d'autre a déjà mentionné celui que vous utilisez, envisagez de voter et d'utiliser un commentaire pour élaborer si nécessaire.

Je m'intéresse aux différentes options ici, dont TCP est à une extrémité de l'échelle et UDP à l'autre. Diverses options UDP fiables sont disponibles et chacune apporte certains éléments de TCP à UDP.

Je sais que souvent TCP est le bon choix, mais avoir une liste des alternatives est souvent utile pour aider à arriver à cette conclusion. Des choses comme Enet, RUDP, etc. qui sont construites sur UDP ont divers avantages et inconvénients, les avez-vous utilisés, quelles sont vos expériences?

Pour éviter tout doute, il n'y a plus d'informations, c'est une question hypothétique et j'espérais qu'elle susciterait une liste de réponses détaillant les différentes options et alternatives disponibles pour quelqu'un qui a besoin de prendre une décision.

Il est difficile de répondre à cette question sans quelques informations supplémentaires sur le domaine du problème. Par exemple, quel volume de données utilisez-vous? À quelle fréquence? Quelle est la nature des données? (par exemple, est-ce des données uniques, uniques? Ou est-ce un flux d'échantillons de données? etc.) Pour quelle plate-forme développez-vous? (par exemple bureau / serveur / intégré) Pour déterminer ce que vous entendez par «trop lent», quel support réseau utilisez-vous?

Mais en termes (très!) Généraux, je pense que vous allez devoir essayer très fort de battre TCP pour la vitesse, à moins que vous ne puissiez faire des hypothèses fermes sur les données que vous essayez d'envoyer.

Par exemple, si les données que vous essayez d'envoyer sont telles que vous pouvez tolérer la perte d'un seul paquet (par exemple, des données régulièrement échantillonnées où le taux d'échantillonnage est plusieurs fois supérieur à la bande passante du signal), vous pouvez probablement sacrifier une certaine fiabilité de la transmission en vous assurant que vous pouvez détecter la corruption des données (par exemple grâce à l'utilisation d'un bon CRC)

Mais si vous ne pouvez pas tolérer la perte d'un seul paquet, alors vous allez devoir commencer à introduire les types de techniques de fiabilité que TCP a déjà. Et, sans consacrer une quantité raisonnable de travail, vous constaterez peut-être que vous commencez à intégrer ces éléments dans une solution d'espace utilisateur avec tous les problèmes de vitesse inhérents.

Qu'en est-il du SCTP . C'est un protocole standard de l'IETF (RFC 4960)

Il a une capacité de segmentation qui pourrait aider à la vitesse.

Mise à jour: une comparaison entre TCP et SCTP montre que les performances sont comparables sauf si deux interfaces peuvent être utilisées.

Mise à jour: un bel article d'introduction .

ENET - http://enet.bespin.org/

J'ai travaillé avec ENET en tant que protocole UDP fiable et j'ai écrit une version conviviale pour les sockets asynchrones pour un de mes clients qui l'utilise dans leurs serveurs. Cela fonctionne très bien mais je n'aime pas la surcharge que le ping d'égal à égal ajoute aux connexions autrement inactives; lorsque vous avez beaucoup de connexions, les envoyer régulièrement est un travail très chargé.

ENET vous donne la possibilité d'envoyer plusieurs «canaux» de données et que les données envoyées ne soient pas fiables, fiables ou séquencées. Il comprend également le ping peer to peer susmentionné qui agit comme un keep alive.

Nous avons des clients de l'industrie de la défense qui utilisent UDT (UDP-based Data Transfer) (voir http://udt.sourceforge.net/ ) et en sont très satisfaits. Je vois que c'est aussi une licence BSD amicale.

RUDP - Protocole de datagramme utilisateur fiable

Cela fournit:

• Accusé de réception des paquets reçus
• Windowing et contrôle de la congestion
• Retransmission des paquets perdus
• Overbuffering (plus rapide que le streaming en temps réel)

Il semble légèrement plus configurable en ce qui concerne le maintien en vie que ENet, mais cela ne vous donne pas autant d'options (c'est-à-dire que toutes les données sont fiables et séquencées, pas seulement les bits que vous décidez d'être). Il semble assez simple à mettre en œuvre.

Comme d'autres l'ont souligné, votre question est très générale, et si quelque chose est «plus rapide» que TCP dépend beaucoup du type d'application.

TCP est généralement aussi rapide que possible pour une diffusion fiable des données d'un hôte à un autre. Cependant, si votre application effectue beaucoup de petites rafales de trafic et attend des réponses, UDP peut être plus approprié pour minimiser la latence.

Il existe un juste milieu. L'algorithme de Nagle est la partie de TCP qui permet de garantir que l'expéditeur ne submerge pas le récepteur d'un grand flux de données, ce qui entraîne une congestion et une perte de paquets.

Si vous avez besoin de la livraison fiable et dans l'ordre de TCP, ainsi que de la réponse rapide d'UDP, et que vous n'avez pas à vous soucier de la congestion due à l'envoi de gros flux de données, vous pouvez désactiver l'algorithme de Nagle:

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

Quiconque décide que la liste ci-dessus n'est pas suffisante et souhaite développer son propre UDP fiable devrait absolument jeter un coup d'œil à la spécification Google QUIC, car elle couvre de nombreux cas compliqués et des attaques de déni de service potentielles. Je n'ai pas encore joué avec une implémentation de ceci, et vous ne voudrez peut-être pas ou n'avez pas besoin de tout ce qu'il fournit, mais le document vaut la peine d'être lu avant de vous lancer dans une nouvelle conception UDP «fiable».

Un bon point de départ pour QUIC est ici , sur le blog Chromium.

Le document de conception QUIC actuel peut être trouvé ici .

Si vous avez une situation où une connexion TCP est potentiellement trop lente et une «connexion» UDP est potentiellement trop peu fiable, qu'utilisez-vous? Il existe différents protocoles UDP standard fiables, quelles expériences avez-vous avec eux?

Le mot clé dans votre phrase est «potentiellement». Je pense que vous devez vraiment vous prouver que TCP est, en fait, trop lent pour vos besoins si vous avez besoin de fiabilité dans votre protocole.

Si vous voulez obtenir de la fiabilité avec UDP, vous allez essentiellement ré-implémenter certaines des fonctionnalités de TCP en plus d'UDP, ce qui ralentira probablement les choses que d'utiliser simplement TCP en premier lieu.

Protocole DCCP, normalisé dans la RFC 4340 , "Datagram Congestion Control Protocol" peut être ce que vous recherchez.

Il semble implémenté sous Linux .

Peut-être RFC 5405 , "Unicast UDP Usage Guidelines for Application Designers" vous sera utile.

Avez-vous envisagé de compresser vos données?

Comme indiqué ci-dessus, nous manquons d'informations sur la nature exacte de votre problème, mais la compression des données pour les transporter pourrait aider.

RUDP . De nombreux serveurs socket pour les jeux implémentent quelque chose de similaire.

La meilleure façon d'obtenir la fiabilité à l'aide d'UDP est de renforcer la fiabilité dans le programme d'application lui-même (par exemple, en ajoutant des mécanismes d'acquittement et de retransmission)