J'utilise TCP pour communiquer avec un arduino (il suffit d'ouvrir une socket et d'attendre une connexion) en utilisant un bouclier ethernet, tout en regardant/lire sur divers autres projets qui utilisent une sorte d'interface réseau pour communication, ils semblent tous utiliser UDP au lieu de TCP pour la communication. Ce que je me demandais est ce qui serait mon gain si j'utilise UDP à la place?TCP vs UDP pour la communication par microprocesseur
Une pile UDP est considérablement plus simple qu'une pile TCP. Vous pouvez facilement écrire une pile UDP à partir de rien, TCP est un peu plus difficile, faisable mais plus difficile. TCP a construit dans les tentatives et d'autres choses afin que vous ne perdiez pas la fiabilité avec UDP directement, c'est ce que vous en faites qui pourrait comparer. UDP est significativement plus rapide que TCP et c'est pourquoi il est ou a été utilisé pour la vidéo et diverses choses dans la journée. Aussi des choses comme la vidéo pourraient supporter de perdre un paquet ici et là et ne s'en soucient pas. Pour UDP embarqué, c'est plutôt sympa d'être petit, rapide, etc. Si vous utilisez une bibliothèque de quelqu'un d'autre, alors UDP ne va probablement pas vous faire économiser beaucoup sur les ressources mémoire/flash, il sera encore un peu plus rapide. C'est lorsque vous implémentez votre propre UDP que vous économisez un peu sur la mémoire, car vous pouvez couper les coins. Vous pouvez faire des choses comme seulement implémenter arp et udp et rien d'autre (bien que ping soit utile mais en quelque sorte douloureux), et vous pouvez couper des coins sur arp/rarp en fonction de ce que vous devez faire avec cette chose. Vous pouvez implémenter le support uniquement pour la taille de paquet qui vous intéresse. Numéroter vos paquets et avoir le côté demandeur envoyer deux ou trois de tout et répondre à chaque demande peut réduire considérablement le problème de paquet perdu. Garder la taille des paquets très petite aide à la fois le problème de ressources intégré et évite tout problème de mtu ou d'autres problèmes en cours de route. Pour plus de simplicité, vous pouvez même forcer une longueur de paquet spécifique.
Je pose toujours la question de l'autre côté, que gagnerais-je à utiliser TCP? Il y a des moments où c'est utile, embarqué, bureau ou serveur bien que je pose toujours cette question à chaque fois et que je doive justifier l'utilisation de TCP sur UDP sinon je ne l'utiliserai pas.
Vous bénéficiez d'une multidiffusion, mais vous perdez la fiabilité.
également moins de frais généraux avec UDP http://www.skullbox.net/tcpudp.php –
Vous gagnez de l'espace de code, de la mémoire de données et du déterminisme.
Une bonne quantité de mémoire est requise pour réassembler un flux TCP, sauf si vous voulez NAK chaque paquet qui n'est pas en ordre. Ils ne sont jamais garantis dans l'ordre ....
Un protocole de réponse-commande asynchrone avec des délais d'attente, où toutes les commandes et réponses tiennent dans un seul paquet UDP, et les commandes sont idempotentes (peuvent être appliquées plusieurs fois et maintenir le résultat correct) est un protocole assez robuste.
Notez également que tcp est basé sur les flux et que udp est basé sur les paquets. Donc * si * vous obtenez le paquet udp, vous obtiendrez le tout. * Quand * vous obtenez le paquet tcp, il n'y a aucune garantie qu'il arrive comme il est parti. Si vous supposez qu'il se comporte comme udp vous perdrez des données/paquets parce que vous ne réaliserez pas que ces deux petits paquets si souvent étaient vraiment plus gros. Ajoute aux besoins de mémoire et la quantité de code qu'il faut pour analyser le paquet sur le code supplémentaire pour la pile tcp, etc. –
... vous ne réaliserez pas ces deux, petits paquets, si souvent, ... –