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

[devnewton <devnewton AT bci.im>]

Je ne comprends pas trop ce qu'un protocole spécifique peut faire de 
mieux qu'un rsync?

Sinon j'ai vu la page 
http://pokecraft.first-world.info/wiki/Base_protocol_messages et je 
voulais te demander si tu as envisager d'utiliser un outil comme 
protobuf pour spécifier ton protocole et si oui pourquoi tu y as renoncé?

alpha_one_x86 a écrit :
> 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.
> > > > > >              
> > >
> > >
> > >
> > >        
> >      
>
>
>