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

[alpha_one_x86 <alpha_one_x86 AT first-world.info>]

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.



-- 
alpha_one_x86 <alpha_one_x86 AT first-world.info>
Main developer of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department