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

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

Après je ne part pas des mêmes principes, c'est donc surement un
différence de point de vue.
Une gas qui vas sur des milliers de map, avec des milliers de skins vu
différent accumulera forcement des ressources, lui faire téléchargé
pour qu'il ai le contrôle du contenu est mal vu car contraignant coté
joueur. Je pense à half-life 1, au quel j'ai beaucoup joué (je me vois
pas dl les ressources et map à la main).

Ensuite je par du principe pour mon mmorpg que:
1) Le datapack est en lecture seule, les données éditables (db), sont
une chose à part, si une mod doit existé, les spécificités doivent
étre fait proprement dans le protocole (chat en couleur, nouveau
perso, ...)
2) Rien n'est uploadable (peu étre par la suite, en admin), pas de
script uploadable (si non il faut comme tu as dit, une bonne VM pour
l'isolation)
3) Pas de lecture dans les fichiers (les fichiers sont transmit tel
qu'il sont dans le datapack)
Et justement coté sécurité, il vaut mieux avoir un port d'ouvert avec
un services pour le transfer des fichiers, que plusieurs port avec
plusieurs services (http/ftp). Et tout faire via sont protocole permet
une gestion fine, avec un controle en event pour notifié d'un upload.
(Pas de polling).

Je part aussi d'un serveur légé en binaire, ça veux dire hoster
individuellement dans mon cas sur de petite machine (kimsufi) ou de la
virtualisation (para-virtualisation ou isolation type vserver).
Par contre je suis assez d'accords avec toi en général, d’après les
points de tu dit sur qake3, mais pour moi, ça ce résume à un problème
de conception générale, des gas qui ont voulut tout personnalisable à
l’arrache via des mod, au lieu de bien définir ce qui serai
personnalisable et le faire dans le protocole.

Pour rebondir sur les images, ne pas les chargés pour vérifié qu'il
sont dans le bon format avant d'accepté l'image, c'est un problème
d'implémentation. Il y as la même merde sur les uploads des sites.

Après tu peu jeter un coup d'oeuil sur mon protocole, il est
relativement simple, mais ça part des conditions cité plus haut.
Pas compris:
> 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".

Pas les fichiers à dl, je suis d'accords, la plus part ont leur
serveur favoris, mais c'est comme les sites web et le cache du
navigateur, ... la responsabilité est au client de chargé/supprimé les
ressources trop veille non utilisé.
Dans mon cas, ça ne me gène pas de transmettre 50 000 fichiers, (ayant
fait ultracopier je sais de quoi je parle), coté serveur c'est le
cache FS qui vas tourner et aussi le inode cache, slab_cache pour
linux), et coté transmission, c'est l'une des raisons pour la quel la
compression de la communication tcp est indispensable selon moi. Dans
mon protocoles, ça ce résume à de la lecture pour la majorité des
accès disque.

2012/5/19 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.
>>
>>
>>
>>
>



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