Discussion :

[Elendhil]

Quelles sont les avantages à décentraliser un jeu en ligne ?

Je vois pas trop les bénéfices de la chose , peut-être au niveau de la bande passante mais dans ce cas c'est que tu fais passer autre chose que des 'données de logique de jeu' , genre de la vidéo , de la voie , graphismes ect ...

Et dans ce cas on est plus du tout dans le même problème ...

J'ai du mal a voir dans un jeu de poker ce qui pourrait prendre plus de 100 octets du serveur vers un client , et dans ce cas la mémoire et le processeur du serveur vont lâcher bien avant la saturation de la connexion de 200 Mbps.

Et vu le prix de la location d'un serveur qui est devenu relativement faible, on peut toujours clusteriser sans que cela coûte des sommes folles.

[SuperBidi]

Dans tous les cas, il n'existe pas de sécurité 'parfaite'. Mon prof de sécu pendant mes années d'étude disait à juste titre que la seule machine sécurisée, c'est un PC éteint. La question à se poser à chaque fois, c'est quel serait le coût du piratage pour quel gain.

Pour le moment, personne ne s'est penché sur la question.

Je dirais une chose : Si ton jeu de poker manipule du vrai argent, je compterai pas trop dessus.

Si c'est le cas, je ferai gaffe à trois choses :
Multi valider les messages clients par divers contrôleurs maître. Avoir un contrôleur pirate est beaucoup plus facile à réaliser qu'en avoir 2 qui valide en simultané une partie sur laquelle tu joues.
Faire en sorte que toutes les sommes soient majorées (et minorées) côté serveur. En gros, si un contrôleur maître signale qu'un joueur à gagné 1 million d'euro, vérifier que c'est possible en comparant la somme gagnée à la somme de toutes les mises initiales. Ca permet, en cas de piratage, de limiter un peu la casse.
Faire gaffe aux arrondis. Même si ce point est plus secondaire, il est vraiment arrivé à une banque : Un employé qui récupérait sur toutes les opérations de paiement les arrondis (tous les chiffres étaient arrondis au centime, lui récupérait les dixièmes de centimes). Impossible de repérer la fuite, et si y a beaucoup de données manipulées (cas du contrôleur maître), à force, ça fait de l'argent (le mec s'était fait 20000 francs, je crois).

Après, le langage compte aussi beaucoup. Le java est facile à décompiler. Même obfusqué, si tu remontes à partir des appels sur la lib standard, je pense que tu peux retrouver des patterns de fonctionnement rapidement (j'ai jamais testé, ça doit être casse tête, mais je pense qu'avec un débugger, ça doit se faire). Si c'est du C/C++, c'est une autre histoire et là, faut un crack pour le faire.

[Maldus]

Il est actif ce sujet !

Quelles sont les avantages à décentraliser un jeu en ligne ?

Gain de BP (déjà dit et déjà contestés), mais il n'y pas que les logiques de jeux qui transitent, les images des joueurs, les voix, les vérifications de sécurité, les listes de tables, .... (mais il ne faut pas oublier qu'on ne parle pas spécifiquement d'un jeu de poker).

Gain sur la puissance de calcul. A ne pas avoir a gérer des centaines de connexions ni des centaines de calculs inhérents au jeu, le processeur est saturé bien moins rapidement.

L'infrastructure n'est plus un problème à gérer, n'importe quel serveur tiendra la charge, qu'importe le nombre de connectés (dans la mesure du raisonnable)

En cas de micro-coupure, les contrôleurs maitres "survivent" quelques temps en autonomie en attendant le retour du serveur. En cas de reboot du serveur, tout le monde n'est pas déconnectés.

Plus il y a de monde, plus il y a de puissance et de BP dispo, aucune limite matérielle théorique (on peux donc imaginer plus de traitement et plus de transit de données).

C'est vachement plus sympa comme défi technique !

J'ai du mal a voir dans un jeu de poker ce qui pourrait prendre plus de 100 octets du serveur vers un client , et dans ce cas la mémoire et le processeur du serveur vont lâcher bien avant la saturation de la connexion de 200 Mbps.

Effectivement, mais on ne parle pas spécifiquement d'un jeu de poker, mais dans le cas présent, le but était surtout d'héberger le maximum avec le minimum !

On gère pour le poker, le chat, les voix, les images persos, les contrôles de sécurité, les routines de jeux, ... On arrive vite a quelque chose de conséquent (bien moins que n'importe quel autre jeu, mais lorsqu'on multiplie ne serait-ce que par 500 connectés , le processeur mouline ! Pas la BP je te l'accorde !)

Il est par exemple possible d'héberger près 200 personnes sur une simple ligne ADSL grâce à la décentralisation.

Reste à voir l'intégration pour d'autres jeux, ou le contenu diffusé est plus important !
Je m'amuse actuellement à l’intégrer et à tester les contraintes inhérentes aux FPS.

Pour exemple, actuellement (Poker):
Celeron d1.6Ghz => 500 Joueurs en pic (15% UC environ/ utilise moins de 280 Mo Ram / 11Mbit/s en pic)

Il est possible de limiter encore l'utilisation de bande passante (via différents reglagles) pour essayer d'héberger à la maison.

Et vu le prix de la location d'un serveur qui est devenu relativement faible, on peut toujours clusteriser sans que cela coûte des sommes folles.

C’est vrai

Multi valider les messages clients par divers contrôleurs maître. Avoir un contrôleur pirate est beaucoup plus facile à réaliser qu'en avoir 2 qui valide en simultané une partie sur laquelle tu joues.

Déjà implémenté de cette façon mais de façon aléatoire. Mais c’est quasiment toujours le cas

Faire en sorte que toutes les sommes soient majorées (et minorées) côté serveur. En gros, si un contrôleur maître signale qu'un joueur à gagné 1 million d'euro, vérifier que c'est possible en comparant la somme gagnée à la somme de toutes les mises initiales. Ca permet, en cas de piratage, de limiter un peu la casse.

Se fait lors de la verification des règles de jeux.
Avec 11000 jetons a la table il faut qu’a chaque fois qu’il y a une sortie tout soit bon, sinon le contrôleur refait les comptes en demandant l'historique à tout les clients, pour revalider les paquet.

[SuperBidi]

C'est vachement plus sympa comme défi technique !

Là, je te rejoins

Celeron d1.6Ghz => 500 Joueurs en pic (15% UC environ/ utilise moins de 280 Mo Ram / 11Mbit/s en pic)

Je suis un poil étonné par tes stats, que je trouve élevées.
Si je fais le calcul : 500 joueurs * 1 requête par seconde (je crois que c'est un poil inférieur sur un jeu en ligne, mais c'est globalement ça) * 400 octets (taille de la requête entrante comme des sorties) * 8 (bit->octet) = 1.6Mbit/s. Or, là, je parle des stats qu'aurait un serveur central. Tu as 10 fois ça avec une archi partagée.
15% UC environ : Ok, ton serveur ne m'a pas l'air d'être une bête de course. Mais ça fait 3000 joueurs max en simultanée (si on considère que tous tes traitements sont en O(nombre de connectés)). Même sur un serveur central, j'atteins des stats 5 fois meilleures.
T'es sûr de pas te retrouver avec une 'survalidation' ?
As tu benchmarké pour savoir quel process te prenait le plus de CPU ?

[Maldus]

Les informations entre les joueurs sont envoyés toutes les 100ms (inutile pour un jeu de poker je te l'accorde).

Sinon, les stats annoncée sont en prenant le maximum de traitement sur le serveur, je ne suis pas encore passé en mode décentralisation maximale (l'option est là, mais ca fait peur !).

En décentralisant au maximum j'héberge 200 joueurs avec 1 Mbit/s (pas fantastique, mais c'est un bon début ! ).

Je referais les tests, car ca fait un moment, je monitore tout ça et je te dit
!

[SuperBidi]

Les informations entre les joueurs sont envoyés toutes les 100ms (inutile pour un jeu de poker je te l'accorde).

Juste pour savoir, tu passes par une synchro complète ou par des updates progressifs ?

[Maldus]

Des updates progressifs suivi d'update complet de temps a autres :-)

Un client envoi environ 4-6ko/s. Ce qui créé pour le serveur principal un trafics compris entre 0.1 et 3ko selon les réglages définis.(plus ou moins décentralisé)

Le gain est faible de la manière dont je l'utilise mais il peut devenir important en modifiant les réglages. Je reviendrai avec un petit simulateur montrant l'architecture et le système (quand j'aurais le temps )

[Xanguiz]

Bonjour,
je relance ce sujet fort intéressant, car une question me turlupine.

Je suis en phase d'analyse de conception pour un portage en C# d'une architecture "Maison" pour un serveur type MMO. Et je me demandais s'ils était pertinent d'utiliser le principe de remoting? (RMI en java)

Merci d'avance pour les futures réponses ^^

[SuperBidi]

Tu m'as appris un concept. En fait, je pense qu'il faudrait que tu détailles plus à quel niveau tu comptes gagner du temps. Parce qu'au premier abord, j'ai l'impression que ça sert surtout à remplacer la structure de message. Or, à mes yeux, c'est une partie tellement simple à gérer que j'irai pas chercher midi à quatorze heure. Pour moi, tu risques de perdre du temps plutôt que d'en gagner. Mais comme dit plus haut, faudrait que tu détailles comment tu comptes t'en servir pour que je puisse argumenter plus avant.

[Xanguiz]

Je trouve le remoting très facile à mettre en place, je me suis donc dit que je gagnerais forcément du temps. Mais sans trop y réfléchir pour le moment >_<

Le projet est pour l'instant toujours au stade "cahier des charges" donc rien n'est fixé.

Je pensais donc utiliser le remoting pour la connexion/authentification étant donnée qu'à partir du framework .NET 3 ( ou 3.5 je crois) on peut crypter les données.

Problème pour le moment non traité :
- Aucune idée des ressources consommées par l'encodage/décodage, ni du principe utilisé.

Étant donnée que les informations qui transitent sont sérialisé, je pensais également l'utilisé pour la transition des données entre le MainServer et le/les WorldServeur.

Le plus simple serait que je montre en premier lieu mon architecture général. Je n'ai pour le moment que des schémas sur des bouts de papier. Dès que j'aurais tout mis au claire dans ma tête et avec mes collègues je vous ponds un schéma.

[SuperBidi]

Exécuter un message serveur sur le client, c'est pas bien dur. Ca consiste à le récupérer (ça, c'est à charge de la partie réseau), à décoder le premier short/int qui contient l'id du message, à le désérialiser suivant son id, et à ensuite lancer une méthode qui le prend en paramètre.
Y a un peu de code, mais c'est pas une partie galère et ultra sensible.
Autre avantage, tu utilises le même système pour discuter entre tes différents serveur (vu que tu m'as l'air d'aller vers une archi master server/servers de jeu), ce qui permet d'avoir une belle archi de gestion des messages clients comme serveurs. Et de même, tu peux t'en servir pour des messages internes, au moment ou tu commenceras à multi-threader ton serveur (ce qui risque d'être fort possible avec par exemple le thread bdd).

Par contre, le remoting, ça me paraît pas super. Exemple, le joueur se connecte, tu veux lui envoyer les infos de son personnage, tu utilises le remoting pour appeler une méthode sur l'objet personnage que tu as sur ton serveur ? De un, l'objet personnage côté serveur n'est pas le même que côté client (si tu codes proprement), de deux, tu maîtrises pas les données que tu envoies (et là, gros problème de sécurité/perf). Ou alors, tu sérialises ton personnage comme tu veux et tu lances une méthode sur une sérialisation de ton personnage. Là, ça marche, mais ton remoting commence à se complexifier fortement si tu dois sérialiser tous les objets spécifiquement avant d'appeler une méthode remote, et, surtout, tu retombes sur la même logique que les messages que je t'ai décrite au dessus, donc plus aucun intérêt dans le remoting.

J'ai l'impression que le remoting suppose que le client comme le serveur possèdent peu ou prou la même archi/structure interne/types de données. C'est très très loin de la vérité. En général, y a 25% de code commun, tout le reste de spécifique.

Quant à ta remarque sur le cryptage, perso, je crypte le message de connexion, et je pense que beaucoup de monde fait pareil. L'impact en perf est secondaire à côté du gain de sécurité. Par contre, il ne faut crypter que la connexion, sinon, c'est vraiment trop lourd.

[SuperBidi]

N'arrivant pas à éditer mon message précédent, j'en crée un nouveau.

Donc, après un peu plus de réflexion sur le remoting, je reste sur mon avis, pour quelques raisons supplémentaires. Je vais me baser sur des cas concrets :
1. Tu as un monstre qui se trouve au point X et qui va au point Y. Le serveur envoie le message au client. Le client en le recevant, place le monstre au point Y -> téléportation du monstre. Le client va devoir faire une interpolation linéaire ou quoi que ce soit pour permettre au monstre d'être au point Y. Donc pas possible de faire du remoting dans ce cas là.
2. Tu as un bug complexe du à un enchaînement d'action. Avec une structure de messages, tu as un endroit très bas niveau où logger. En gros, à chaque réception de message, tu logges le type de message, et au prochain crash, tu peux voir l'enchaînement. En remoting, je suppute que tu as beaucoup moins de visibilité sur ce qui se passe, vu que tout est géré par une bibliothèque interne. Je pense que le débugging doit pas en être facilité.
3. Tu veux créer un client de stress test pour voir si ton serveur tient un tant soit peu la charge. Avec une structure de message, tu peux faire en sorte de créer plein d'actions en créant plein de messages. Ca demande un peu de boulot sur chaque message pour permettre de créer des messages de stress fonctionnels, mais ça se fait. En remoting, vu que tu synchronises des objets tous différents, tu dois te taper un code ultra spécifique par objet. Ca prend trop de temps.
4. Tu veux lutter contre le hack. Tu cherches donc à savoir quels input réseau entraînent des crashs de ton application ou des comportements dommageables. Avec des messages, tu fais en sorte d'envoyer du garbage, et tu regardes comment le serveur les désérialisent. Avec du remoting, pas possible.


D'ailleurs, je me permets une parenthèse sur les clients de stress test.
Sur un serveur standard, c'est primordial. Sur un serveur en C++, c'est obligatoire.
C'est peut-être le plus gros truc que je donne dans ce sujet : faites un vrai gros client virtuel, apte à copier tous les comportements joueurs. Ca va vous prendre un mois, ça va vous en faire gagner 6 (ans).
Un client virtuel va vous permettre plusieurs choses :
- Faire des tests de charge (toujours utile).
- Trouver les fuites mémoire (oui oui, même en Java, y en a).
- Lutter contre le hacking en bloquant les messages à contenu incorrect (faire en sorte que le client virtuel envoie du garbage).
- Lutter contre le hacking en corrigeant les problèmes dus à des enchaînements trop rapides de messages (genre la déconnexion en plein échange d'objet avec un délai de l'ordre de la milliseconde entre les deux messages).
- Valider les versions une fois que le serveur est en ligne. Une ou deux heures de stress avec un client virtuel permet au moins de voir si le serveur part pas en vrille.
- Reproduire les bugs à occurrence infime (je reproduis assez aisément les bugs à occurrence 1 sur 1 milliard).
- Ca permet parfois de détecter des problèmes de données (si vous voyez des données erronées en bdd), voire les bugs clients tant qu'ils touchent aux données (vu que les messages peuvent subir une légère exécution sur le client virtuel, au moins la partie désérialisation).
Honnêtement, j'ai bossé sur un serveur avec, j'ai bossé sur un serveur sans. On divise par 10 le temps de débugging sur les bugs complexes.

[Linunix]

Bonjour, je sais que cette discussion est depuis un bon moment terminée .
Cependant, Neo007 j'ai une petite question, pourquoi ne pas faire plusieurs serveurs, pour répartir les taches, équitablement .

Exemple :
Serveur Maitre : qui gère la map
Serveur d'Authentification + BDD : celui-ci se charge de voir, si le joueur peut jouer, et verifie les données envoyés par le client lors de sa connexion, à celle qui est dans la BDD .

Un serveur de Secours, au cas, où le serveur Maître est Down :

Voili, voila, je sais, que c'est une discussion qui n'est pas très récente .
Mais je souhaitais te poser ces questions .
Bonne soirée .