Discussion :

[johnvx]

Bonjour,

Depuis quelques temps, je me suis lancé (avec 2 collègues) dans la création d'un jeu online. Ayant parcouru les forums à la recherche d'informations sur la partie qui me concernait particulièrement - le moteur réseau - je me suis rendu compte que l'on parle énormement 3D et physique mais que la partie communication est bien moins débattue.
Je crée donc ce post afin de partager des expériences et des questionnements avec les gens interessés par le sujet.
J'aimerais également que les gens qui connaissent des librairies réseaux et/ou en ont developpés viennent en parler.
Enfin, dans une partie plus "technique" j'aimerais discuter de choses spécifiques comme la gestion des connexions, les protocoles, les timers, l'optimisation de bande passante, ou encore de gestion de la sécurité.

Cordialement,

John

[Onlava]

Salut,

D'après moi tout dépend du type de jeu dont on parle. On n'attent pas les mêmes choses d'un serveur de jeu FPS que d'un RTS ou même d'un MMO.

Pour le protocole tu as en gros le choix entre TCP (connecté) et UDP (non-connecté).
L'avantage de TCP est qu'il guaranti l'intégrité et l'ordre des paquets et qu'il s'occupe également des ACK / resends.
Le seul désavantage par rapport à UDP c'est que les trames sont légérement plus grandes.

Le principe c'est de dire que toute information échangée fréquemment et qui peut être perdue est sujette à passer par des messages UDP.
Par exemple : l'envoi des positions des joueurs dans un FPS. Pour tout le reste, TCP fais l'affaire.

A propos de l'optimisation des trames je dirais qu'il faut tout ecrire en binaire, utiliser des bitmasks quand cela est possible, tout en gardant le bon equilibre entre taille des trames / temps de process des messages.
Avoir une couche de compression peut être bénéfique pour les trames suffisament grosses.

La sécurité dépend de l'algorythme de chiffrage utilisé. Personellement j'opterais plutot pour une solution de cryptage légère (genre XORing avec clé de session).
Il faut bien être conscient du fait que si ton application peut déchiffrer les données du serveur, alors il suffit à un hackeur de faire du "reverse-engineering" pour pouvoir reproduire ce comportement et faire un bot.
Sinon il y a aussi des algos genre blowfish, mais qui sont plus lourds coté CPU. La encore, tout dépend du type de jeu et des perfs nécéssaires au serveur surtout.

Sinon en rêgle génélrale il faut partir du principe que "le client ment".
En gros gérer toutes les variables coté serveur et vérifier au maximum les valeurs des paquets provenant du client sans jamais lui faire confiance.
Par exemple on mettera tous les timers coté serveur histoire d'éviter qu'un petit malin modifie les time-out sur son application client et puisse tricher.

Voilà j'aspère que ça répond en partie à tes questions.
Etant un amateur dans le domaine, l'avis d'un proffesionnel m'intéresse aussi.

a+

[nouknouk]

Pour le protocole tu as en gros le choix entre TCP (connecté) et UDP (non-connecté). [...] Le seul désavantage par rapport à UDP c'est que les trames sont légérement plus grandes.

Oui, mais non.

L'autre désavantage du TCP par rapport à l'UDP est surtout le temps de transmission en cas de perte de paquets. Je m'explique : si un paquet N a été perdu en cours de route, TCP qui ne supporte pas les pertes va redemander ledit paquet à la source. Tant que le paquet N n'a pas été ré-émis et reçu, tous les autres paquets reçus entre temps (N+x) ne seront pas remis à l'application qui gère la socket.

C'est pour ça que l'UDP est hautement utilisé pour les connexions où la contrainte de temps est (très) forte et les données volatiles.

Un exemple parlant : le FPS. Si le paquet qui disait "joueur 7 à position 123,456 à 12h01m03,234s" est perdu. Ca n'a plus de sens de vouloir le récupérer ensuite.
On préfèrera l'oublier et récupérer au plus vite la prochaine position du joueur 7.

Toujours à propos de l'UDP, il ne faut pas oublier non plus que les données peuvent être corrompues. Donc qu'un paquet peut arriver mais contenant n'imp. A prendre en compte si on veut pas que le programme plante à cause du cas non géré d'une donnée corrompue.

Dernière chose: une fois les protocoles bien maîtrisés, l'important est aussi de regarder du côté des mécanismes pour gérer la continuité du temps entre deux actions. Les mécanismes comme le Dead reconing te permettront à la fois d'avoir des mouvements fluides à l'écran et d'optimiser ta bande passante (ie. en s'abstenant d'envoyer les informations qui peuvent être dévinées par la machine d'en face).

[nicØB]

Toujours à propos de l'UDP, il ne faut pas oublier non plus que les données peuvent être corrompues. Donc qu'un paquet peut arriver mais contenant n'imp. A prendre en compte si on veut pas que le programme plante à cause du cas non géré d'une donnée corrompue.

J'ajoute juste qu'avec UDP il y a un checksum facultatif (sur 16 bits).
Par contre je ne sais plus comment il faut faire pour qu'il soit utilisé ou non (et si il l'est par défaut). Ca peut être utile pour éviter de faire un checksum sois même.

[johnvx]

Bonjour,

Je vous remercie de l'attention que vous avez porté à ce post.
Je trouve très intéressantes les remarques de nouknouk sur UDP ainsi que sur le dead reconing, cela va m'être utile.
Suite à la remarque de nic0b, je vais me pencher de plus près sur les options de UDP que peuvent amener à de bonnes choses je pense.

Dernièrement, j'ai longuement parcouru les codes sources de différentes bibliothèques réseau pour les jeux. Il s'agit principalement de TNL (Torque Network Library) qui est orienté FPS. J'ai trouvé de bonnes choses dans les concepts de sécurité. Je parle par exemple du système de puzzle crypto pour l'établissement d'une connexion. Je connaissais cette méthode déjà utilisée par exemple sur les systèmes SCADA et il est vrai que cela peut être intéressant dans mon cas afin d'éviter la saturation du serveur en augmentant en prime la complexité du puzzle en fonction de la charge.
j'ai également épluché NLHawk qui est bien plus légère et fournie que TNL mais très intéressante pour débuter.

Je suis actuellement dans la prédiction de mouvements, les timers et d'une manière générale, tout ce qui me permettra de gérer la fluidité et la bande passante.
Petite précision, nous développons sous GNU/Linux exclusivement. Un portage BSD sera éventuellement effectué suivant le stade d'avancement du jeu. J'ai lu un papier il y a quelques temps qui parlait justement du portage Linux > BSD et il semble que les API soient très proches.

Je posterais dans quelques temps pour plus de détails sur mes choix techniques(sécurité, gestion des connexions, acheminement p2p etc.)

A bientôt!

Johnvx