Création d'un serveur, quels vérifications faire ?

Pour parler d'un système d'un jeu que je connais — Minecraft —, celui-ci cumule deux techniques.

La première, c'est celle citée par Folaefolc, pour les actions qui ne nécessitent pas une très faible latence. Lorsqu'une telle action est effectuée par le client (par exemple, poser un bloc), le client va dire au serveur « je fais ça », et attendre que le serveur confirme que c'est bon. Pour donner une impression de fluidité, le client va graphiquement effectuer l'action immédiatement dans certains cas, et en cas d'action invalide, elle sera retirée côté client (typiquement, un bloc qui n'aurait jamais dû être posé sera retiré).

Pour d'autres actions ce n'est pas vraiment possible car il est nécessaire d'avoir une grande fluidité côté client pour que tout soit fluide. Typiquement, les déplacements ou certaines actions. Dans ce cas, ce qui est fait, c'est que le serveur fait de base confiance au client, et vérifie périodiquement ses actions et leur cohérence (vitesse, par exemple). Dans ce cas précis il est difficile de les « corriger », mais ça peut être utilisé pour avertir d'éventuels modérateurs ou bannir automatiquement, selon les cas, selon les serveurs.

Ce n'est pas le meilleur système pour bien contrer la triche, mais il permet une plus grande fluidité d'actions pour les clients, même avec une connexion dégradée.

Pour ce qui est de Minecraft, le premier point est globalement natif, mais le second se borne aux déplacements et à un avertissement dans la console du serveur. Certains serveurs ajoutent des surcouches pour avoir un système plus complet pour éviter la triche.

LE point clé dans pas mal de cas si on peut, c'est l'interface optimiste, comme évoqué par AmauryPi.

L'interface optimiste, basiquement ça veut dire que l'utilisateur envoie toutes les actions qu'il effectue, le serveur les valide, mais avant même que l'action ne soit validée on fait comme si elle l'était déjà (affichage immédiat du résultat, car on présume que l'action sera validée dans 99.9% des cas). Comme ça on combine une latence apparante faible pour l'utilisateur, et la sécurité.

A noter que ça ne s'applique pas seulement aux jeux, mais aussi de plus en plus à tout le reste, interfaces de sites web notamment.

L'autre élément important et ça a aussi déjà été évoqué, c'est la prédiction. Mais ça peut faire appel à des algorithmes rapidement compliqués suivant le type de jeu (comment prédire où sera l'armée de l'adversaire dans 5 secondes ?) C'est des erreurs de prédiction brusquement corrigées à postériori qui peuvent donner l'impression que les unités « sautent », donc c'est très délicat à mettre en place et surtout à doser.

La logique complètement inverse, client lourd et serveur léger, c'est très mauvais pour gérer la triche, mais ça a quand même d'autres avantages: faire un serveur « idiot » qui broadcast sans discernement tout ce qu'il reçoit aux autres joueurs de la partie, ça a l'avantage d'être hyper flexible et de permettre beaucoup plus de connexions simultanées. Ca peut fonctionner très bien pour des jeux où plus rien n'existe après la fin de la partie, mais clairement ce n'est pas adapté pour un MMO.