N'acceptez pas simplement une réponse "oui ou non parce que je l'ai dit", car vous vous exposez peut-être à devoir vous attaquer à un tas de problèmes avec UDP auxquels vous n'avez pas à faire face.
Aucune des autres réponses ici n'indique le moyen évident de le prouver.
Prenons quelques faits simples
- Un en-tête IP comporte 20 octets, quel que soit le protocole utilisé.
- Les en-têtes UDP sont 4 octets
- Les en-têtes TCP ont 20 octets.
Ainsi, chaque fois que vous envoyez un message d'un octet sur la ligne, vous avez effectivement envoyé 25 ou 41 octets, en fonction du protocole, en supposant qu'un en-tête IP est également nécessaire.
sources:
Mon conseil
Prenez votre situation où vous avez besoin d’une interaction client-serveur, estimez le nombre de clients, puis faites le calcul en fonction des données que vous envoyez réellement entre les 2.
Un exemple
Disons que j'envoie 10 messages de 1 octet par mise à jour dans mon jeu et que je mets à jour environ 60 ips; je dois donc envoyer 60 * 10 = 600 octets par seconde de données de message réelles + les en-têtes correspondants.
Maintenant, en fonction du jeu, je peux envoyer tout cela en un seul message, de sorte que la surcharge de la couche TCP ne représente que 40 octets (soit un coût sur UDP de 20 octets par seconde). Ne pas avoir cette surcharge représente un coût potentiel de 600 octets ( parce que je pourrais avoir à renvoyer le flux de messages entier).
S'il est toutefois extrêmement important que chaque message soit envoyé seul au moment où il est prêt à être envoyé, j'ai 600 messages (également 600 octets) + 40 * 600 = 24k de temps système TCP ou ~ 14k de temps système UDP par seconde + 600 octets de données de message.
Encore une fois, nous posons les questions suivantes: quelle importance ont ces messages, quelle est leur fréquence et peuvent-ils être regroupés d’une manière ou d’une autre afin de réduire les frais généraux?
Ceci est basé sur une série de messages mono-octet. En général, vous feriez quelque chose de très différent, mais vous ne sauriez pas si les données brutes envoyées sont difficiles à prouver si le protocole TCP convient mieux à votre situation que le protocole UDP.
Alors, ça va marcher?
Eh bien, si vous avez un fps typique et que la position est importante (pour éviter les tricheries ou des décisions incorrectes), vous devez savoir que votre flux réseau est réalisable, mais 32 joueurs envoient chacun en continu plus de 24k octets de message (donc 768 Ko / s + messages) ... il s’agit d’une ligne à large bande de 10 Mo / s, réservée aux en-têtes individuels, qui consiste à envoyer au moins un message par image de chaque client à tous les autres clients via un serveur.
De toute évidence, vous n'allez pas coder votre serveur et votre client pour qu'ils fonctionnent de cette manière et la taille des messages risque d'être beaucoup plus grande et probablement moins fréquente qu'un octet par image dans la plupart des situations, il est donc difficile de dire sans voir le monde réel. "Ce sont les données que je dois envoyer" exemple.
Mon cas
Dans mon cas, je me suis dit que les frais généraux étaient raisonnables, mais que cela dépend de la manière dont je construis mes flux de messages afin d'éviter des frais généraux énormes par rapport à certains modèles.
Le protocole TCP fonctionne bien et je dispose d’un serveur MMO évolutif et d’une infrastructure client, mais je n’ai pas besoin de diffuser beaucoup de données en continu ni de petits paquets car je peux traiter mes appels en lots.
pour les autres: TCP ne fera tout simplement pas l'affaire, et ils peuvent uniquement utiliser UDP, mais doivent accepter le fait que cela ne leur donnera aucune garantie quant à ce qu'ils obtiennent (garantie de commande / arrivée).
Autres considérations
De nombreux moteurs de jeu mal codés gèrent tout ce qui est sur le thread principal du cpu, de sorte que le cpu ne dispose souvent que de très peu de temps pour gérer le code réseau, une implémentation décente du serveur et du client serait entièrement asynchrone et éventuellement tirer des messages par lots.
Il existe de bonnes bibliothèques de réseautage, mais comme on peut le voir ici, beaucoup semblent être d’avis que UDP est "tout simplement meilleur", il faut bien prendre en compte vos propres besoins en premier et ce n’est peut-être pas le cas, et trouver une bibliothèque qui ne fonctionne pas En tenant compte de ce que vous faites, vous risquez de créer une configuration TCP mal codée par rapport à la variante UDP de la même bibliothèque (je dis simplement que j’ai vu cela et que les tests de charge l’ont prouvé).
Construisez d'abord une base technique des données que vous voulez envoyer et testez-la, puis faites le calcul pour la faire évoluer. Dans le cas le plus défavorable, testez-la en la déployant sur un cloud et demandez à 50 ordinateurs d'exécuter un client de test pour voir s'il peut gérer. votre limite de 32 joueurs par match (ou quelle que soit votre limite).