Re: [Jeux libres] Système de mises à jour / G ame update System

[Gabriel Schnoering <gabriel.schnoering AT gmail.com>]

Ce que j'essaye de dire c'est que l'idée à l'air simple.
Une mise en œuvre pratique et cohérente beaucoup plus...

Pour les mmorpgs le souvenir que j'en ai, c'était un serveur ftp/http 
géré par le développeur sur lequel le lanceur du jeu va synchroniser les 
données avant de lancer le dit jeu.
Bien sur si les logiciels sont libres (AGPL ?) n'importe qui peut mettre 
en place son propre serveur avec ses propres données.
Mais a ce moment la cela devient aussi TRES vite le bordel du coté du 
client avec des ressources qui viennent d'un peu partout.
Rien que pour l'exemple des fps, vu les différents mods et chaque 
serveur avec ses fichiers customs et ses petites modifs, le joueur 
accumule rapidement des GO de données juste pour faire plaisir a chaque 
admin de chaque serveur. Je ne trouve pas cette fonctionnalité tellement 
enthousiasmante de cette perspective.

Ensuite pour le cas d'un mmorpg, même les plus connus sortent leurs 
nouveautés majeures (lorsqu'il y a pléthore de nouvelles ressources) 
périodiquement et ça peut tout a fait être découplé des mises à jours 
plus régulières des binaires par exemple.

Le coup du c'est la faute du développeur est bien facile.
En prenant l'exemple de q3, regardons ce que cela implique d'implémenter 
le réseau en supposant la possibilité de télécharger des ressources 
depuis le jeu.

Le jeu a son propre protocole perso avec tout ce que ça implique de 
gestion des adresses et des clients depuis la réception d'un paquet sur 
la socket. Ce protocole doit gérer les requêtes de client voulant se 
connecter mais également les clients déjà connectés et les paquets 
"ingame". 1ere couche.
Le jeu maintient son propre système de fichier au dessus de celui de 
l'OS afin de pouvoir mixer les fichiers sur la partition avec ceux 
chargé depuis les .pk3. 2eme couche à gérer.
De plus pour le téléchargement, on doit autoriser et mettre en place 
l'écriture sur le disque.

Le moteur utilise une machine virtuelle pour "protéger" le client du 
mauvais code des développeurs et des possibles serveurs malicieux qui 
envoient des mods exotiques. Donc une fois le mod téléchargé et copié 
sur le disque à travers le protocole de jeu, il est chargé par le moteur 
qui va lancer le bytecode et potentiellement empêcher l’exécution de 
toute commande non valide.
La encore programmer un bonne VM est DIFFICILE ! Une 3eme couche.
Regardez comme exemple JAVA, ca fait 20 ans qu'ils essayent et les 
failles ne s'arrêtent pas pour autant.

Et comme ces 3 couches ne sont PAS indépendantes, les snapshots du 
serveur doivent arriver jusqu'au code "mod" coté client par exemple.
Ce n'est pour moi clairement pas un gage de sécurité, mais plutôt de 
rajouter beaucoup de code difficile a maintenir.

De plus, la VM ne protège que pour le code directement, pas les 
ressources falsifiés ou l'appel à d'autres fonctions du moteur. Par 
exemple j'envoie un .jpg corrompu, le moteur va bien le charger et je 
peux tout à fait exploiter une faille dans les autres secteurs qui ne 
peuvent être couvert par le VM. (exemple toujours tiré de q3)
La encore l'argument le dev a cas garder son système à jour est valide. 
Encore faut-il que ce ne soit pas 0-day, que le pb soit "vu" etc...

Donc bien sur c'est TOUJOURS de la faute du programmeur. Après peut être 
aussi qu'il faut se poser la question de la validité de certains choix 
techniques et de certains algorithmes. Il y a peut être des développeurs 
géniaux qui savent gérer tout ça facilement, je dis juste que pour moi 
ça reste assez lourd comme mise en œuvre :)

Dans la pratique, keep it simple.
Il y a des fausses bonnes idées, en particulier fortement complexifier 
le code pour une "petite option".

Laisser le client faire un "rsync" avant de lancer son jeu, ou 
l'automatiser via un script, pourquoi pas, mais pas en faisant une sauce 
perso directement "via le jeu".

Et sinon au lieu de télécharger 50000 fichiers, il suffit de les mettre 
dans une archive, c'était l'idée derrière les .pk3 de quake3. Mais la 
encore dans la théorie c'est "beau" que chaque serveur ai son jeu de 
ressources à faire dl aux clients. Dans la pratique, bien souvent les 
joueurs ne vont pas sur 40 serveurs différents régulièrement.
Mais tournent entre les 2 ou 3 favoris.

On 19/05/2012 19:25, alpha_one_x86 wrote:
> La je ne suis pas d'accords pour les jeux de type mmorpg, où
> l'utilisation de multiple serveur avec de multiples ressources est
> possible.
> Cela doit être fait de base dans le protocole pour garantir la
> fraîcheur et l'intégrité des données, ne pas téléchargé à la main 50
> 000 fichiers à chaque connexion et à chaque serveur.
> Après il y as les mauvais protocole, les mauvaises implémentations.
> Dans tout les cas, les failles de sécurité ne sont pas lié à la
> fonctionnalités, mais bien au travail qu'as fait le développeur
> derrière. (Certain ce plante en ne pas échappant les caractères dans
> les requêtes mysql, ce qui ouvre plein de faille dans les truc
> basique).
>
> 2012/5/19 Gabriel Schnoering<gabriel.schnoering AT gmail.com>:
> > De mémoire et historiquement,
> > c'est justement la source d'un certain nombre de failles de sécurités majeures
> > dans les moteurs basés sur quake3.
> > L'implémentation à travers le protocole du jeu est (était ?) une catastrophe,
> > passer par http/ftp est une amélioration mais il n'empêche que de tout miser
> > sur la bonne volonté de la VM (qui a aussi eux sont lot de failles critiques)
> > me semble douteux.
> > Je préfère que le jeu éventuellement informe le joueur de mises à jour
> > disponibles, mais certainement pas les lui imposer, bien que l'idée semble
> > tentante sous motif de "simplicité", de "live" et "dynamicité"
> >
> > Quoi qu'il en soit je trouve qu'un système de live update directement via le
> > jeu, n'est clairement PAS la priorité. Cela peut venir éventuellement une fois
> > le jeu terminé. Je reste sur une approche binaire et archive de ressources.
> > Concrètement, même dans le cas d'un jeu où les joueurs peuvent relativement
> > facilement créer des ressources, comme des cartes pour un fps.
> > Cela n'arrive pas si fréquemment et proposer une archive a télécharger,
> > soit sur le site du serveur personnalité ou alors le proposer au développeur
> > du jeu la version suivante de l'archive "ressources" ne me semble pas
> > contraignant. Beaucoup moi que de se retrouver a télécharger moultes fichiers 
> > a
> > l'insu de son plein gré des qu'on se connecte sur un serveur de jeu par
> > exemple (si le jeu est client/server)
> >
> > Le Friday 18 May 2012 19:00:36, Cacatoes a écrit :
> > > Pour le cas d'ioquake3 et des FPS qui s'appuient dessus, c'est un peu
> > > particulier, car:
> > >
> > > - y'a un moteur
> > > - une machine virtuelle qui tourne sur ce moteur, et qui définit la
> > > logique interne du jeu (règles, éléments du gameplay)
> > > - et les données graphiques et sonores
> > >
> > > Hormis le moteur, tout (y compris d'autres versions de machines
> > > virtuelles) peut être embarqué dans des fichiers .pk3, qui sont des
> > > archives .zip.
> > > Ces pk3 peuvent être téléchargés depuis les serveurs de jeu (si le
> > > client active l'autodownload).
> > > Le téléchargement se fait par UDP (mais est lent tel qu'il a été conçu),
> > > ou par HTTP si l'administrateur a configuré et dispose d'un serveur.
> > >
> > > Résultat: on peut mettre à jour certains éléments par ce biais
> > > (téléchargement de maps, ou même de mods de jeux). Mais effectivement,
> > > avec cette architecture, la sécurité est en question. D'autant qu'il
> > > s'agit ici d'exécuter un bout de logiciel que n'importe quel
> > > administrateur de serveur mal intentionné pourrait mettre en place.
> > > La machine virtuelle tourne dans un environnement chrooté, ce qui
> > > fournit un degré de sécurité, mais qui pourrait être contourné en
> > > faisant charger une DLL, ce que le client refuse de faire si celle-ci
> > > est contenue dans un PK3.
> > > Dans la pratique, je n'ai pas eu vent du fait qu'un tel problème soit
> > > arrivé.
> > >
> > > Infos à prendre avec des pincettes, mais ça vous donne une idée ..
> > >
> > > Le 18/05/2012 17:56, Gabriel Schnoering a écrit :
> > > > Bonjour,
> > > >
> > > > La plupart des jeux que je connais aiment faire leur propre sauce.
> > > > Parfois de manière hybride en utilisant un serveur ftp/http qui tourne
> > > > derrière et le client qui parse un protocole spécial pour gérer les
> > > > ressources.
> > > >
> > > > Néanmoins je suis absolument contre ce genre d'approche, d'expérience la
> > > > plus grande partie des jeux où les clients vont aller télécharger des
> > > > updates soit à un "master" soit les fichiers manquants sur les serveurs
> > > > de jeu etc... suivant la configuration du serveur sur lequel on se
> > > > connecte, sont des véritables passoires à sécurité.
> > > > Les clients sont très souvent exposé a des failles critiques.
> > > >
> > > > De mon point de vue, le plus propre reste de séparer les binaires et les
> > > > ressources. Préparer des archives pour les ressources et par exemple
> > > > faire la mise à jour en passant par le gestionnaire de paquet de
> > > > distribution. Ce n'est pas la peine d'essayer de (re)faire un semblant
> > > > de gestionnaire d'archives en moins bien.