Que devrais-je savoir sur la programmation UDP?

“Je suppose que si j’envoie 200 octets, je peux obtenir 120 et 60 octets séparément?”

Lorsque vous envoyez des datagrammes UDP, votre taille de lecture sera égale à votre taille d’écriture. En effet, UDP est un protocole de datagramme , comparé au protocole de stream de TCP. Toutefois, vous ne pouvez écrire que des données allant jusqu’à la taille de la MTU avant que le paquet puisse être fragmenté ou abandonné par un routeur. Pour une utilisation générale d’Internet, le MTU du coffre-fort est de 576 octets, en-têtes compris.

“Je devrais m’inquiéter d’une autre connexion m’envoyant de mauvaises données sur le même port?”

Vous n’avez pas de connexion, vous avez un port. Vous recevrez toutes les données envoyées à ce port, peu importe d’où elles proviennent. C’est à vous de déterminer si c’est à la bonne adresse.

Si les données n’arrivent pas en général, combien de temps puis-je (généralement) ne pas voir les données pendant (250 ms? 1 seconde? 1,75 sec?)

Les données peuvent être perdues à tout jamais, les données peuvent être retardées et les données peuvent arriver dans le désordre. Si l’un de ces problèmes vous dérange, utilisez TCP. Écrire un protocole fiable en plus du protocole UDP est une tâche peu banale et il n’ya aucune raison de le faire pour presque toutes les applications.

Devrais-je m’inquiéter d’une autre connexion qui m’envoie des données incorrectes sur le même port?

Oui, vous devriez vous en préoccuper. Toute application peut envoyer des données à tout moment sur votre port UDP ouvert. L’une des utilisations les plus importantes d’UDP réside dans les communications à plusieurs styles: vous multiplexez des communications avec plusieurs pairs sur un même port en utilisant l’adresse renvoyée lors du recvfrom pour différencier les pairs.

Cependant, si vous voulez éviter cela et n’accepter que les paquets d’un seul pair, vous pouvez appeler la connect sur votre socket UDP. Ceci a pour effet que la stack IP rejette les paquets provenant de n’importe quel hôte: port combo (socket) autre que celui avec lequel vous voulez parler.

Le deuxième avantage de la connect appel sur votre socket UDP est que, dans de nombreux systèmes d’exploitation, cela améliore considérablement la vitesse / latence. Lorsque vous appelez sendto sur un socket UDP non connecté, le système d’exploitation connecte temporairement le socket, envoie vos données, puis déconnecte le socket, ce qui augmente considérablement la surcharge.

Le troisième avantage de l’utilisation de sockets UDP connectés est qu’il vous permet de recevoir des messages d’erreur ICMP, tels que le routage ou un hôte inconnu, en raison d’un crash. Si le socket UDP n’est pas connecté, le système d’exploitation ne saura pas où envoyer les messages d’erreur ICMP du réseau et les éliminera en silence, ce qui risquerait de bloquer votre application en attendant une réponse d’un hôte bloqué (ou en attente de votre message). sélectionnez pour expirer).

Votre paquet peut ne pas y arriver.

Votre paquet peut y arriver deux fois ou même plus souvent.

Vos paquets peuvent ne pas être en ordre.

Vous avez une limite de taille sur vos paquets imposée par les couches réseau sous-jacentes. La taille du paquet peut être assez petite (éventuellement 576 octets).

Rien de tout cela ne dit “n’utilisez pas UDP”. Cependant, vous devez être conscient de tout ce qui précède et réfléchir aux options de récupération que vous souhaitez peut-être prendre.

La fragmentation et le réassemblage se font au niveau IP, vous n’avez donc pas à vous en préoccuper (Wikipedia) . (Cela signifie que vous ne recevrez pas de paquets divisés ou tronqués).

Les paquets UDP ont une sum de contrôle pour les données et l’en-tête, il est donc improbable, mais possible, de recevoir de fausses données. Les paquets perdus ou en double sont également possibles. De toute façon, vous devriez vérifier vos données.

Il n’ya pas de contrôle de congestion, vous pouvez donc envisager de le faire si vous envisagez d’obstruer les tubes avec beaucoup de paquets UDP.

UDP est un protocole sans connexion. L’envoi de données via UDP peut arriver au destinataire, mais peut également être perdu pendant la transmission. Le format UDP est idéal pour la diffusion et la diffusion audio ou vidéo en continu (c.-à-d. Qu’un paquet perdu ne pose jamais de problème dans ces situations.) Si vous devez vous assurer que vos données parviennent à l’autre côté, respectez le protocole TCP.

UDP a moins de surcharge que TCP et est donc plus rapide. (TCP doit d’abord établir une connexion et vérifier également que les paquets de données sont corrompus, ce qui prend du temps.)

Les routeurs fragmenteront probablement les paquets UDP fragmentés (c’est-à-dire des paquets dont la taille est supérieure à environ un demi-Ko). Par conséquent, divisez vos données en petits morceaux avant de les envoyer. (Dans certains cas, le système d’exploitation peut s’en charger.) Notez que c’est toujours un paquet qui le fabrique, ou non. Les demi-paquets ne sont pas traités.

La latence sur de longues distances peut être assez importante. Si vous voulez faire la retransmission de données, je choisirais environ 5 à 10 fois le temps de latence moyen de la connexion en cours. (Vous pouvez mesurer la latence en envoyant et en recevant quelques paquets.)

J’espère que cela t’aides.

Je ne ferai pas de même avec les autres personnes qui ont répondu à cette question, elles semblent toutes vous pousser vers le protocole TCP, et ce n’est pas du tout pour les jeux, sauf peut-être pour les informations de connexion / chat. Allons dans l’ordre:

Dois-je m’inquiéter des mauvaises données dans mon socket?

Oui. Même si UDP contient une sum de contrôle extrêmement simple pour les routeurs et autres, il n’est pas efficace à 100%. Vous pouvez append votre propre appareil de sum de contrôle, mais la plupart du temps, le protocole UDP est utilisé lorsque la fiabilité n’est pas déjà un problème. Par conséquent, les données non conformes doivent être simplement supprimées.

Je suppose que si j’envoie 200 octets, je peux obtenir 120 et 60 octets séparément?

Non, UDP est l’écriture et la lecture directes de données. Toutefois, si les données sont trop volumineuses, certains routeurs seront tronqués et vous perdrez une partie des données de manière permanente. Certains ont dit à peu près 576 octets avec en-tête, je n’utiliserais personnellement pas plus de 256 octets (nombre rond de log2).

Devrais-je m’inquiéter d’une autre connexion qui m’envoie des données incorrectes sur le même port?

UDP écoute toutes les données de n’importe quel ordinateur sur un port, alors oui. Notez également que UDP est une primitive et qu’un format brut peut être utilisé pour simuler l’expéditeur. Vous devez donc utiliser une sorte de “clé” pour que l’écouteur vérifie l’expéditeur par rapport à son IP.

Si les données n’arrivent pas en général, combien de temps puis-je (généralement) ne pas voir les données pendant (250 ms? 1 seconde? 1,75 sec?)

Les données envoyées sur UDP sont généralement jetables. Par conséquent, si vous ne recevez pas de données, vous pouvez facilement les ignorer … Cependant, vous voulez parfois “semi-fiable” mais vous ne voulez pas “ordonné”, comme l’utilisation de TCP, 1 seconde est une bonne estimation d’une goutte. Vous pouvez numéroter vos paquets sur une rotation et écrire votre propre communication ACK. Quand un paquet est reçu, il enregistre le numéro et renvoie un champ de bits laissant l’émetteur connaître les paquets qu’il a reçus. Vous pouvez lire ce document inachevé pour plus d’informations (bien qu’inachevé, il donne toujours des informations valables):

http://gafferongames.com/networking-for-game-programmers/

La chose importante à savoir lorsque vous essayez d’utiliser UDP est:

Vos paquets risquent de ne pas tous traverser la ligne, ce qui signifie que des données risquent d’être corrompues.

Si vous travaillez sur une application où 100% des données doivent arriver de manière fiable pour fournir des fonctionnalités, utilisez TCP. Si vous travaillez sur une application dans laquelle certaines pertes sont admissibles (diffusion multimédia en continu, etc.), optez pour UDP, mais ne vous attendez pas à ce que tout soit parfaitement intact.

Une façon de voir la différence entre les applications appropriées pour UDP et TCP est que TCP est bon lorsque la livraison des données est “meilleure tard que jamais”, UDP est bonne lorsque la livraison des données est “mieux vaut jamais que tard”.

Un autre aspect est que la nature sans effort et au mieux de la plupart des applications basées sur UDP peut rendre l’évolutivité un peu plus facile à réaliser. Notez également que UDP peut être multicast alors que TCP ne le peut pas.

En plus de la recommandation de don.neufeld d’utiliser TCP.

Pour la plupart des applications, TCP est plus facile à mettre en œuvre. Si vous devez conserver les limites de paquets dans un stream TCP, un bon moyen consiste à transmettre un en-tête de deux octets avant les données pour délimiter les messages. L’en-tête doit contenir la longueur du message. À la réception, il suffit de lire deux octets et d’évaluer la valeur. Ensuite, attendez que vous ayez reçu autant d’octets. Vous avez alors un message complet et êtes prêt à recevoir le prochain en-tête de 2 octets.

Cela vous donne une partie des avantages du protocole UDP sans les tracas de données perdues, d’arrivées de paquets hors d’ordre, etc.

Et ne supposez pas que si vous envoyez un paquet, il l’a reçu.

S’il existe une limite de taille de paquet imposée par un routeur le long du chemin, vos paquets UDP peuvent être tronqués de manière silencieuse à cette taille.

Deux choses:

1) Vous pouvez ou non recevoir ce qui a été envoyé

2) Tout ce que vous recevez peut ne pas être dans le même ordre qu’il a été envoyé.