Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Le réseau dans les jeux vidéo : UDP vs TCP
Bonjour,
Vous vous lancez dans un jeu vidéo et vous voulez lui donner des fonctionnalités multijoueurs. Il est évident d'arriver à la question du protocole. Faut-il choisir TCP ou UDP. Dans cet article, Glenn*Fiedler apporte une réponse.
La rubrique 2D/3D/Jeux souhaite remercier Bousk pour son travail de traduction de l'article.
Bonne lecture.
Retrouvez les autres articles de cette série.
Article intéressant à lire.
Je regrette juste qu'il n'y ai pas des chiffres comparatifs entre TCP et UDP.
Je n'ai que survolé rapidement l'article, mais ce problème se pose-t-il quand TCP et UDP partagent un nœud goulot d'étranglement ? Et ces pertes de paquets surviennent lors de la synchronisation des fenêtres ? Cela n'arrive pas si fréquemment que cela (?)
Donc qu'on soit en TCP/UDP ou en UDP seulement, dès qu'on congestionne le réseau, on a forcément des pertes de paquets.
Je ne vois pas non plus en quoi mélanger TCP et UDP serait complexe.
Au final, pourquoi faire du TCP/UDP serait si problématique ?
L'idée de réinventer TCP par dessus UDP mais en mieux ne me parait pas vraiment génial.
Les FPS sont un cas particuliers, mais je serais plutôt du genre à conseiller de commencer avec du TCP et de faire ce qu'on a à faire.
Je pense que ce sera beaucoup plus facile pour développer, tester en local et moins enquiquinant. Ce que je veux dire, c'est qu'au début d'un projet, il y a des choses plus intéressantes et plus utiles que de se battre à réinventer des roues en UDP. D'autant plus si, au final, on garde le projet pour soi en local.
C'est comme les personnes qui veulent absolument faire 50 threads avant la première ligne de code pour leur jeu car ce sera "plus performant". Sans parler de tous les problèmes causés (deadlock, débogage, …), ce n'est pas de cette manière qu'on procède :
- écriture avec un seul thread ;
- mesures ;
- optimisation sur un seul threads aux endroits critiques (on peut avoir des facteurs impressionnant) ;
- mesures pour voir si on gagne ou non ;
- si et seulement si cela ne suffit pas, on passe à plusieurs threads ;
- et on mesure encore pour voir si on gagne réellement.
Pour l'UDP et le TCP, cela revient au même. Soyons pragmatique, commençons simple et ne modifions que si on en a réellement besoin. Avoir un jeu qui marche en local en TCP me semble plus important que d'avoir des flux UDP avec checksum, numérotation, acquittement, timeout, renvoie du message si pas d'acquittement reçu, qui aura probablement quelques bugs.
Pour tout ce qui est connexion, achat dans une boutique, confirmation de décisions importantes, on peut utiliser un flux TCP/SSL. Si cela perturbe le flux UDP, ce n'est pas bien grave car on est pas vraiment dans des phases de jeux à ces moment là.
Après, il faut bien évidement avoir une découpe cohérente, et ne pas mélanger UDP, TCP et TCP/SSL n'importe comment. On ne va pas utiliser du TCP pour les boules de feu et de l'UDP pour les boules de glaces par exemple.
Par contre, rien n'empêche d'avoir un chat en TCP, la carte, déplacements et attaques en UDP et des "événements" en TCP.
J'aurais plutôt tendance à privilégier l'UDP pour tous les messages qui seront "périmés"/"à jetter" au bout d'un certain temps si on a pas réussi à les transmettre et le TCP sinon.
Il n'y a pas que la nature des données à prendre en compte pour le choix du protocole, mais aussi et surtout la stratégie utilisée pour synchroniser le serveur et le client pour les garder dans un état cohérent.
Sinon article très intéressant. Je ne savais pas que les flux TCP pouvaient poser problèmes aux flux UDP.
Je savais que les flux UDP peuvent perturber les flux TCP (en cas de congestion du réseau) mais pas l'inverse.
Je regrette juste qu'il n'y ai pas de chiffres/schémas/tableaux et que le discours ne soit pas un peu plus nuancé.
Merci au traducteur de nous faire découvrir cet article
Salut,
tu pars dans tous les sens
Les 2 sont des surcouches d'IP, donc les 2 sont finalement liés.Je ne savais pas que les flux TCP pouvaient poser problèmes aux flux UDP.
Je savais que les flux UDP peuvent perturber les flux TCP (en cas de congestion du réseau) mais pas l'inverse.
UDP pourra "plus facilement" congestionner ton réseau parce qu'on fait plus facilement n'importe quoi en UDP : spam de send sans réfléchir, là où TCP gèrera en interne la congestion, mais silencieusement.
Mais puisque la congestion se situe sur IP..
Quels chiffres voudrais-tu ?Je regrette juste qu'il n'y ai pas des chiffres comparatifs entre TCP et UDP.
Chiffrer UDP est à la limite faisable, mais TCP est une jolie boîte noire.
Les chiffres importants sont que
- le header TCP fait 20 octets ( + jusque 40 octets d'options)
- le header UDP fait 8 octets
à partir de là, tu peux déjà calculer le gain en bande-passante de l'un par rapport à l'autre.
Ensuite une autre chose très importante c'est que TCP est fiable, et la façon dont ils implémentent cette fiabilité le ralentit.
Sachant que chaque attente du ack est une attente justement.
- envoi des data
- attente ack
-> si ack pas reçu à temps (disons 2RTT), renvoi des data
- réception ack
-> ok c'est envoyé !
De plus, TCP étnat une boîte noire, il se charge lui-même de découper ton buffer pour l'envoyer - pratique-, mais il peut aussi décider que ton buffer ne mérite pas un envoi! Et il attendra que le buffer soit plus grand pour l'envoyer.
L'attente est déjà performance-killer dans un programme tps-réel, mais alors là
Il estime la perte de paquet à 5%, ça me parait pas déconnant sur une connexion "normale". Pour l'anecdote, on a eu un bug en début d'année qui n'était reproductible que parfois sur une certaine machine : perte de paquet. En lan ça a pas été coton de l'identifier, un problème de fiabilité dans notre UDP justement. Tout ça pour dire que la perte est très (totalement?) aléatoire, et rare. Elle peut venir de la ligne, de la connexion, ou du matériel (le pc en question n'était pas une bête de course).
La congestion est bien plus grave, on parle plus de perte à ce niveau. ^^
Il ne dit pas que c'est complexe, mais que c'est une fausse bonne idée. Déjà parce que de toutes façons, derrière il n'y a que IP. Puis parce qu'on a vite fait de tomber dans l'excès - comme il le décrit dans l'article : 1 socket TCP pour la position, c'est important la position, 1 UDP pour le chat, 1 TCP pour le cast, .... chacun son socket pour pas interférer avec les autres et ça devient n'importe quoi.Je ne vois pas non plus en quoi mélanger TCP et UDP serait complexe
C'est pourtant ce que l'on fait dans tous les studios qui proposent du multijoueur un tantinet "tps-réel".L'idée de réinventer TCP par dessus UDP mais en mieux ne me parait pas vraiment génial.
Ca se fait très bien, ça marche très bien, et ça permet des choses impossibles autrement : broadcast, P2P, Nat-traversal et surement d'autres..
Ui m'enfin, t'as juste pas compris l'intérêt de l'article excuse-moi.Ce que je veux dire, c'est qu'au début d'un projet, il y a des choses plus intéressantes et plus utiles que de se battre à réinventer des roues en UDP. D'autant plus si, au final, on garde le projet pour soi en local.
Où on parle de Bob qui fait un jeu tout seul dans sa chambre pour lui ?
Ce que Glenn présente, c'est une technique que l'on utilise dans le milieu, en tant que professionel. Après si tu veux ne pas y croire, je peux rien pour toi...
Parce qu'il faudrait pas oublier que "faire un jeu", c'est marrant, y'a plein de personnes qui s'y essayent (y'a qu'à voir le forum projet), mais y'a une vraie industrie qui existe.
Donc
non, avoir un jeu en local, si tu fais un jeu multijoueurs en ligne, c'est inutile.Avoir un jeu qui marche en local en TCP me semble plus important que d'avoir des flux UDP avec checksum, numérotation, acquittement, timeout, renvoie du message si pas d'acquittement reçu, qui aura probablement quelques bugs.
C'est un tout autre sujet, très intéressant mais bien plus complexe.Il n'y a pas que la nature des données à prendre en compte pour le choix du protocole, mais aussi et surtout la stratégie utilisée pour synchroniser le serveur et le client pour les garder dans un état cohérent.
Si ça t'intéresse, il en a parlé à la GDC http://gdcvault.com/play/1022195/Phy...ers-Networking
Cette série d'article ne traite que l'envoi des données.
Parce que la boite noire de TCP ne permet aucun controle.Au final, pourquoi faire du TCP/UDP serait si problématique ?
Tu ne sais pas si tu t'approches de la congestion ou non. Donc tu ne sais pas ce que tu peux faire avec ton socket UDP l'esprit tranquille, ou si ta prochaine utilisation de TCP ne va pas entraîner une congestion - et donc un lag - de plusieurs centaines de ms.
Ce que je veux dire, c'est que si on a congestion, on a congestion et des pertes de paquets, qu'on fasse du TCP/UDP ou de l'UDP uniquement.Envoyé par Bousk
Je connais assez bien TCP et UDP, par contre, aujourd'hui, avec nos connexions qui ont des temps de latence très faible, des débits à plusieurs Mo/sec, peu de pertes de paquets, est-ce que la différence de vitesse entre TCP et UDP est si significative ?Quels chiffres voudrais-tu ?
Si c'est pour gagner 1ms en moyenne, je ne vois pas l'intérêt. Ce que je veux dire, c'est qu'ici, on ne fait pas des jeux AAA, si ça "marche" en TCP, c'est déjà bien. Même si l'UDP serait plus approprié.
C'est bon à savoir, mais avec nos connexions, je pense que la différence est peu significative.- le header TCP fait entre 20 et 60 octets + jusque 40 octets d'options
- le header UDP fait 8 octets
à partir de là, tu peux déjà calculer le gain en bande-passante de l'un par rapport à l'autre.
Ce que je veux dire, c'est qu'ici, on ne gère pas des milliers de clients simultanément.
Il y a une option pour envoyer sans attendre.De plus, TCP étnat une boîte noire, il se charge lui-même de découper ton buffer pour l'envoyer - pratique
C'est à nuancer.L'attente est déjà performance-killer dans un programme tps-réel, mais alors là
Si la granularité est de 1s que ce soit TCP ou UDP, on s'en moque complètement.
Si on a une granularité de temps très fine, en effet, il faut se poser des questions.
Ensuite, pour tester en local ou avec peu de client, je pense que du TCP peut suffire.
Je ne pense pas qu'on ai un public qui vienne nous insulter car ils ont 59 FPS au lieu de 60FPS.
Ce que je veux dire, c'est qu'on a ici des jeux amateurs, si on a une version qui marche avec TCP, c'est déjà très bien et très encourageant. Après, si on veut distribuer le jeu à plus large échelle, on pourra toujours passer à l'UDP.
Si la perte de paquet est très rare, le coût supplémentaire dû à TCP doit être minimum non ?Tout ça pour dire que la perte est très (totalement?) aléatoire, et rare.
On peut se limiter à un socket par "type" : TCP, UDP, TCP/SSL.Puis parce qu'on a vite fait de tomber dans l'excès
Cela me semble mieux, plus simple et plus rapide que de recoder, directement, un TCP bogué.
Oui, mais nous, nous ne sommes pas des studios.C'est pourtant ce que l'on fait dans tous les studios qui proposent du multijoueur un tantinet "tps-réel".
De plus, ils ne réinventent rien car ils ont leur propres bibliothèques propriétaires depuis quelques années, qu'ils ont testé, retesté et éprouvé.
Le P2P en TCP est possible (hole punching).ça permet des choses impossibles autrement : broadcast, P2P, Nat-traversal et surement d'autres..
Après, est-ce qu'on a besoin de tout cela tout de suite ?
Un professionel n'ira pas voir des articles pour savoir s'il doit utiliser du TCP ou de l'UDP, à son niveau je pense qu'il est censé savoir lequel il doit utiliser.Où on parle de Bob qui fait un jeu tout seul dans sa chambre pour lui ?
Ce que Glenn présente, c'est une technique que l'on utilise dans le milieu, en tant que professionel.
Je pense qu'on s'addresse ici à des amateurs pas à des studios AAA.Vous vous lancez dans un jeu vidéo
Ce que je veux dire, c'est qu'en amateur, se précipiter sur de l'UDP et recoder TCP sans bien forcément maîtriser le sujet, ce n'est peut-être pas le plus important. Que si on a un choix à faire, d'abord faire simple. Si on s'apperçoit que TCP ne va pas, passer à l'UDP, mais c'est aussi comme cela que l'on apprend.
N'ayant pas de don d'ubiguïté, c'est plus simple pour moi de tester sur un réseau localnon, avoir un jeu en local, si tu fais un jeu multijoueurs en ligne, c'est inutile.
J'essayerais de le lire un jourC'est un tout autre sujet, très intéressant mais bien plus complexe.
Si ça t'intéresse, il en a parlé à la GDC http://gdcvault.com/play/1022195/Phy...ers-Networking
Cette série d'article ne traite que l'envoi des données.
Mais est-ce qu'à notre niveau, on a besoin de ce contrôle dès le début du projet ?Parce que la boite noire de TCP ne permet aucun controle.
Cela me fait penser aux personnes qui se prennent des crises cardiaques dès que deux lignes de codes ne sont pas optimales.
Si tu as un bug, il sera dû à quoi ?
- perte de paquet UDP ?
- paquets UDP arrivés dans le mauvais ordre ?
- bug dans notre surcouche UDP ?
- problème sur le bout de code qu'on vient d'écrire ?
Autant commencer en TCP ainsi, on a plus ces questions à se poser.
Dès qu'on touche et qu'on observe les limites de TCP, on passe à l'UDP. Mais on aura acquéri une expérience concrète et on aura mieux compris TCP. La prochaine fois, on commencera peut-être directement en UDP.
Je ne nie pas que l'UDP est plus appropriée, mais à un niveau amateur, je ne peux que conseiller de commencer simplement. C'est comme si tu disais "pour un jeu, un faut absolument avoir deux threads, un pour l'affichage et un pour les calculs". Non, on commence déjà avec un thread et on voit ce que cela donne.
Je ne dis pas qu'il a tord et que j'en sais plus que lui, juste que les personnes qui se posent la question TCP vs UDP sont généralement des débutants et qu'un débutant devrait mieux commencer par TCP. Quand on apprend à faire du vélo, on commence avec les petites roue et ce n'est qu'ensuite qu'on les enlèves.
Bien entendu. Sauf que comme il est dit dans l'article :
- TCP va renvoyer le paquet dès qu'il se rendra compte du timeout (soit ping * 2, soit, on va dire 50 ms * 2)
- UDP, on abandonne le paquet et le jeu enverra un autre paquet avec une description du jeu plus à jour (position plus à jour ...)
Je tiens aussi à vous montrer l'article sur le réseau de Quake 3. -> http://trac.bookofhook.com/bookofhoo...ake3Networking
Cela vous montrera mieux quels types de données ont échangent vraiment dans un jeu vidéo.
Je suis heureux que vous ayez la fibre, félicitations
J'ai encore un PC (en France !) avec du 28 k, encore actif aujourd'hui. J'ai joué à Starcraft dessus ! J'imagine que sur une connexion 28 k, chaque petit bit compte.
Après, c'est comme dire : oh, maintenant tous le monde a un i7 et 16 Go de RAM et la dernière NVIDIA, donc n'optimisons pas le jeu. C'est un principe vraiment débile ([troll] bon, comme dirait une connaissance, avec tout le monde acceptant des trucs comme JavaScript ... [/troll] ). Il faut se rappeler qu'un jeu peut être vendu en Afrique, en Asie, jouer dans des Cybercafé et ainsi de suite. Les machines et les configurations sont loins d'être les mêmes pour tous et les capacités du réseau aussi.
TCP, pour se rendre compte qu'un paquet est perdu, c'est ping * 2 (soit, 50ms * 2), soit 5 images (6 pour être précis), soit, toutes les données que j'en envoyé à ce moment là sont obsolètes. Ok, mais ce crétin de TCP est entrain de les renvoyer (wooooooooooooooooooo). Donc, on a perdu 6 images, mais en plus on s'embourbe avec des paquets obsolètes (qui vont devoir arriver et que je vais devoir attendre, notamment car TCP découpe mon buffer et va attendre l'ordre des paquets).
Ah oui, et si vous pensez que 50 (100 ms) c'est rien. Il y a des articles (Google Scholar) sur l'impact de la latence réseau sur les résultats des joueurs. Notamment il est dit qu'au dessus de 200 ms de lag, c'est désagréable pour un joueur. Je crois aussi que 50 ms, c'est ce qu'il faut pour pouvoir bien profiter d'un FPS/jeu de cours.
Elle est mentionnée dans l'article, mais il reste les soucis de ce que j'ai dit au dessus.
En effet, un amateur comme moi (qui ai déjà fait de la programmation réseau à l'université, avec pour objectif un jeu multijoueur (oui c'est le but du TP)), je vais utiliser Unity ou Unreal Engine, ou Raknet ou .... Mais tout de même, pourquoi je lis des articles quotidiennement : pour ma culture générale ou encore, pour aller en entretien et ne pas me rétammé, ou encore si un jour, je suis dans une petite boite et que personne n'a d'idée (ou de temps) sur le réseau, autant que je sache et que j'ai un point de vue hétéroclyte.Ce que je veux dire, c'est qu'on a ici des jeux amateurs, si on a une version qui marche avec TCP, c'est déjà très bien et très encourageant. Après, si on veut distribuer le jeu à plus large échelle, on pourra toujours passer à l'UDP.
C'est comme dire : oh, je fais un pong, donc faisons le avec le pire langage et en codant trop trop mal. Ça sera dommage de montrer le code source à Ubisoft et qu'ils vous disent : ouep, mais votre code ne prend aucunement en compte les vrais problèmes d'un JV et donc on vous embauche pas vous avez aucune connaissance dessus.
Il faut transmettre le savoir et pas se contenter de croire que toute la machine est une boite noire et que les pointeurs sont magiques et ainsi de suite.
C'est plutôt l'inverse. Pourquoi un tel gros surcout du TCP, alors que la perte est max 5%. Les 95 autre % sont du gachis, non ?Si la perte de paquet est très rare, le coût supplémentaire dû à TCP doit être minimum non ?
Oui mais peut être que nous voulons être engagé chez les grandsOui, mais nous, nous ne sommes pas des studios.
Avec l'émergence des studios indépendant ...Un professionel n'ira pas voir des articles pour savoir s'il doit utiliser du TCP ou de l'UDP, à son niveau je pense qu'il est censé savoir lequel il doit utiliser.
Sur I0, le ping est de 0,05ms, sur un réseau local Ethernet entre 4-10ms. Donc pour débuter et tester, c'est déjà pas mal.
Après oui, en UDP, on peut envoyer 3/4 fois le même paquet en même temps pour réduire le risque de perte, je n'y pensais plus.
J'aimerais bien, je n'ai "que" l'ADSL à plusieurs Mo/s.Je suis heureux que vous ayez la fibre, félicitations
Pour un jeu amateur, je pense qu'on se moque un peu de ces problématiques dans un premier temps.J'ai encore un PC (en France !) avec du 28 k, encore actif aujourd'hui. J'ai joué à Starcraft dessus ! J'imagine que sur une connexion 28 k, chaque petit bit compte.
Après, c'est comme dire : oh, maintenant tous le monde a un i7 et 16 Go de RAM et la dernière NVIDIA, donc n'optimisons pas le jeu. C'est un principe vraiment débile ([troll] bon, comme dirait une connaissance, avec tout le monde acceptant des trucs comme JavaScript ... [/troll] ). Il faut se rappeler qu'un jeu peut être vendu en Afrique, en Asie, jouer dans des Cybercafé et ainsi de suite. Les machines et les configurations sont loins d'être les mêmes pour tous et les capacités du réseau aussi.
Combien de projets ici sont compatibles Linux ?
Alors certes, c'est bien d'optimiser le jeu, mais l'optimisation prématurée, c'pas bien.
Ayons déjà un prototype, une démo fonctionnel, c'est le plus important.
Et ceci se produit à quelle fréquence ?Notamment il est dit qu'au dessus de 200 ms de lag, c'est désagréable pour un joueur. Je crois aussi que 50 ms, c'est ce qu'il faut pour pouvoir bien profiter d'un FPS/jeu de cours.
Si c'est une fois par heure, c'est déjà suffisant pour tester et montrer des démos.
Je ne dis pas que 100 ms c'est rien, mais qu'il faut être pragmatique. On peut passer des mois à gagner 10ms, mais on ne le fait pas au début du projet avant même d'avoir réussi à afficher une fenêtre.
Cela dépend aussi de ce que l'on veut faire.C'est comme dire : oh, je fais un pong, donc faisons le avec le pire langage et en codant trop trop mal. Ça sera dommage de montrer le code source à Ubisoft et qu'ils vous disent : ouep, mais votre code ne prend aucunement en compte les vrais problèmes d'un JV et donc on vous embauche pas vous avez aucune connaissance dessus.
Combien de personnes ici codent pour elles-même, pour s'amuser et combien le font pour être recrutée par Ubisoft ?
Bien sûr, je ne dis absolument pas le contraire.Il faut transmettre le savoir et pas se contenter de croire que toute la machine est une boite noire et que les pointeurs sont magiques et ainsi de suite.
Mais quand on va conseiller un débutant, on ne va pas lui dire de faire son jeu en assembleur.
On lui conseille même parfois d'utiliser RPG Maker.
Pourquoi prendre de l'UDP si du TCP suffit ?C'est plutôt l'inverse. Pourquoi un tel gros surcout du TCP, alors que la perte est max 5%. Les 95 autre % sont du gachis, non ?
On est pas dans du code embarqué critique où chaque cycle compte.
L'optimisation prématurée, c'est pas bien. Déjà commencer en TCP permet de se confronter aux problématiques propres au jeu sans se soucier, dans un premier temps, des problématiques réseaux.
Mais je n'ai jamais dit qu'il faut sortir une release en TCP et ne jamais utiliser d'UDP, au contraire.
Je dis juste de commencer en TCP puis de finir en UDP si nécessaire. Et je pense que c'est un gain de temps non-négligeable dans le développement et surtout le débogue.
Quand on veut devenir champion en cyclisme, on ne commence pas à faire 100km en vélo par jours.Oui mais peut être que nous voulons être engagé chez les grands
On commence par apprendre à faire du vélo, puis on commence par 10km, 20 km, 50km, etc.
Tu ne vas pas dire à un débutant qui sait à peine programmer :
"Oui c'est bien, mais ce bout de code, tu devrais l'écrire en assembleur pour l'optimiser un max".
"Utilise TBB pour ta gestion de machins…".
Quand on commence à faire des jeux, on commence par un Hello World, pas par un WOW mais en mieux.
Si c'est un professionnel débutant, je lui conseille déjà de commencer petit avant de commencer à recréer un WOW ^^.Avec l'émergence des studios indépendant ...
Oui, cet article est très intéressant, mais j'ai peur que des lecteurs débutants se disent "Le TCP, faut surtout pas l'utiliser, il faut tout faire en UDP et réinventer notre propre surcouche".
C'est pour cela que je dis qu'il faut d'abord commencer en TCP (et en local). Après, une fois que l'on a fait cela, rien n'empêche de faire des jeux en UDP sans passer par du TCP.
Quand je commence et j'apprend à afficher des choses sur une fenêtre, je le fais d'abord en SFML. Je ne commence pas tout de suite à le faire en OpenGL pour des raisons de performances.
Ce que je veux dire, c'est qu'on ne court pas un marathon avant d'avoir appris à marcher.
Justement, en UDP ça peut être géré, voire anticiper. Avec TCP, tu te la colles derrières l'oreille et tu attends qu'il s'en sorte.
Hier c'était utile parce que les connexions étaient lentes. Demain ça sera utile parce qu'on souhaite envoyer de plus en plus de données.
La latence très faible, les débits à plusieurs Mo/s etc ne sont que théoriques, et tu serais surpris de voir que c'est pas la norme encore.
Dans 95% des cas tu vas déjà gagner au moins ton ping, voire ton ping*2, dans les 5% restants (perte) le gain est encore plus énorme.
Tu n'as jamais pensé à mettre un sleep(250) dans ta boucle de rendu n'est-ce pas ? Alors pourquoi accepter que ta couche réseau le fasse pour toi ?
Ici ? Ou juste toi ?
Relis donc le header du forum : "Developpez.com, développeurs [..] pro"
Sinon autant renommer ça en Developpez.edu hein
La différence est non négligeable quand tout va bien, elle est énorme quand des problèmes commencent à survenir.
Si les problèmes deviennent bien trop grave => connection dead. Là où TCP te fera un joli freeze pendant qu'il doit réessayer.
Option traitée dans l'article : TCP se réserve le droit en interne de la prendre en compte ou non, on n'en sait rien.
Je vais pas t'apprendre que rien n'est jamais tout blanc ou tout noir...
Si tu as un jeu en tour/tour, TCP fera l'affaire. Dès que tu as un minimum d'action ou de tps-réel, oublie.
En local ui, mais je pense pas que ton but soit de faire du multi-instance sur ton pc local..
Quand au public.. peut-être pas toi, mais d'autres possiblement oui.
L'article te dit justement que c'est pas une bonne chose..
Encore ce fameux nous..
TCP over UDP est éprouvé oui, puisque nous avons ce code qui n'évolue plus depuis un moment. Sauf quand il sort une nouvelle plateforme (console), sauf quand un bug ultra-rare réapparait subitement, sauf quand on veut aussi l'améliorer (mise en place de delta-paquets), ...
Oui le code réseau est souvent l'un des plus testés, puisqu'il l'est en continu, mais s'agissant d'un code critique, il n'est pas partagé. Chacun garde son steack.
Et moi je propose ici une traduction d'un article que j'aurais aimé avoir il y a quelques années, ça m'aurait certainement simplifié mes débuts dans le milieu.
Sauf que tu fais des tests qui sont loins des conditions réelles et donc tu passeras au travers de problèmes non décelables.N'ayant pas de don d'ubiguïté, c'est plus simple pour moi de tester sur un réseau local
Edit: oh et puis zut, t'es indécrottable, tu n'en démords pas, libre à toi de penser ce que tu veux, je ne répondrai plus à tant d'énormités que je trouve totalement hors sujet. Voir le monde à travers le nombril des débutants c'est mignon, mais y'a un mode en dehors qu'il ne faudrait pas occulter parce que "j'en fais pas partie (encore?)".
J'ai la vsync, ça compte ?
Il y a une différence entre saboter son code et choisir une solution moins optimale mais plus simple.
Quelle est la proportion d'amateurs, de débutant et d'étudiants ici ?
De plus, rien n'empêche un professionnel d'un domaine être débutant dans un autre.
D'accord, je ne le savais pas.Option traitée dans l'article : TCP se réserve le droit en interne de la prendre en compte ou non, on n'en sait rien.
Bon déjà, rien que d'avoir cela, c'est pas si mal. Après changer pour UDP n'est pas si coûteux si l'architecture a bien été pensée.En local ui, mais je pense pas que ton but soit de faire du multi-instance sur ton pc local.
Avoir tout en local (pas nécessairement sur le même ordinateur) permet aussi de tester sans avoir de problèmes réseau, cela peut donc faciliter le débogue de certaines fonctionnalités.
Pour des jeux amateurs comme on peut en trouver ici ?Quand au public.. peut-être pas toi, mais d'autres possiblement oui.
Ensuite, avoir une démo à 40 FPS n'empêche pas de retravailler dessus pour atteindre les 120 FPS pour une version finale.
L'article dit aussi :L'article te dit justement que c'est pas une bonne chose..
Une paire de connexions TCP en parallèle de votre jeu ne va pas tout faire s'effondrer.Combien de studio professionnel et sérieux sont ici ?Encore ce fameux nous..
Oui, je ne dis pas le contraire.Et moi je propose ici une traduction d'un article que j'aurais aimé avoir il y a quelques années, ça m'aurait certainement simplifié mes débuts dans le milieu.
Je n'ai pas dit que c'est les seuls tests à faire, il y a plusieurs types de tests : tests unitaires, …Sauf que tu fais des tests qui sont loins des conditions réelles et donc tu passeras au travers de problèmes non décelables.
On ne teste jamais directement en prod
C'est quoi ton problème ?Edit: oh et puis zut, t'es indécrottable, tu n'en démords pas, libre à toi de penser ce que tu veux, je ne répondrai plus à tant d'énormités que je trouve totalement hors sujet. Voir le monde à travers le nombril des débutants c'est mignon, mais y'a un mode en dehors qu'il ne faudrait pas occulter parce que "j'en fais pas partie (encore?)".
Je n'ai pas dit qu'il a tord, je n'ai pas dit que cet article est inintéressant, je n'ai pas prétendu donner des conseils à des professionnels, juste que pour des débutants, commencer par du TCP me semble plus approprié.
Je vais répondre, certes hors sujet par rapport à l'article, mais c'est, disons, pour la communauté.
Oui, et comme vous l'aviez vu, on a tout de même de plus en plus de gens professionnels qui passent. Notamment, dans les présentations des jeux vidéo, Planet Centauri et bien d'autres qui ont une qualité de plus en plus pro. Ça, je ne crois pas que l'on voyait ce genre de projets sur Developpez.com il y a quelques années.Pour des jeux amateurs comme on peut en trouver ici ?
Certes, on a beaucoup de débutants, mais je préfère un débutant qui sache réfléchir et juger des choses que le gars qu'on lui dit juste : fait ça ou ça. Là, il a une porte, pour voir. S'il veut apprendre plus le réseau, s'entrainer ou autre, bah suivre l'article sera un bon moyen de gagner mass XP. S'il veut faire son jeu, bah il utilisera Unity, Raknet, ou TCP. Il est pas aussi naif. On propose des ressources, autant que possibles, des ressources hétéroclytes pour apprendre et réfléchir.
De plus en plus, du moins je l'espère. Bousk fait parti de ces gens, mais aussi plusieurs autres membres qui passent régulièrement dans ces forums et je les en remercie.Combien de studio professionnel et sérieux sont ici ?
Oui, la rubrique 2D/3D/Jeux pouvait rester une rubrique totalement pour débutante. C'est vrai. On aurait pu avoir mille tutoriels (un par langage) sur comment faire Pong et voilà. Mais j'ai (en tant que responsable de la rubrique) souhaité aller plus loin, souhaité (même si tout le monde lit les ressources en anglais) proposé un vrai espace pour les développeurs de jeux francophone et un vrai espace où l'on trouve des ressources utiles. Cela prends du temps à mettre en place, mais j'ai envie de dire, pourquoi pas.
On accueille les débutants, mais on veut aussi que les débutants deviennent des gens avec la connaissance.
Hier, on m'a dit : un développeur qui fait faire des entretiens à des gens pour une boite de jeux vidéo était toujours plus étonné de voir comment le niveau descendait. Et depuis le début je sais que le niveau en sortie d'université et le niveau voulu par les boites est totalement différent (ce n'est pas qu'en jeux vidéo). Alors essayons de donner des clés en main.
On ne force pas à faire un truc en UDP, on montre juste ce qui est dans le monde, comment les gens réfléchissent et c'est toujours cool de savoir comment est réellement fait un jeu vidéo, non ?
bref, désolé pour le hors sujet
Bonjour,
Merci pour cette traduction.
Oui, je n'ai jamais dit le contraire, ni même dit que la rubrique doit rester réservé à des débutants et je suis bien content que la rubrique ai des articles de ce genre très intéressant.
Des universités et du reste, et pas que dans le développement. L'enseignement supérieur en France == une vaste blague.
signé, un ancien étudiant inutile et aigri !
connecté / déconnecté
Bonjour,
Un aspect important à prendre en compte est la notion de connecté / déconnecté.
En TCP : un client initie une connexion avec un serveur, les communications peuvent ensuite aller dans les deux sens
En UDP : un client se connecte à un serveur et le serveur au client. Deux connexions à établir.
La différence qui en résulte et que la connexion TCP fonctionne très bien sans configuration particulière des routeurs côté client, contrairement à l'UDP. Cela peut être tout à fait acceptable pour des jeux en local, mais dès qu'on utilise internet, c'est un problème qu'il faut pouvoir prendre en compte.
UDP ne fait pas de connexion, il écoute sur un port les paquets entrants, et permet d'envoyer des paquets sortants.
On maitrise depuis un moment des techniques de nat traversal, qui marchent dans 95% des cas.
Pour les 5% restants, ils devront (re)configurer leur routeur pour rediriger le port. Mais ils savent faire, puisqu'ils ont déjà fait une configuration qui le bloque.
Si on souhaite aussi être sympa avec eux, on mettre en place un serveur de relay.
Ca ajoute des serveurs, comme pour TCP, et ça a un cout.
En soi c'est un faux problème que l'on règle aisément avec la technique que cette série d'article montre.
Abus de langage de ma part. L'idée à retenir était surtout que TCP permet une communication bilatérale, tandis qu'UDP ne permet la communication que dans un seul sens, et nécessite donc deux canaux.
Oui, il existe des méthodes, mais cela rajoute encore de la complexité qui dépasse le cadre de l'échange de données à proprement parler puisqu'on aborde ici le sujet de l'infrastructure en général. Les "5%" ne sauront peut être pas forcément le faire. Je me suis retrouvé dans cette configuration par défaut avec ma box internet. Heureusement que je m'y connais ^^.
Par contre, je n'ai pas compris le coup des serveur relay en UDP. En TCP je vois très bien ce que c'est et le principe de fonctionnement, mais en UDP, en cas un serveur relay peut-il résoudre le problème ? Si le client est derrière un routeur, il faudra bien configuré (manuellement ou automatiquement) le routeur pour qu'il achemine les paquets UDP à destination.
Ce n'est pas un faux problème. C'est un problème qui a certes des solutions, mais dont l'aspect est négligé dans l'article. Ce qui n'enlève en rien à l'intérêt et à la pertinence de l'article.
Le choix d'"UDP vs TCP" me fait penser au choix "C++ vs Java" (ou plus généralement "langage sans GC vs langage avec GC").
Dans le milieu amateur le choix se fait parce qu'on est plus à l'aise avec un langage qu'un autre.
Dans le milieu pro, le risque d'un freeze de quelques ms le temps que le GC fasse le ménage rend les langages avec GC "inutilisables".
À noter quand même que l'article parle de FPS (ou tout autre jeu où la moindre latence est inacceptable), mais que la conclusion est plus générale.J'imagine que c'est un oubli de ne pas avoir répété "pour les jeux d'actions / FPS" et que pour les jeux où on peut s'autoriser une perte de quelques dizaines de ms (MMORPG par exemple ?) TCP peut être un bon choix ?Ma recommandation n'est donc pas seulement d'utiliser UDP, mais que pour votre protocole de jeu vous n'utilisiez qu'UDP.
Ou alors la conclusion est aussi générale pour faire passer le message que temps réel = UDP ?
(Bonne traduction sinon).
Mais faut arrêter de dire que les MMORPG peuvent se permettre des latences oO. Tous ces fichus leatrix latency fix (dont j'imagine certains ont déjà entendu parler) qui, il me semble mais je me trompe peut-être, sont supposés réduire le nombre d'ack ou accepter une plus grosse marge d'erreur au niveau des paquets je ne sais plus, ça n'existerait pas si les latences n'étaient pas un problème avec les MMO. Dès qu'un MMO a du pvp la moindre latence est un problème ENORME (bon surtout pour les nerfs du joueur), alors déjà qu'on a le problème des connexions à débits inégaux (tout le monde se préoccupe du boulet qui veut garder son PC d'il y a dix ans mais tout le monde se fiche du gars qui ne peut strictement rien faire à sa petite connexion), le peering complètement moisi de plus en plus fréquent (genre gameforge est passé maître dans cet art et battleping c'est payant), je ne crois pas que miser sur un truc plus lourd de base soit forcément intelligent. Un MMO est aussi compétitif qu'un FPS, il n'y a pas que le PVE, et l'enchaînement des compétences demande une précision très nette de synchronisation. Personne n'a jamais fait de crise à pouvoir encore se déplacer mais aucune technique ne sort parce qu'on est déjà mort mais qu'on ne le sait pas encore ?
Moi je ne vois qu'un jeu de stratégie où le choix du TCP ne serait pas réellement handicapant. Hormis ce style de jeu tous les autres nécessitent d'éviter la moindre latence (oui bon tous les styles peu représentés comme les jeux de cartes, échecs et autres aussi c'est sûr, et d'autres aussi mais il y en a tellement ...).
2 canaux ??
Pour comuniquer en UDP, tu ne crées qu'un socket..
TCP permet surtout de camoufler tout les échanges et de faire croire à l'utilisation d'un stream, d'un fichier. Tu remarqueras que le paramètre à passer à socket est SOCK_STREAM. D'ailleurs (sous Unix uniquement il me semble) les fonctions relatives aux fichiers (read et write) peuvent être utilisées sur un socket qui est un filedescriptor, et pour fermer un socket on utilise close.
Ces techniques ne sont que des techniques d'échange de données. Et c'est pas Joe le rigolo qui la mettra en place mais ton équipe de programmeurs réseau..
Ca ne change rien pour le reste de l'application qui continue de faire un simple Send et traiter les messages arrivants/décodés par le réseau.
Je vois pas pourquoi tu différencies autant TCP et UDP.
Quant au routeur, il ne bloque que les connexions entrantes inconnues (je n'ai plus le terme exact). Sinon tu pourrais jamais utiliser internet.. je te rappelle que tout ça passe par la couche IP.
La latence est importante, mais ce n'est pas la seule chose qui importe. On a développé des techniques pour améliorer le rendu et compenser le lag : interpollation, prédiction, ...
Il l'explique bien mieux dans son talk à la GDC http://gdcvault.com/play/1022195/Phy...ers-Networking
Mais ça dépasse de loin le sujet de cette série d'article, qui n'est que l'envoi des données.
Ce n'est pas un oubli, c'est la traduction exacte de son article.
La conclusion est : oubliez TCP et faites de l'UDP. En introduction de l'article, il clame clairement que sa série d'article prend pour background un jeu d'action temps-réel comme un fps.
Si tu veux faire un jeu en tour/tour, avec un serveur, TCP fera l'affaire. (civilization, hearthstone likes)
Dans un autre cas, TCP ne fera que plomber ton application et ne devrait pas être utilisé.
Tu peux aussi le faire en UDP grâce à la fonction connect().
Pour avoir une communication bilatérale avec UDP, il faut pouvoir créer 2 canaux de communication : 1 dans le sens client->serveur, un autre dans le sens serveur->client. On passe par le même socket, mais il faut que l'une et l'autre des parties puisses initier la communication. Du coup, deux canaux : un pour les informations entrantes, un pour les informations sortantes. Il faut que le serveur soit joignable "directement" par le client et le client par le serveur à tout moment. En TCP, il est uniquement nécessaire que le serveur soit joignable par le client et une fois que la connexion est établie, elle peut se faire dans les deux sens, qu'importe le routage.
Non. Ces techniques nécessite d'agir d'une manière ou d'une autre sur l'infrastructure du réseau. UPNP par exemple, nécessite d'avoir des routeurs compatibles et que l'option soit activée. Idem pour le "Hole punching" (désolé pour l'anglicisme, mais je ne connais pas la traduction correspondante ^^). Il faut avoir un routeur qui le supporte.
Avec TCP, dès lors que la communication "sort", la réponse peut "entrer".
Je différencie les deux car les deux sont différents (M. Lapalisse n'aurait pas fait mieux :p). Avec TCP, si un client envoie un message à un serveur, alors le serveur peut répondre directement à ce client. C'est intrinsèque à la nature même de TCP. Avec UDP, un client peut envoyer un message à un serveur et le serveur peut ne pas être en mesure de lui répondre si le client n'est pas accessible directement (par exemple, car derrière un routeur). Et dans cette configuration, avoir un serveur relay (suggestion que tu as faite), je ne vois pas du tout ce que cela change. Ma question reste donc toujours en suspens...Je vois pas pourquoi tu différencies autant TCP et UDP.
Quant au routeur, il ne bloque que les connexions entrantes inconnues (je n'ai plus le terme exact). Sinon tu pourrais jamais utiliser internet.. je te rappelle que tout ça passe par la couche IP.
Répondre avec citation
Partager