Discussion :

[slouma_b_h]

bonjour tout le monde,
je suis à ma première expérience de développement de jeu en réseau et j'aimerai savoir ce qu'est le mieux pour les objets à échanger entre le client et le serveur? est ce des objets xml ou des objets serialisables?

merci pour votre aide
a+

[nouknouk]

salut,

tout dépend de tes besoins, des technos utilisées et du type de jeu que tu es en train de développer (un jeu de carte et un quake-like n'ont absolument pas les même besoins).

Mais en règle générale, ce n'est ni l'un ni l'autre: les jeux utilisent généralement leur propre protocole propriétaire, dans le sens ou leur brique réseau sérialise elle-même les infos qu'elle veut transmettre.

[slouma_b_h]

merci pour la réponse,
je développe plus mon idée:
je veux mettre en place un serveur pouvant gérer plusieurs genre de jeux; que ce soit en tour par tour ou en temps réel.
pour le tour par tour (jeux de cartes, je de plateau...), je sais bien que le xml peut faire l'affaire mais ma question c'est surtout l'impact sur les performances du réseau, et le temps de traitement de l'info échangé.
la deuxième partie de ta réponse m'intéresse beaucoup et je te serai reconnaissant si tu pourrais me filer des tuyaux sur le sujet (doc, tutoriaux,....)
merci beaucoup et a+

[nouknouk]

re,

il y a deux aspects principaux à prendre en compte:
- l'impact du choix d'un format de données sur la consommation en bande passante.
- l'impact du choix d'un format de données sur la consommation en temps CPU pour décoder.

Deux exemples du contenu d'un message qui contient les même données: dans un jeu de cartes, je veux envoyer un message pour dire que le client a joué l'As de pique.

1ère solution on utilise du XML:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
<action type="JoueCarte">
    <carte>
        <valeur>As</valeur>
        <couleur>Pique</couleur>
    </carte>
</action>

Résultat: le message encodé en ASCII de base pèse 128 octets.

2ème solution on se fabrique notre propre protocole:

- un message commence par un entier codé sur 2 octets pour la taille totale du message à l'exclusion faite du présent champ 'taille' et du champ ci-après 'typeAction'.

- vient ensuite un champ codé sur un octet pour le type d'action (1=JoueCarte ; 2=Passe ; 3=etc...)

- pour les messages de type JoueCarte, l'unique valeur stockée ensuite est la valeur de la carte, codé sur 1 octet "00VVVVCC", où:
* 0 représente un bit toujours à zéro
* VVVV représente les 4 bits de valeur de carte (1=As, 2=Deux, ... 13=Roi)
* CC représente 2 bits codant la couleur (00=Pique, 01=Coeur, 10=Carreau, 11=Trèfle).

On a au final un message qui tient en 2+1+1 = 4 octets (à comparer aux 128 octets du message en XML). Et encore, tu pourrais décider que le type de message (JoueCarte) suffit pour savoir que le message n'aura qu'un octet de long (car tous les messages JoueCarte n'auront qu'une valeur de carte associée) et donc économiser les deux premiers octets.

Ce type de message demandera de plus beaucoup moins de puissance CPU pour être décodé (quelques opérations sur les bits des octets suffiront, comparé à un parsing de texte formaté en XML).

Donc le cas n°2 est meilleur en consommation de bande passante et en temps CPU.

Par contre, il est beaucoup moins lisible (pour le debug notamment) et si tu dois t'interfacer un jour avec quelque chose d'autre, ce ne sera pas chose aisée (contrairement au XML qui est devenu un standard).

En bref, il doit exister une infinité de façon de coder un même message, mes deux exemples ci-dessus sont deux cas plus ou moins extrêmes pour mettre en valeur les différences. Après, il n'y a pas une réposne idéale et applicable partout ; c'est à chacun de faire un compromis entre:

- compacité (pour économiser de la bande passante)
- généricité (pour réutiliser la brique réseau pour différents projets)
- lisibilité (pour la facilité de debug)
- interfaçage pour permettre à des programmes tiers de se connecter à notre serveur
- performances au décodage (pour minimiser les ressources consommées côté serveur).

EDIT: un post sur l'architecture générale d'un client/serveur relativement générique qui devrait te donner quelques idées.

[slouma_b_h]

merci beaucoup pour tes réponses
a+

[deadalnix]

Sauf que dans les deux cas, 128 ou 4 octets, on n'envoie qu'un paquet sur le réseau, donc ça ne change pas grand chose.

Avec de telles tailles les l'overhead du aux protocoles réseaux est de toute façon bien supérieur aux données envoyées. Par contre, il est clair que l'xml sera plus long à coder/decoder.

A mon avis, tu ne devrait pas faire un truc à la fois pour le temps réel et le tour par tour, les contraintes sont trop différentes.

[nouknouk]

Sauf que dans les deux cas, 128 ou 4 octets, on n'envoie qu'un paquet sur le réseau, donc ça ne change pas grand chose.

Je ne comprends pas où tu veux en venir.

Avec de telles tailles les l'overhead du aux protocoles réseaux est de toute façon bien supérieur aux données envoyées.

Pas d'accord: même avec les en-têtes TCP, on abouti quand même à un paquet 6 fois moins gros pour les même données utiles (24 vs. 148 octets). C'est loin d'être négligeable.

Bien sûr, si on raisonne côté client, et que dans le cadre d'un jeu de cartes on n'envoie qu'un paquet toutes les 5 secondes, ça ne change pour ainsi dire rien du tout.

Mais si on raisonne côté serveur quand x centaines de joueurs sont connectés en même temps, ça peut faite une énorme différence: ici si on raisonne uniquement sur l'aspect "consommation de bande passante", on supporterait 6 fois plus de clients sur un même serveur.

Enfin, au risque de me répéter, je n'ai jamais dit que le protocole le moins consommateur en bande passante était forcément l'idéal, cf mon dernier paragraphe: "il n'y a pas une réponse idéale et applicable partout ; c'est à chacun de faire un compromis entre [...]"

A mon avis, tu ne devrait pas faire un truc à la fois pour le temps réel et le tour par tour, les contraintes sont trop différentes.

+1

[deadalnix]

Pas d'accord: même avec les en-têtes TCP, on abouti quand même à un paquet 6 fois moins gros pour les même données utiles (24 vs. 148 octets). C'est loin d'être négligeable.

Et après, on rajoute l'en tête IP, puis on empaquette tout cela dans un trame ethernet.

Et puis, si on revient sur TCP, tu as tous les paquets qui vont avec, SYN SYN/ACK ACK puis ACK à chaque fois que tu arrive en bout de fenêtre.

Mais bon, en tour par tour le débit est souvent pas un problème, donc je pensais plus à du temps réel, et la TCP c'est vraiment pas l'idéal.

Bref, 128 octets, c'est trop faible pour avoir une différence notable. La différence entre 128 et 512 devrait par exemple être bien plus signification qu'entre 4 et 128.

[nouknouk]

Et après, on rajoute l'en tête IP, puis on empaquette tout cela dans un trame ethernet.

Non, les calculs de bande passante se font couramment au niveau IP. C'est ce qu'on te 'vend' quand tu prends un serveur dédié ; le reste n'est pas le problème du développeur de jeu qui va louer un serveur.

Et puis, si on revient sur TCP, tu as tous les paquets qui vont avec, SYN SYN/ACK ACK puis ACK à chaque fois que tu arrive en bout de fenêtre.

On comparait deux façons d'encoder un même message indépendamment du protocole sous-jacent.
Si tu veux comparer TCP et UDP c'est une autre histoire, et là encore il faudra prendre d'autres choses en compte pour UDP: par exemple la surcharge résultant de la mise en place de mécanismes de 'sécurisation' et d'ordonnancement de (certains) paquets.

Mais bon, en tour par tour le débit est souvent pas un problème, donc je pensais plus à du temps réel, et la TCP c'est vraiment pas l'idéal.

Il y a 'temps réel' et 'Temps Réel' ; un bomberman like ou un petit jeu de voiture, peuvent très bien être basés sur des flux TCP. J'en veux pour preuve les jeux online en Flash (flash ne propose que le TCP), comme ceux de OMGPOP ... ou le projet sur lequel je bosse actuellement. J'ai même déjà pu apercevoir un 'FPS' en 2D fait également en flash qui tournait plutôt très bien.

Bref, 128 octets, c'est trop faible pour avoir une différence notable.

On parlait ici d'un facteur 6. Et même si on ne parlait que d'un facteur 2, c'est loin d'être négligeable quand tu dois sortir toi-même les euros de ton porte-monnaie pour payer la location de tes serveurs et/ou de ta bande passante !

[deadalnix]

Non, les calculs de bande passante se font couramment au niveau IP. C'est ce qu'on te 'vend' quand tu prends un serveur dédié ; le reste n'est pas le problème du développeur de jeu qui va louer un serveur.

Le débit IP n'inclue pas les en tête IP si je me souvient bien. De toute façon, quelque soit ce que spécifie le contrat, techniquement, t'aura pas les mêmes perfs en envoyant 10 paquet de 4 octets qu'un de 40.

[yamashi]

Et dire qu'on entend encore des gens qui disent que je TCP est lent a cause de ses en-tête...
J'ai envie de dire qu'on s'en fou un peu ici non ? pour un jeu de carte on a pas besoin de faire une update 1000 fois par seconde si ?
Après si on parlait d'un FPS j'ai envie de dire cette fois que le TCP serait celui qui consommerait le moins par rapport a l'UDP bien que ses entêtes soit plus lourde, mais pourquoi me dirait vous ?!
C'est plutôt simple, le TCP utilise l'algorithme de nagle, il va envoyer plusieurs paquet en 1 paquet donc il y a un gains sur la taille du header...
Donc envoyer 10 paquets de 4 octets reviendrais en TCP a envoyer 1 paquet de 40 octets... On y gagne donc par rapport a UDP qui va envoyer 10x 4 octets + header...

[deadalnix]

Si TCP est lent, c'est clairement pas à cause des en têtes, mais de la lourdeur du protocole en lui même : on ne reçoit pas les infos dans le désordre, les infos doivent être acquittées, etc . . .

[nouknouk]

Après si on parlait d'un FPS j'ai envie de dire cette fois que le TCP serait celui qui consommerait le moins par rapport a l'UDP bien que ses entêtes soit plus lourde, mais pourquoi me dirait vous ?!
C'est plutôt simple, le TCP utilise l'algorithme de nagle, il va envoyer plusieurs paquet en 1 paquet donc il y a un gains sur la taille du header...
Donc envoyer 10 paquets de 4 octets reviendrais en TCP a envoyer 1 paquet de 40 octets... On y gagne donc par rapport a UDP qui va envoyer 10x 4 octets + header...

L'algorithme de Nagle permet d'optimiser l'utilisation de la bande passantee en retardant l'émission de certains paquets dans le cas où des données seront encore à envoyer juste après. Ce retard est inacceptable dans le cadre d'un jeu réseau à fortes contraintes temps-réel, typiquement le cas d'un FPS.

C'est pourquoi lorsque TCP est utilisé dans une communication réseau avec de fortes contraintes temps-réel, l'algorithme de Nagle est systématiquement désactivé.

De même, autant TCP peut faire l'affaire dans de nombreux cas (en règle générale plus que ce qu'on pourrait croire quand on débute en réseau), autant il ne faut pas me faire dire ce que je n'ai pas dit: l'UDP reste l'idéal pour les flux à très fortes contraintes temps-réel, ce n'est d'ailleurs pas pour rien que la quasi totalité des FPS par exemple l'utilise.

[deadalnix]

On notera qu'on peut utiliser RTP si l'on veux retrouver certaines fonction de TCP qui n'existent plus en UDP.

RTP fonctionne couche 5, donc ça s'emboite dans du UDP afin d'en completer les fonctionnalités. C'est pas mal utilisé en VoIP par exemple, peu dans le monde du jeu, mais ça a du potentiel a mon avis.