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

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

Rsync est un protocole complexe, l'implémentation windows ne marche
que via cygwin, ... aprés je voulais aussi garder le faite le le
serveur puisse pusher des fichiers dynamiquement et ne pas ouvrir un
port pour le rsync et un pour mon protocole, ni multiplexer les
données.

Je connaissait pas protobuf, mais ça pose peu être des problèmes,
notamment pour la minimisation de la bande passante et de la
compression (je doit pouvoir transmettre mes 3 octets pour envoyé mes
déplacements).
En plus de ça, Qt dispose de sont propre système de sérialisation. Et
rajouter des lib/entête à rallonge à un truc qui marche... le seul
truc à déploré dans qt, c'est que j'ai du coder à la main un contrôle
des chaines de caractères.


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



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