Certains jeux utilisent aujourd'hui un système de réseau qui transmet des messages via UDP et garantit que les messages sont fiables et commandés.
Par exemple, Raknet est un moteur réseau de jeu populaire. Il utilise uniquement UDP pour ses connexions et dispose d'un système entier pour vous assurer que les paquets peuvent être fiables et commandés si vous le souhaitez.
Ma question de base est, qu'est-ce qui se passe avec ça? TCP n'est-il pas la même chose que commandé, fiable UDP? Ce qui le rend tellement plus lent que les gens doivent réinventer essentiellement la roue?
6 Réponses :
TCP est un protocole orienté vers le flux, alors que l'UDP est un protocole orienté des messages. Par conséquent, TCP fait plus que la juste fiabilité et la commande. Voir Cet article Pour plus de détails. Fondamentalement, les développeurs Raknet ont ajouté la fiabilité et la commande tout en la surveillant comme un protocole orienté par message, et le résultat était donc plus léger que TCP (qui doit faire plus).
Les choses spécialisées sont généralement meilleures que les choses à usage général pour la chose qu'ils sont spécialisées.
Envoi de cartes discrètes d'informations de jeu généralement mieux à un paradigme basé sur un message. L'envoi d'un courant est possible mais horriblement inefficace. Si vous souhaitez envoyer de manière fiable une énorme quantité de données (transfert de fichiers), TCP est assez efficace. C'est pourquoi Bit-Torrent Utilisez UDP pour les messages de contrôle et TCP pour l'envoi de données.
Il y a beaucoup plus de différence entre UDP et TCP que la simple fiabilité et séquençage:
au cœur de la question est le fait que UDP est sans connexion tandis que TCP est connecté . Cette différence simple conduit à une foule d'autres différences que je ne vais pas résumer considérablement ici. Vous pouvez lire l'analyse ci-dessous pour plus de détails.
La réponse à mon avis Les deux mots: "Contrôle de la congestion".
TCP passe à de grandes longueurs pour gérer la bande passante du chemin - pour en utiliser le meilleur parti, mais pour vous assurer d'espace pour d'autres applications. Il s'agit d'une tâche très difficile et, de manière intrinsèquement, il n'est pas possible d'utiliser 100% de la largeur de bande 100% du temps.
avec UDP, d'autre part, on peut créer leur propre protocole pour envoyer les paquets sur le fil aussi vite qu'ils le souhaitent - cela rend le protocole très hostile à d'autres applications, mais peut gagner plus de "performance" à court terme . D'autre part, il est à forte probabilité que si les conditions soient appropriées, ce type de protocoles pourrait contribuer à congestion effondrement .
Ce petit article est vieux, mais il est toujours assez vrai quand il s'agit de jeux. Il explique les deux protocoles et les ravages que ces personnes ont essayé de développer un jeu Internet multijoueur. "X-aile vs latte à attacher"
Leçons apprises (Internet suce)
Il y a une mise en garde à cela, je courais / développe un jeu multijoueur et j'ai utilisé les deux. UDP était beaucoup mieux pour mon application, mais beaucoup de gens ne pouvaient pas jouer avec UDP. Routeurs et tels bloqués les connexions. J'ai donc changé vers le TCP "fiable". Eh bien ... fiable? Je ne le pense pas. Vous envoyez un paquet, aucune erreur, vous enverrez une autre et il se bloque (exception) au milieu du paquet. Maintenant quels paquets l'ont fait? Donc, vous finissez par écrire un protocole fiable sur TCP, pour simuler UDP - mais établir en permanence une nouvelle connexion lorsqu'elle se bloque. Prendre à peu près inefficace.
udp + stop and attendre arw = bon
Protocole de fenêtre coulissante UDP + Mieux = mieux
protocole de fenêtre coulissante TCP + avec reconnexion? = Bulkware sans valeur. (IMHO)
L'autre effet secondaire est des applications multi-threadées. TCP fonctionne bien pour un type de chambre de discussion, car chaque chambre peut être propre. Une chambre peut contenir 60-100 personnes et elle fonctionne bien, car le fil de la pièce contient les prises pour chaque participant.
UDP d'autre part est mieux servi (imo) par un fil, mais lorsque vous obtenez le paquet, vous devez l'analyser pour déterminer qui it est venu (via INFO envoyé ou à distance), puis transmettez ces données à le fil de la salle de discussion de manière threadsafe.
En réalité, vous devez faire la même chose avec TCP, mais uniquement sur Connect.
dernier point. N'oubliez pas que TCP n'arrivra que par erreur et tuera la connexion à tout moment, mais vous pouvez vous reconnecter environ 5 secondes et envoyer les mêmes informations. La chose la plus bizzare que j'ai jamais travaillé avec.
Pouvez-vous élaborer à l'exception qui a été lancée lorsque vous avez utilisé TCP? Je voudrais absolument blâmer votre code et non le calque TCP pour cela, car il semble un peu ridicule. Merci d'avoir souligné le protocole de la fenêtre coulissante, je n'avais pas entendu parler de cela et c'est un algorithme intéressant.
Nous sommes passés de fiables à une "League of Legends" il y a environ un an à cause de plusieurs avantages qui se sont avérés comme étant vrais:
1) Les anciennes informations deviennent sans importance. Si j'envoie un paquet de santé et que cela n'arrive pas ... Je ne veux pas avoir à attendre que le même paquet de santé soit renvoyé lorsque je sache que c'est changé.
2) L'ordre n'est parfois pas nécessaire. Si j'envoie des messages différents à différents systèmes, il peut ne pas être nécessaire d'obtenir ces messages dans l'ordre. Je ne force pas le client à attendre des messages en ordre.
3) Non fiable ne pas être sauvegardé avec des messages ... c'est-à-dire attendre des accusé de réception, ce qui signifie que vous pouvez résoudre des pics de perte beaucoup plus rapidement.
4) Vous pouvez contrôler la réexécution quand nécessairement plus efficacement. Comme le remballage de quelque chose qui n'a pas envoyé à un autre paquet. (TCP est debout, mais vous pouvez le faire plus efficacement avec la connaissance de la façon dont votre programme fonctionne.)
5) Contrôle du message de message tel que lancer des messages moins pertinents lorsque le réseau pointe soudainement. Le système de réseau peut choisir de ne pas renvoyer des messages moins pertinents lorsque vous avez une pointe de perte. Avec TCP, vous auriez toujours une file d'attente de messages qui tentent de renvoyer, ce qui peut être une priorité inférieure.
6) Paquet d'en-tête plus petit ... N'ayez pas vraiment besoin de dire grand chose à ce sujet.