Programmabilité (hum) d'un logiciel en réseau Open Source

Pause Café
#1

Plop,

Je me suis posé une question qui me turlupine. Je prends l’exemple d’un jeu qui se joue en réseau (style CS). Comment programmer ça en Open Source ? Le problème est que si le serveur envoie au client la position des personnages, y compris ceux cachés par un mur, il y aura toujours un petit malin pour modifier le client et programmer des murs translucides pour voir les ennemis cachés…
On peut donc donner ce boulot au serveur, qui n’enverrai au client que les personnages visibles. Mais la charge de travail pour le serveur sera dans ce cas assez ignoble.

Ceci n’est bien sûr qu’un exemple. Mais tout programme travaillant en réseau, et ne devant informer l’utilisateur que d’une seule partie des infos présentes sur le serveur présente le même problème. Ma question était donc de savoir si la meilleure programmation dans ces conditions était de donner tout le travail au serveur, ou s’il existait un autre moyen de contourner le problème.

#2

Tu retrouves le même problème que les clients P2P, les clients opensource permettent à certains de ne faire que télécharger sans partager…

#3

Faire cracher ses trippes à un pauvre petit serveur juste pour jouer?!? :open_mouth: … Vous n’y pensez pas j’espère!!! (quoique… :unamused: :005 :unamused: )

Il faut vérifier (entre autre) l’intégrité du client… Il me semble que le système “PunkBuster” se base (en partie) là dessus (cf: evenbalance.com/ )…
Après, rien n’empêche un petit malin de détourner (en aval ou en amon…) les données… et/ou de rajouter ses scripts “perso” (sur certains serveurs ça peut être considéré comme de la triche, sur d’autres non… :unamused: )

À mon humble avis, la (seule?) “vraie” solution (celle qui limiterait les “risques” au maximum…), c’est de faire faire tout le boulot au serveur (le pauvre :119 )… [size=50](mais rien n’empêche d’utiliser un “deuxième” joueur en spectateur, par exemple…)[/size]

Ou alors, tous jouer dans un hangar, avec des gardes dans le dos pour vérifier que personne ne triche!!! :005 :005 :005

Aller… zou… :006

#4

fran.b > C’est un exemple auquel je n’avais pas pensé. Y’a-t-il des tentatives pour contrer ce genre de détournement ?

[quote=“Num’s”]Il faut vérifier (entre autre) l’intégrité du client… Il me semble que le système “PunkBuster” se base (en partie) là dessus (cf: evenbalance.com/ )…
Après, rien n’empêche un petit malin de détourner (en aval ou en amon…) les données… et/ou de rajouter ses scripts “perso” (sur certains serveurs ça peut être considéré comme de la triche, sur d’autres non… :unamused: )[/quote]
Voire même de bidouiller la partie qui vérifie l’intégrité du client, si cette partie est Open Source.

Ce style de triche me gêne moins, puisque le joueur ne détourne à aucune moment le client de son but initial. (Et pourtant, un logiciel libre doit pouvoir être exécuter dans n’importe quel but…)

Ouais, mais les gardes, il faut les payer…

#5

J’avoue ne pas savoir grand chose de tout ça. Il faut une certaines autonomie aux clients à fin d’une part de ne pas surcharger le serveur d’autre part ne pas surcharger le réseau. Signer les binaires reviens à ne pas faire de logiciel libre (en fait tu n’a pas d’interopérabilité entre un fork de ton client et ton serveur).

C’est pour cela que les projet comme BOINC ou Folding@Home ne distribuent pas leur client sous licence libre.

Je vais essayer de voir s’il n’y a pas un motif de conception pour ça. Sinon il faut se tourner vers les intergiciel, la science du travail distribué.

#6

Bonjour,

En fait, c’est tout simplement parce que c’est pas le rôle du client de dire sa position aux autres, son rôle consiste simplement à signaler les actions de l’utilisateur au serveur et de s’occuper de l’intéraction avec l’utilisateur (affichage graphique, jouer des sons, etc.).
La sécurité de l’information réside dans le protocole de communication établit entre le client et le serveur, le client indique qu’il “avance”, le serveur met donc à jour la position du joueur XYZ et notifie sa nouvelle position, les autres joueurs verront donc ce joueur à la position que LE SERVEUR donne et non que le CLIENT donne.
Donc, peu importe qu’on modifie le client pour que notre joueur soit à des positions différente, les autres joueurs le verront à la position que le serveur dira.

#7

Peut être mais ça ne répond pas à la question posée.

Tu limite complètement les données accessibles par tes clients ? Donc à chaque action le serveur reçois N notifications (N étant le nombre de client connectés) doit effectuer le calcul de “qui voit qui ?” et envoyer N notifications (une à chaque client). Si tu limite tant que ça les données accessibles par les clients tu va devoir répéter cela combien de fois par seconde ?

C’est peut être possible mais il faut, je pense, de lourdes optimisations pour ne pas reeffectuer le calcul entre deux unités si on peu savoir que pendant x temps ils ne pourront pas se voir et être capable “d’intensifier” le trafic dès lors qu’ils se voient.

Même avec ça je ne suis pas sur que l’ADSL apprécie.

Et ça ne résous pas les problèmes de BOINC ou du P2P.

#8

Je ne comprends pas ce qui est limité ?

Pour les N notifications, c’est du côté serveur que ça se passe, tu n’envoies pas forcément N notifications, car pas tout le monde est intéressé par l’information (hors du champs de vue ou autres contraintes). Justement, on ne limite pas les données accessibles par les clients, on fait juste respecter un protocole de communication. Si un joueur veut avancer, il indique l’ordre au serveur, et le serveur lui notifie sa nouvelle position.

Bof, on peut très bien imaginer que le serveur connaissent les zones de visibilité de chaque joueur, et quand un joueur change de position, le serveur notifie tous les joueurs qui se trouvent dans son champs de vision.

Faut poser les contraintes dès le début, sans ça, impossible de décider.

Je connais pas BOINC, par contre pour le P2P, j’aimerais avoir plus de détails, car je pense avoir mal compris, que je sache, il existe bien des clients libre/open source de P2P.

#9

Gabriel > C’est justement ce que j’appelle “donner tout le boulot au serveur”. Pas forcément idéal pour avoir un jeu fluide :stuck_out_tongue:
Des clients P2P Open Source existent bel et bien, et Fran.b disait qu’il existe (et non pas qu’il pourrait exister) des clients qui ne font que télécharger, sans partager.

MisterFreez > Signer le binaire détruit en effet la liberté du logiciel. Mais vérifier son intégrité grâce à un programme externe ne fait que limiter l’accès à un serveur, et laisse toute liberté sur le logiciel lui-même. (Mais c’est quand même c** de devoir faire un programme à code fermé pour s’assurer que des petits malins ne fassent pas un mauvais usage du programme open source…)

#10

Je ne comprends pas ce qui est limité ?

Pour les N notifications, c’est du côté serveur que ça se passe, tu n’envoies pas forcément N notifications, car pas tout le monde est intéressé par l’information (hors du champs de vue ou autres contraintes). Justement, on ne limite pas les données accessibles par les clients, on fait juste respecter un protocole de communication. Si un joueur veut avancer, il indique l’ordre au serveur, et le serveur lui notifie sa nouvelle position.[/quote]
Le client ne connait pas la position de tout les joueurs c’est la limite dont je parlais (ne pas avoir d’apriori négative sur le mot “limite”).

Ton ébauche de protocole marche très bien pour des jeux simples. Je l’ai utilisé pas mal de fois sans problème. Pour un jeu temps réelle comme un FPS c’est extrêmement lourd. Soit tu impose une granularité (“un pas du joueur correspond à 1m”) et là ça peu être gênant pour le joueur soit tu as un cycle requète réponse 24 fois par secondes si possible à temps fixe et cela pour chaque client (il faut aussi prendre en compte les autres traitements que doit effectuer le client au moins pour créer le rendu après la réponse du serveur. Je choisi 24 fois par secondes car c’est le seuil de fluidité.

Bof, on peut très bien imaginer que le serveur connaissent les zones de visibilité de chaque joueur, et quand un joueur change de position, le serveur notifie tous les joueurs qui se trouvent dans son champs de vision.[/quote]
Riche idée :wink:

Je connais pas BOINC, par contre pour le P2P, j’aimerais avoir plus de détails, car je pense avoir mal compris, que je sache, il existe bien des clients libre/open source de P2P.[/quote]
BOINC ou Folding@Home sont des grilles de calculs. Tu installe un client sur ta machine qui va effectuer des calculs pour la recherche pendant que tu utilise peu ton processeur. Une fois la tâche effectuée, le client envoie le résultat. Je crois que ni l’un ni l’autre des deux projet utilisent de client libre. Avec un client libre il pourrait être modifié pour envoyer de faux résultats.

Pour le P2P il existe des clients qui ne respectent pas les conventions (pas d’envoie juste de la réception). Ce n’est pas du aux clients libres mais aux spécifications des algorithmes qui sont publiques.

#11

[quote]Gabriel > C’est justement ce que j’appelle “donner tout le boulot au serveur”. Pas forcément idéal pour avoir un jeu fluide :stuck_out_tongue:
Des clients P2P Open Source existent bel et bien, et Fran.b disait qu’il existe (et non pas qu’il pourrait exister) des clients qui ne font que télécharger, sans partager.[/quote]

Ok, je comprends, mais pour moi c’est different, j’évite juste de donner le boulot au client que devrait faire le serveur. C’est bien ici que réside la difficulté de réaliser un jeu en réseau pour moi.
Bon, il est vrai que j’ai parlé que du système de positionnement, qui pour moi est largement surmontable et optimisable. Après, il y a aussi les autres actions (attaquer, parler, etc.), mais le principe reste le même, le gros du travail reste du côté du client (rendu graphique, jouer des sons, etc.) mais la partie mise à jours des données, vérifications des positions des objets, etc. doit être faites par le serveur, pour la fluidité, je trouve pas ça génant pour 30-40 joueurs, si le serveur est bien développé et bien pensé. Après, si c’est codé par des porcs (ce qui est souvent le cas), je ne peux être que d’accord, par exemple, si à chaque message, il répond à tout le monde …

Ah si, quand tu te connectes, tu as la position de TOUS les joueurs, ce que je dis, c’est juste que quand quelqu’un bouge, il est inutile d’avertir quelqu’un qui ne te voit pas.

[quote]
Ton ébauche de protocole marche très bien pour des jeux simples. Je l’ai utilisé pas mal de fois sans problème. Pour un jeu temps réelle comme un FPS c’est extrêmement lourd. Soit tu impose une granularité (“un pas du joueur correspond à 1m”) et là ça peu être gênant pour le joueur soit tu as un cycle requète réponse 24 fois par secondes si possible à temps fixe et cela pour chaque client (il faut aussi prendre en compte les autres traitements que doit effectuer le client au moins pour créer le rendu après la réponse du serveur. Je choisi 24 fois par secondes car c’est le seuil de fluidité.[/quote]

Oui voilà, après pour des jeux ou le nombre de joueurs évoluent, il faut réfléchir différemment, surtout par rapport aux messages qui transiteront afin de limiter les notifications des joueurs (ne pas notifier des joueurs qui ne sont pas concerné). Mais pour moi, clairement, c’est le serveur qui doit travailler (en même temps, il est payé pour ça :)).

#12

Nous sommes donc d’accord sur la différence du travail que doit exécuter le serveur, et celui qui incombe au client. Mais malheureusement, la répartition du travail n’est pas équitable…

#13

Qu’est-ce qui n’est pas libre chez le client BOINC ? C’est dans les dépôts free de Debian et il me semblait que c’était sous licence GNU LGPL. Après, les projets utilisant BOINC ne sont peut-être pas forcément libre, mais le premier et plus connu SETI@home semblerait être sous licence GPL.

#14

Je parlais de mémoire. Peut être que ça a changé ou que c’est un projet dont le nom m’échappe.
Peut vérifient ils la véracité des résultats en effectuant des recoupements mais ça ne marche que tant qu’il n’y a pas beaucoup de clients “pirates”.

Sinon je vois pas comment ils font.