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

[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.