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

Question

Si vous êtes dans une situation où une connexion TCP est potentiellement trop lente et une "connexion" UDP est potentiellement trop peu fiable, qu'utilisez-vous ? Il existe plusieurs protocoles UDP standards et fiables, quelles sont vos expériences avec eux ?

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

Je suis intéressé par les différentes options, 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 le PCT est souvent le bon choix, mais il est souvent utile de disposer d'une liste des alternatives pour arriver à cette conclusion. Des choses comme Enet, RUDP, etc., qui sont construites sur UDP, ont des avantages et des inconvénients divers.

Pour éviter tout doute, il n'y a pas d'autres informations, il s'agit d'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 doit prendre une décision.

Answer 1

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

Il dispose d'une capacité de découpage en morceaux qui pourrait contribuer à la rapidité.

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

Mise à jour : a bel article d'introduction .

Answer 2

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, s'agit-il de données uniques, ponctuelles, ou d'un flux de données échantillons, etc.) Pour quelle plate-forme développez-vous ? (par exemple, bureau/serveur/embarqué). 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 faire de gros efforts pour battre tcp en termes de vitesse, à moins que vous ne puissiez faire des hypothèses précises 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 transmission en vous assurant que vous pouvez détecter la corruption des données (par exemple, par 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 possède déjà. Et, sans y mettre une quantité raisonnable de travail, vous pouvez trouver que vous commencez à construire ces éléments dans une solution d'espace utilisateur avec tous les problèmes de vitesse inhérents qui vont avec.

Answer 3

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

J'ai travaillé avec ENET en tant que protocole UDP fiable et j'ai écrit une version asynchrone adaptée aux sockets pour un de mes clients qui l'utilise dans ses serveurs. Cela fonctionne très bien mais je n'aime pas l'overhead que le peer to peer ping ajoute à des connexions par ailleurs inactives ; lorsque vous avez beaucoup de connexions, envoyer régulièrement des ping à chacune d'entre elles représente beaucoup de travail.

ENET vous donne la possibilité d'envoyer plusieurs "canaux" de données et de faire en sorte que les données envoyées soient peu fiables, fiables ou séquencées. Il inclut également le ping peer to peer mentionné plus haut qui agit comme un keep alive.

Answer 4

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

Answer 5

Comme d'autres l'ont souligné, votre question est très générale, et le fait qu'un élément soit ou non "plus rapide" que le TCP dépend beaucoup du type d'application.

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

Il existe un terrain d'entente facile. L'algorithme de Nagle est la partie du TCP qui permet de s'assurer que l'expéditeur ne submerge pas le récepteur d'un grand flux de données, ce qui entraîne une congestion et la 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 grands 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");