Salutation les zéros !

Bon, après m'être intéressé de près aux moyens (bibli socket&pThreads), je me pose des questions sur la méthode.

Je n'ai pas de projet particulier, donc mes exemples sont purement imaginaire.

Etant un la base un devellopeur Web (J'ai commencé la "programmation" par le php) je suis toujours parti du principe qu'il fallait faire confiance le moins possible au visiteur/utilisateur (En devellopement Web ca se traduirait par des vérifications sur les entrées des formulaires).

Je me suis dis que même pour un programme il fallait éviter d'éxecuter trop de calcul (par exemple résolution d'un combat, ou enregistrement des données numériques tel les ressources et caractéristiques) chez le client.

Cela peut paraitre parano, mais un petit malin pourrait (dans un cas extrème je l'accorde) falsifier ce qu'il envoit au serveur.

Ainsi donc, est il nécessaire d'utiliser des clients que j'appellerai "léger" (bien que le terme ne soit peut etre pas approprié), qui ferait uniquement office d'affichage de l'environnement pour le client et de l'envoie des ses ordres (déplacement, productions, etc) qui seraient traités par le serveur et dont le résultat lui serait seulement renvoyé ?

Pour ce qui est de gérer plusieurs clients une fois la technique des threads acquises, on échaffaude rapidement une structure, mais j'ai peur que mon serveur ne soit trop lourd, et qu'avec un nombre trop élèvé de clients, les informations, calculs, et envoie de données se multipliant, je me retrouve avec un serveur, soit en dépassement de mémoires, soit trop ralentit pour assurer une stabilité et un gameplay convenable, ou une bande passante full au point de rendre le serveur timed out. (Bien que, comme je le rapelle je n'ai pas de projet particulier, et quand bien même j'en aurais un, je n'éstimerai pas le nombre de joueur dépassant la 30aine^^)

J'imaginerai bien une solution intermédiaire au client "léger"/serveur omnipotent et au client calculateur/serveur passerelle entre clients uniquement. Mais j'ai bien peur que peu d'informations puissent être suffisament sans risques si elles viennent du client.

Au moins que je ne sois qu'un paranoïaque et que seul un utilisateur sur un milliard ait suffisament de cran pour se permettre de surveiller ses registres processeur, sa mémoire, et ses connexions entrantes/sortantes, de mon programme pour chercher à en tirer profit.

J'entend tellement parler de système anti-cheat, de chasse aux pirates, et autre vices qui sévicent sur le monde du jeux vidéo pour que cela me pose questions.

Ainsi, suis-je un paranoïaque ? ou je ne devrais rééllement pas faire confiance aux clients ?

Si quelques zéros (courageux de lire ce que je viens d'écrire (merci ) ont quelques expériences, idées, à partager à ce sujet, je les en remercie grandement d'avance !

Quand à tous ceux qui pourrait avoir le même genre de questionnement : bienvenue !

Bonne soirée !
Xan

tu peut crypter les connection ou les paquets envoyé avec un systéme de clé public clé privé sa empéche l'injection de paquets tu peut aussi faire un sha ou md5 sur le client pour verifier qui n'est pas modifier faire des verification sur le serveur genre un gars qui gagne 100xp/s ben c'est qu'il triche ou qui gagne 1000xp par monstres dans une zone low lvl enfin ta plein de solution possible pour plus ou moin protéger ton jeux mais je pence pas que gére tout les calcul par le serveur est une solution

Hmmm 30 joueurs ca me semble pas mal du tout, surtout que tu nous cacher quelle était la pattate de ton serveur.

D'un point de vue purement théorique je vois 3 choses a faire pour améliorer les performances d'un jeu en ligne :

- Simplifier les règles :
Disons que nous avons 30 joueurs qui se donnent des coups d'épées faisant "(Force + Agilité / 2) * Bonus temporaire - (EnduranceEnnemi + AgilitéEnnemi * 3)" en oubliant les calculs d'esquive, parade résistance et compagnie.
Ca sera toujorus plus lourd qu'un bon vieu "Force - Endurance" tout aussi efficace =)
L'exemple est extrème, mais il y a toujours moyen de trouver un petit truc à optimiser.

- Trouver la balance taches du client / anti-cheat :
Pour ce qui est du client lourd tu es loin d'être paranoïaque, je n'ai jamais vu un seul jeu en réseau sur lequel il n'y avait pas de cheat fait par des gars qui ont visiblement passer leurs nuits à analyser des trames
Après il faut se dire que tout ce qu'on délèguera comme taches au client, ça coutera au serveur sous forme d'anti-cheat. Il faut voir s'il n'y a pas moyen de perdre moins de temps à vérifier que les joueurs ne courent pas trop vite plutôt que de leur imposer en continue une vitesse de course.

- Load-Balancer :
Je m'était poser le même genre de question sur la capacité des MMO à supporter la charge des milliers de joueurs connectés et j'avais tapper une phrase magique chez google, j'en ai apprit pas mal en tombant sur une entreprise qui vendait sa technologie de clients/serveurs MMO.
Tout n'était que load-balancer (nb: serveur frontal servant a à répartir la charge entre une batterie de serveurs), le gros de la technologie consistait donc à faire changer continuellement le joueur de serveur de manière totalement transparente.
Ainsi il devient je suppose plus facile d'augmenter la capacité "DU serveur" en rajoutant un petit rack en cas de besoin.

En espérant t'avoir lancer sur de nouvelles pistes de réflexions,
et en espérant avoir pauser de nouvelles bases pour mes propres réflexions.

Tout d'abord merci beaucoup à vous deux d'avoir répondu si rapiement !

Citation : prsieux

tu peut crypter les connection ou les paquets envoyé avec un systéme de clé public clé privé sa empéche l'injection de paquets tu peut aussi faire un sha ou md5 sur le client pour verifier qui n'est pas modifier faire des verification sur le serveur genre un gars qui gagne 100xp/s ben c'est qu'il triche ou qui gagne 1000xp par monstres dans une zone low lvl enfin ta plein de solution possible pour plus ou moin protéger ton jeux mais je pence pas que gére tout les calcul par le serveur est une solution

-L'encapsulation des paquets transmis une bonne idée a laquelle je n'avais pas pensé en effet !
-Le hash de l'executable est une bonne idée, mais j'ai le sentiments qu'il serait facile de créer une programme qui enverrait un faux-hash... bon évidement avec une encapsulation des données il devient plus difficile de déviner qu'il faut en envoyer un !
-Quand à la vérification sur le déroulement normal du jeu, et bien pour un MMORPG ca me semble correcte, mais si j'avais voulu faire un FPS ? bon bien sur j'aurais surement d'autre logs possibles.

Quoi qu'il en soit, encore merci

Citation : Inki

Hmmm 30 joueurs ca me semble pas mal du tout, surtout que tu nous cacher quelle était la pattate de ton serveur.

Car, n'ayant pas de projet, je n'ai pas non plus de serveur attitré ! Il n'y a guère que mon propres pc qui sert a tester mes vagues essais sur le sujet, et encore !

Citation : Inki

- Simplifier les règles :
Disons que nous avons 30 joueurs qui se donnent des coups d'épées faisant "(Force + Agilité / 2) * Bonus temporaire - (EnduranceEnnemi + AgilitéEnnemi * 3)" en oubliant les calculs d'esquive, parade résistance et compagnie.
Ca sera toujorus plus lourd qu'un bon vieu "Force - Endurance" tout aussi efficace =)
L'exemple est extrème, mais il y a toujours moyen de trouver un petit truc à optimiser.

Moui et m'non : Si le but du jeu est justement de faire intervenir pleins de facteurs pour créer un simulacre de réalisme ?
Et tout simplement : Ces calculs (dans le cas d'un combat entre deux joueurs semble-t-il), je les execute ou au final ? Client 1 ? Client 2 ? serveur ?

Citation : Inki

- Trouver la balance taches du client / anti-cheat :
Pour ce qui est du client lourd tu es loin d'être paranoïaque, je n'ai jamais vu un seul jeu en réseau sur lequel il n'y avait pas de cheat fait par des gars qui ont visiblement passer leurs nuits à analyser des trames
Après il faut se dire que tout ce qu'on délèguera comme taches au client, ça coutera au serveur sous forme d'anti-cheat. Il faut voir s'il n'y a pas moyen de perdre moins de temps à vérifier que les joueurs ne courent pas trop vite plutôt que de leur imposer en continue une vitesse de course.

Longue reflexion en prévision...

Citation : Inki

- Load-Balancer :
Je m'était poser le même genre de question sur la capacité des MMO à supporter la charge des milliers de joueurs connectés et j'avais tapper une phrase magique chez google, j'en ai apprit pas mal en tombant sur une entreprise qui vendait sa technologie de clients/serveurs MMO.
Tout n'était que load-balancer (nb: serveur frontal servant a à répartir la charge entre une batterie de serveurs), le gros de la technologie consistait donc à faire changer continuellement le joueur de serveur de manière totalement transparente.
Ainsi il devient je suppose plus facile d'augmenter la capacité "DU serveur" en rajoutant un petit rack en cas de besoin.

(même si j'en avais déjà conscience je te remercie de me rafraichire la mémoire ^^)
Evidement tu décris un système qui se donne les moyens, mais j'ai souvenir que pour un jeu tel CounterStrike (par exemple), qui est capable d'accepter jusqu'a près de 32 ( 64 peut etre même ?) joueurs on arrive tout de même à des qualités de jeu optimale, avec un serveur parfois juste hebergé chez un particulier, qui plus est, joue en même temps !

De plus, certain jeu de stratégie acceptent plusieur joueurs, et pour chaque joueurs acceptent près de 2000 unités si mes souvenirs sont bons (je pense à Cossaks, ha quel époque !).
Encore une fois le serveur est hebergé chez un joueur !

Citation : Inki

En espérant t'avoir lancer sur de nouvelles pistes de réflexions,
et en espérant avoir pauser de nouvelles bases pour mes propres réflexions.

Bien sur, et je t'en remercie, et j'en espère autant pour toi

Je peux te proposer une piste de réflection. Ce n'est pas une idée aboutie, donc si ca se trouve c'est a chier mais voila le principe:

Au lieu d'avoir une architecture classique:
Le client décrit des actions au serveur
Le serveur recoit toutes les actions des clients et met à jour l'univers en résolvant les actions
Le serveur envoie a chaque client leur morceau d'univers perceptible.

Tu pourais très bien regrouper les clients en zones, et chaque client recoit les info des clients qui sont dans son univers perceptible et les intègre.
Pour éviter la tricherie tu peux t'arranger pour résoudre des morceaux d'univers chez plusieurs clients. Evidement si il y a un tricheur, sa résolution va changer.

Voila ce qu'il se passe:
Je calcule un morceau de l'univers je trouve A
Bob calcule le même morceau et trouve B

comme je ne trouve pas comme bob, j'envoie aux autres joueurs dans la zone : Bob est un tricheur dans ma zone.
Bob va envoyer : LeDemon est un tricheur dans ma zone.
Mais comme les autres joueurs sont honètes, ils vont eux aussi calculer le résultat dans la zone et trouver A,
Ils vont donc en conclure : Ahh c'est Bob le tricheur et vont le buter.

Formellement tu dois :
- répartir ton univers en zones.
- si il n'y a pas beaucoup de jouer par zones, c'est le serveur (fiable) qui la gère
- si il y a plein de joueurs tu peux faire confience a la majorité:
- chaque joueur calcule sa résolution de zone en local et la compare de temps en temps avec celle des autres.
- Si c'est pareil : on fait rien,
- si c'est différent on accuse celui qui a produit une résolution différente de tricher.
- Si on reçoit une suspicion de triche d'un joueur on vérifie ce qu'il a calculé et
- si on ne trouve pas pareil, on le marque comme tricheur, et on le bannie.
- Si on trouve pareil, on laisse tomber l'accusation.

Ainsi un type qui triche va se faire griller par tout le réseau.

Bonsoir.

C'est marrant, parce qu'en écrivant mon dernier post j'ai plus ou moins (surement "moins" que "plus") penser a un tel système, et pendant cette journée, j'y ai un peu reflechit : l'idée que les clients se répartissent les calculs (en fonction de leur capacité/puissance peut etre ?), en partant d'une idée type "wiki" ^^.

Mais je ne suis pas arrivé à une reflexion aussi aboutit (N'ayant principalement pas envisagé de système de "zones").

Cette architecture demanderai surement plus de boulot qu'une architecture plus classique, mais j'aimerai la qualifier de "Web 2.0". Mais ce type de structure n'existe-t-elle pas déjà ? M'étonnerais que des génies ne l'ai pas déjà mis en oeuvre ou qu'il n'existe pas d'essai à ce sujet... ?

Après, j'ai l'impression que cela demanderait peut etre plus en bande passante/vitesse de connection, les envoie se multipliant en cas de suspicion. bien que cela soit surement optimisable.

Malgré tout, je me pose encore la question du stockage des informations (en dehors d'une base de données pour le stockage d'un personnage non connecté (pour un jeu de type MMORPG (Cf deux paragraphe plus loin)).

Bon, je me permet une petite reflexion :
A la connexion d'un client, ses données sont récupérées d'une base de donnée, devrait on les lui envoyer ? ou les envoyer à ceux de la même zone ? ou les deux ?
Dans le premier cas il est le seul détenteur (hormis la BdD qu'on évitera de contacter (trop lent/trop de ressources ?)) de ses propres informations, et pourrait être à même de les modifier.
Dans le deuxième cas, en dehors du risque qu'un autre utilisateur modifie les données à la baisse d'un autre joueur, le risque majeur est la disparition des ces joueurs (déconnexion brutale aucunes mesures de récupération n'est possible) et la perte des informations de l'interessé.
Le dernier cas pourrait être le plus envisageable, mais s'il est le seul ?
Bon bien sur ce n'est qu'une première reflexion, et ces questions n'ont pas nécessairement besoin de réponses, bien que si certains sont interessés, je les y invite avec joie.

Quoi qu'il en soit, elle me semble plus particuliérement adapté à un jeu de type MMORPG (le concepte de zones, peut etre ?).
Mais dans un jeu plutot FPS ou de stratégie il n'y a pas rééllement de "zones" possible (Quoi que la map puissent être comparé à une zone unique et global), cette solution pourrait elle être adaptable ET viable ?

En tout cas, je tire mon chapeau pour cette belle idée !

Je me permet de faire un appel à témoins à tous ceux qui ont de l'expérience dans le domaine réseau (particulièrement de type jeu, ou pas en fait ! :p), mais aussi à tous ceux friant de reflexion abstraite et d'algorithmie (Non ! Ne fuyez pas devant ce mot qui agace plus d'un étudiant en informatique ^^). En pur profane je me permet d'ouvrir le débat !

Merci encore.

Bon, je me permet une petite reflexion :
A la connexion d'un client, ses données sont récupérées d'une base de donnée, devrait on les lui envoyer ? ou les envoyer à ceux de la même zone ? ou les deux ?

Le client a une copie statique de tout ce qui est statique dans ton univers (les décors fixes, les ressources ...) Ca la base de donnée ne lui envoie pas, sauf éventuelement sous forme de patch une fois que tu change ton univers.

Ce que le client doit recevoir c'est :
- 1) les données dynamiques qui le concenrnent directement (ou il est positioné, ou afficher un monstre)
- 2) les demandes de calculs dynamiques (résoudre des actions par exemple).

Ce que le client doit envoyer c'est:
- 4) ses actions (je bouge ici, j'attaque ca)
- 5) le resultat de calculs.


> Dans le premier cas il est le seul détenteur (hormis la BdD qu'on évitera de contacter (trop lent/trop de ressources ?)) de ses propres informations, et pourrait être à même de les modifier.

L'utilisateur peut modifier ce qui est chez lui:
- 1) Le client peut modifier sa vision de l'univers, ca c'est son problème s'il a envie d'afficher l'arbre là ou il ne se troue pas, libre à lui.
- 2) Les calculs, là s'il triche c'est un problème, faut distribuer ces calculs aec redondence pour éviter les tricheries.

-4) Le client recoit des ordres, il doivent être vu comme des tentatives, il faut les verrifier (exemple : je bouge de paris à marseille à pied --> ordre invalide).
-5) Le resultat de calculs : s'il est validé par beaucoup d'autres clients il est OK et on ne refait aps les calculs, s'il y a suspicion on refait les calculs pour identifier les tricheurs.

Dans ce système les stats du joueur j sont stockées:
- chez lui
- sur le serveur (en sauvegarde)
- chez d'autres clients

S'il les modifie illégalement chez lui, il va perdre la cohérence avec les autres clients et être accusé de tricherie.


> le risque majeur est la disparition des ces joueurs (déconnexion brutale aucunes mesures de récupération n'est possible)

Ca c'est un problème.
Dans se cas, on peut switcher sur le serveur mais c apose de gros problèmes de synchronisation. On peut même penser qu'un joueur malveillant peut pinger a donf un joueur qui l'accuse de tricherie.

Peut être qu'un système de mise à jour 1x par minute du serveur est un bon compromis,


ZONE:
Tu peux définir une zone comme un ensemble de l'univers ou les joueurs sont en interraction. En FPS par exemple une zone peut être simplement un endroit dans lequel il y a un joueur qui voit un joueur qui est vu par un joueur qui est aà coté d'un joueur qui est à porté de tir de ...

Les joueurs qui se situent dans des endroits ou il n'y a pas de chaine de "je te vois/je suis vu/je suis proche/je suis a porté de tir" ne sont pas dans la même zone

Ensuite je ne suis pas du tout expert des réseaux, donc les autres idées sont les bienvenues aussi.

bonsoir !

J'ai quelques peu réflechi sur des questions plus "pratique-programmation" :
*Si on peut gagner en mémoire pour le serveur, ne perdrait on pas en bande passante/vitesse de connexion ?
L'envoie d'un bloc de données à plusieurs clients, et ceci pour chaque client qui se connecte, me parait un peu gourmande en temps processeur, et en connexion, non ?

*Quand au calcul, n'est il pas plus rapide pour le serveur de le résourdre lui même et d'être sûr arbitrairement de sa valeur, plutot que de transmettre plusieurs fois le calcul, recevoir plusieurs résultats, les comparer, dans le cas ou tout est bon : accepter; et dans le cas ou il y aurait une erreur, refaire des vérifications (soit lui même, soit en ré-envoyant les instructions), et mettre en place au final un système de "ban" du joueur ?

*Je me suis aussi laissé dire, que déclarer un joueur comme ayant une information incorrecte est un tricheur à bannir me paraissait un peu dur. Selon différentes architectures matériel et/ou système d'exploitation, ne serait il pas possible que le résultat d'un arondi mathématique puisse différé d'un dixième, centième, millième, et créer une erreur involontaire ?
Ou bien même, n'ayant aucunement triché, il possède une série de données obsolètes ? Tout simplement parce qu'un joueur à gagner un niveau (si c'était un RPG), vient de récupèrer une autre arme (si c'est un FPS), etc, il aurait en toute innocence commis une erreur de calcul.
[Edit, et pas des moindres : Qqs minutes plus tard] : J'ajouterai qu'en dehors d'incertitudes de calculs, il est souvent de bon ton de rajouter une composante variable lors de la résolution d'un combat, ceci dans le but d'ajouter un facteur chance(parfois dis réalisme, tu parle je perd toujours a cause de ça). Donc là, le calcul de cette composante rendrait chaque résultat sensiblement différents, et nécessiterait une autorité : le serveur. On y perd un peu de l'interêt des divers clients-calculateurs des résulats ! :/

*Bon, je répond plus moins à mon propre dernier paragraphe en faisant un parallèle avec le réseau de terrain CAN (que j'ai pu étudier en cours) :
Sur CAN, les différents modules émettent toute sorte de trames sur une même connectique, chacun ayant une priorité qui lui donne l'avantage sur les autres (on parle de bits dominants, et de bits récessifs). Et il arrive que certains modules, pour diverses raisons (souvent une erreur et non une faute), émettent des trames érronés et polluent les communications (principalement lorsqu'il s'agit de trames d'alertes souvent très prioritaires alors qu'il n'y a pas raison d'être).
Dans ce cas, le controleur du bus a la possibilité de... le "punir", voir de lui interdire de communiquer s'il commet trop d'erreurs à la suite (et parce qu'il est pas méchant le controleur, au bout d'un moment il lui redonne la parole ^^). On utilise donc un nombre qui identifiera sa fiabilité :
- 0 => c'est parfait, pas d'erreur, normalement fiable
- chaque mauvaise trame lui ajoute +2 (ou +4,+x selon les envies du programmeur)
- chaque bonne trame lui retire -1 (ou -x)
- Et une fois arrivé à la limite (fixé a 254 si je me rapel bien de mes cours), il est interdit d'émission.

Et bien, de même pour notre cas (intervalles, et modificateur à définir selon les besoins), sauf qu'une fois à la limitte -> eject ! (Voir ban ^^)

*Maintenant, d'un coté plus théorique, si le serveur ne possède les informations des joueurs qu'en sauvegarde (donc on évite d'y accèder), lorsque le client rafraichit son écran de vision (Action normalement courante le refresh), à qui va-t-il demander (outre le terrain et décors statique qu'on acceptera de charger en mémoire du serveur) les informations sur les joueurs qu'il peut voir ? Soit tout les joueurs possèdent les informations de tout les autres joueurs, ce qui me ramène à mon premier point sur la connexion, mais me fait rajouter que dans ce cas là il serait trop facile de construire un "wall hack" en cherchant à récuperer les informations des autres joueurs qu'on possède déjà chez soi; soit seul une partie des joueurs possèdent les informations des autres, et dans ce cas, comment intérroger les bonnes personnes qui possèdent les bonnes informations ? on aurait ainsi le risque qu'un client ne puisse virtuellement pas voir des joueurs, tout simplement parce qu'il ne sait pas ou trouver leurs informations !

Si je peux me permettre de remettre mon grain de sel dans ces théories :

J'ai eu une nouvelle idée neuve en pensant aux joueurs et à leur capacité a repérer les fraudeurs.

Regardons les cas Counter Strike, GunZ et tous ces jeux qui se jouent sur une petite map et où les joueurs génèrent un tas d'actions (ne serait-ce que bouger la souris suffit a tourner le personnage et à devoir prévenir les autres), Dans ces jeux il existe toujours des centaines d'exploits pour tricher parfaitement fonctionnels.

D'où l'idée qu'on puisse laisser les joueurs tricher mais ajouter un système de kick/ban par vote, le tricheur finira par avoir du mal a trouver des compagnons pour jouer sauf s'il joue avec d'autres tricheurs, alors il ne sera pas banni automatiquement, ce qui me semble normal.

De plus on peux ajouter des systèmes communautaires de clans/guildes ou autre groupements de joueurs qui se connaissent. Les joueurs aiment jouer avec des gens qu'ils connaissent et en plus ca réduit les risques de tomber sur un tricheur.

Par contre avec ce système là il me parait difficile de réaliser un monde persistant pour deux grandes raisons :
- Monde persistant = une grande map pour tous = impossible d'échapper à un tricheur qui nous en veut particulièrement.
- Un monde persistant est souvent accompagné par une évolution possible des joueurs, hors dans ce cas impossible de vérifier que le joueur n'as pas tricher pour évoluer son personnage plus rapidement.

L'avantage flagrant est que le serveur n'as plus grand chose à faire, il doit juste gérer la connexion des joueurs et les aider a trouver une partie, ensuite tout se ferra en peer to peer, ça ne doit pas être beaucoup plus lourd qu'un serveur IRC.

C'était l'idée du jour, présentée par Inki.