Discussion :

[Charlie111]

Bonjour tout le monde,

je crée un petit bomberman multi tout bête et j'ai une grosse question...
Un protocole TCP sera-il suffisant pour un tel jeu ?

Je débute en réseau et je préfèrerai ne pas m'aventurer tout de suite dans les affres de l'UDP ^^.

Merci d'avance

Bye
Charlie

Aaaaa attendez, j'ai une autre question soudaine qui vient d'arriver la maintenant : Bomberman c'est toujours marque déposée ?!

[deadalnix]

En TCP, tu auras des latences plus grandes. Ça n'est pas vraiment adapté au JV temps réel (comme bomberman).

[Charlie111]

C'est bien ce que je craignais...

[nouknouk]

En TCP, tu auras des latences plus grandes. Ça n'est pas vraiment adapté au JV temps réel (comme bomberman).

Oui mais non: il y a "temps réel" et "temps réel": autant un jeu "hautement temps réel" comme un FPS (Quake, Counter Strike, ...) ne pourra pas se satisfaire d'une communication en TCP, autant des jeux où la réactivité est un peu moins critique pourront très bien s'en accommoder.

J'avais fais quelques tests basiques en vue d'aider quelqu'un à développer un petit jeu de course de voiture en 2D (genre micromachines) en ligne. Il apparait que le ping peut varier entre 60 millisecondes (serveur dédié OVH, connexion depuis la France ou l'Europe) et 300 millisecondes (connexion depuis l'Asie ou US côte ouest). C'est finalement cet aspect là qui est critique plus que tous les autres. Mais on ne peut rien y faire si ce n'est avoir plusieurs serveurs répartis géographiquement.

Clairement, avec 60 millisecondes et jusqu'à 120 millisecondes , même un petit jeu de voiture (qui est plus critique qu'un bomberman like) ça peut passer sans soucis en TCP.

Techniquement parlant, le temps de transmission n'est pas plus important qu'avec de l'UDP et la charge réseau est moins importante en TCP qu'en UDP (headers UDP plus grands que les headers TCP). Le seul cas où le TCP est plus 'lent', c'est si tu perds un paquet en route: avant de délivrer le paquet suivant à l'application, la pile TCP redemande le paquet perdu et attend qu'il soit récupéré pour le délivrer.
Mais la perte de paquets a tendance à être de plus en plus faible de nos jours où on ne communique plus guère avec des modems RTC sur une ligne téléphonique (principale cause de pertes de paquets) et où les accès au net sont largement dimensionnés et où la saturation de la bande passante est plus rare.

Donc je serais toi, je commencerais par faire du TCP, qui est 100x plus simple à gérer que l'UDP (car il faut gérer la perte/corruption de paquets, la protection des paquets 'importants', ...). Ensuite, si et seulement si tu vois que ce n'est vraiment pas gérable, tu pourras toujours switcher vers UDP.

Dernier point: il existe déjà plusieurs clones de bomberman à jouer en ligne qui passent très bien en TCP only, genre les jeux flash (techno qui ne propose que du TCP) de I'm in like with you (dont un bomberman). A noter qu'avec une connexion depuis la France, ça laggue parfois un peu car leur serveur est situé à San Francisco et la latence est donc élevée pour un européen. Mais avec une connexion américaine, c'est de la ... bombe

Bref, comme quoi c'est loin d'être impossible. Attention au idées reçues, la meilleure conseillère est l'expérience et les tests pratiques !

Bomberman c'est toujours marque déposée ?!

Etant donné que Hudson Entertainment exploite toujours la marque (cf. le dernier Bomberman Blast sur Wiiware), c'est certain que c'est pas tombé dans le domaine public.

[Acropole]

Y'a plein de librairies spécialisées qui te permettrons de ne pas avoir à te poser la question. Raknet par exemple.

[nouknouk]

Au passage, il y a un point à ne pas négliger puisqu'au vu de tes autres posts tu sembles vouloir développer un jeu web pour navigateur. Et qui dit jeu web dit "un jeu qui marche sans avoir à se prendre la tête".

Or, contrairement à une connexion TCP initiée par un client, l'UDP ne traverse pas certains équipements de type NAT sans devoir configurer à la main une redirection de ports.

Or les points d'accès wifi et les adslbox sont de plus en plus répandus et ils font justement office de NAT la plupart du temps. Certains sont relativement malins et arrivent à rediriger l'UDP sans qu'on lui ait rien configuré de spécial (type "si l'ordi x a envoyé récemment un paquet UDP sur le port y, il a pas mal de chances que si je reçois plus tard un paquet venant d'internet sur le port y, il sera destiné à x"). Mais ce n'est pas le cas de toutes les box. A prendre en compte dans ton choix.

[Charlie111]

puisqu'au vu de tes autres posts

Ahah oui dsl, je suis un peu en mode mitraillage de post

Enfait j'essaye de me faire une opinion sur l'efficacité d'une architecture client serveur en TCP. Je n'ai pas l'intention d'utiliser l'UDP pour l'instant.
Comme dirais l'autre, chaque chose en son temps.

Y'a plein de librairies spécialisées qui te permettrons de ne pas avoir à te poser la question. Raknet par exemple.

Merci c'est une bonne idée. Cela dit, j'ai déjà utiliser Raknet (avec Ogre3D). Le truc c'est que je veux essayer de programmer l'architecture moi même. Ca m'amuse et en bonus, ça pourrait même m'être utile

[shenron666]

de toute façon, que tu fasses de l'udp ou non, il faudra toujours implémenter du tcp pour identifier et synchroniser le client avec le serveur

[nouknouk]

de toute façon, que tu fasses de l'udp ou non, il faudra toujours implémenter du tcp pour identifier et synchroniser le client avec le serveur

Pas forcément, au contraire: lorsque l'UDP est utilisé, il est en règle générale utilisé seul.
Un mécanisme d'acquitement au dessus d'UDP est alors utilisé pour 'sécuriser' les paquets de données qui doivent absolument arriver à destination (ce qui ne concerne pas uniquement l'authentification mais certaines 'étapes importantes' dans le jeu également).

[deadalnix]

NAT fonctionne avec UDP parfaitement.

Le problème de la redirection de port existe a l'initialisation de la connection, et est le même en UDP et TCP.

[shenron666]

Pas forcément, au contraire: lorsque l'UDP est utilisé, il est en règle générale utilisé seul.
Un mécanisme d'acquitement au dessus d'UDP est alors utilisé pour 'sécuriser' les paquets de données qui doivent absolument arriver à destination (ce qui ne concerne pas uniquement l'authentification mais certaines 'étapes importantes' dans le jeu également).

tu veux dire que tu crées une surcouche ou un système de sécurisation autour d'UDP pour avoir la même chose que TCP ?

[nouknouk]

tu veux dire que tu crées une surcouche ou un système de sécurisation autour d'UDP pour avoir la même chose que TCP ?

oui, j'insiste et je dirais même plus: une surcouche au dessus de UDP pour au final avoir moins bien que TCP (pas de contrôle de congestion pas exemple) !

Et ce n'est pas une lubie: c'est l'état de l'art actuel qui conseille d'éviter de mélanger à la fois des flux TCP et UDP.

J'ai pas de références sous la main, mais google t'en trouveras sans avoir besoin de chercher bien loin (mots clef: "reliable udp")

[IrmatDen]

J'ai fouillé et suis tombé sur cette page. L'auteur précise bien que ne pas mixer TCP et UDP est important, mais principalement dans le cas où la quantité d'infos émise s'approche de la bande passante dispo (sur la plus petite des connexions je suppose).

[2 minutes plus tard...]
Mais cet article présente une autre raison d'éviter de mixer les 2, à savoir la possibilité de fusionner plusieurs paquets en un.

J'ai comme l'impression que c'est déconseillé mais pas un absolu et que ça dépend pas mal du contexte en fait Si tu as d'autres liens en tête que ceux-ci, je suis preneur (j'ai pas trouvé autre chose de plus ou moins lié au jeu vidéo et qui qui dise autre chose que "GFI" )

[johnvx]

Bonjour,

Étant sur le développement d'un moteur réseau d'envergure pour un jeu vidéo depuis 2 ans, par expérience j'utilise les 2 modes de transports. Je pense que certaines informations d'un jeu doivent être envoyé dans des contraintes qui font que UDP est la meilleure solution mais que faire passer certaines par TCP est un meilleur choix.
Je prends un exemple : les statistiques d'un joueur ou du jeu n'ont pas besoin (dans la majorité des cas) d'arriver le plus rapidement possible, l'essentiel étant qu'elle arrive, alors, pourquoi ne pas utiliser TCP.
Dans le cas de la position d'un joueur, principe valable surtout dans les jeux où les positions changent rapidement et sont essentielles dans l'interaction entre les joueurs (ex: FPS...), l'utilisation d'UDP est bien meilleure, et pour en revenir à l'exemple du FPS, si un paquet de position se perd, il est en général inutile de le renvoyer puisque au moment où la retransmission sera reçu, la position sera complètement obsolète.
Je pense donc que l'utilisation de l'un ou l'autre combiné au système l'englobant ("surcouche protocolaire de niveau applicatif) dépend des "micros contextes" internes au jeu.
Bien entendu, il faut veiller à ce que les informations véhiculées par l'un des canaux n'est pas une trop forte dépendance avec l'autre sous peine de désequencement ce qui peu aboutir à du grand n'importe quoi.
J'ajouterais qu'il m'arrive même à l'occasion d'utiliser des sockets RAW pour des raisons de supervision, debug réseau, et autres mécanismes de sécurité (notamment anti-cheats).
Mais ceci dit, (et si j'ai été clair lol) ce n'est que mon choix d'orientation et ce n'est qu'un avis personnel.

xx

john