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

[Cacatoes <un.cacatoes AT gmail.com>]

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.