Je pense que la plus grande partie de TCP/IP qui empêche l'évolutivité est qu'il maintient un tampon sur toutes les connexions entrantes/sortantes jusqu'à la taille de la fenêtre. Donc, si j'ai un temps de latence élevé mais que je parle à un débit élevé, je dois garder tous les paquets envoyés dans le tampon jusqu'à ce que je reçoive un accusé de réception. Donc, pour quelques connexions, c'est bien, mais pour gérer les connexions 100K, cela peut commencer à être problématique. Du côté de la réception, si un paquet est abandonné, il tamponnera à nouveau tous les nouveaux paquets reçus jusqu'à ce que celui requis soit retransmis.
Si vous souhaitez implémenter la retransmission, vous devez faire la même chose et donc avoir la même surcharge. Cependant, UDP vous donne un avantage, si vous connaissez les vitesses de liaison de bout en bout, ou si certains messages peuvent être livrés dans le désordre ou si certains messages n'ont pas besoin d'être retransmis. Garder le scénario de jeu:
paquet 1 = passage à 1,1 paquet 2 = tournage paquet 3 = se déplacer à 2,2
La plupart des concepteurs de jeu, si le paquet 1 est perdu, mais paquet 3 est reçu , le paquet 1 n'est plus important car il contient de toute façon des informations périmées. Cependant, vous pourriez choisir de dire que le paquet 2 est important, donc s'il n'est pas accusé, envoyez une retransmission. Si vous avez besoin d'un haut débit et que vous connectez deux serveurs directement avec 1000Mbps ethernet, TCP/IP prendra un certain temps à l'échelle et aura un surcoût supplémentaire, et n'atteindra probablement jamais une véritable connexion Gigabit grâce aux mécanismes d'évitement de congestion. Cependant, vous savez que c'est 1 Gbps, donc vous pouvez configurer UDP pour transmettre jusqu'à 1 Gbps (moins frais généraux) vous-même. Pour répondre à vos questions plus directement: Si vous voulez tout acquitter, il n'y a pas grand avantage à avoir UDP, sauf que vous pouvez traiter certains messages en attendant la retransmission (sauf si vous voulez livraison en ordre aussi bien). Udp n'est pas autant considéré pour les serveurs de jeu, principalement en dehors du scénario ci-dessus, et les systèmes de combat en temps réel tels que les FPS, où un message peut être abandonné, et le nouveau message à venir invalidera la chute message de toute façon. World of Warcraft peut se permettre d'utiliser TCP, car ils n'ont pas besoin d'être aussi précis avec le timing, et ont probablement une bonne logique qui fait qu'il est plus difficile pour vous de faire la différence de toute façon. Le système de combat ne nécessite tout simplement pas la vitesse.
Je dirais aussi qu'une partie de la justification est la survivance d'il y a des années, quand tout le monde avait des connexions Internet moins fiables et plus lentes. TCP est également plus indulgent pour le partage du réseau, donc s'il se passe beaucoup de choses, il ralentira pour que tout le monde ait une part de la connexion (évitement de congestion).TCP/IP est un protocole conçu par des personnes bien plus intelligentes que moi pendant des années de recherche. Le réglage au cours des dernières années lui a permis de mieux fonctionner avec les vitesses réseau moyennes plus rapides et plus rapides que nous voyons, et ne nécessite pas une grande compréhension à utiliser. Cependant, remplacer ceci par UDP nécessite une compréhension significative de la mise en réseau. J'ai vu des programmes UDP mal écrits saturer des liens 1Gbps et tuer tout le trafic sur le lien, car ils ont implémenté un algorithme de retransmission plutôt naïf.
Voici une liste des choses que TCP/IP peut faire maintenant que vous perdriez en allant UDP: - Dans l'arrivée de la commande vous êtes programme - retransmission (maintenant avec réémission rapide, la reconnaissance sélective, et d'autres caractéristiques) - taille maximale du segment - Path MTU Discovery - Détection trou noir (extension de Path MTU) - congestion Avoidance
à cause de cela, je recommande fortement coller avec TCP/IP si cela vous convient êtes besoins .
Egalement à ne pas choisir nit, mais vous commentez sur l'Internet fonctionnant sur TCP/IP est faux, il y a en fait des douzaines de protocoles routables d'Internet check them out here. Je pense que vous avez fait référence à des pages Web et les serveurs Web sont tous en cours d'exécution sur TCP/IP. Ce qui encore une fois pour le web est super où les humains ne remarqueront pas un retard tant que la page s'affiche correctement. Même pour TCP/IP, leur défi est que TCP/IP n'est pas assez agressif pour le web: Google thinks tcp/ip should be more aggressive by default
Ouais ... c'est la partie "douleur dans le cul" qui me pousse à me demander. Mais je vais continuer à faire des recherches ... – IAbstract
Eh bien, c'est un des sacrifices que je suppose. Si vous utilisez ceci pour le jeu cependant, la meilleure pratique semble être UDP cependant. –
Je voudrais juste noter que l'utilisation de TCP est une idée horrible pour les jeux que si votre jeu fonctionne bien avec la "meilleure distribution de l'effort". Si votre jeu repose sur l'ordre des messages, et ne permet pas de laisser tomber les paquets, TCP finira généralement par être beaucoup plus rapide (les datagrammes UDP sont déposés * tout le temps * sur Internet). Des jeux comme Quake utilisaient UDP (et IPX) dès le début, car un paquet en retard est inutile de toute façon. Des jeux comme Age of Empires ou Civilization utilisaient TCP, car c'est tout le contraire: les messages individuels sont souvent inutiles jusqu'à ce que tous les messages précédents arrivent et soient traités. – Luaan