Discussion :

[SuperBidi]

Bonjour.
Je n'ouvre pas ce sujet pour recueillir des réponses, je le signale d'emblée, mais pour discuter des serveurs 'temps réel' (j'utilise ce terme pour distinguer un serveur auquel les clients sont en permanence connectés de serveurs passifs comme les serveurs web/mails classiques).

Donc, je bosse sur un MMO, et en suis l'architecte serveur. Le bébé se porte bien, j'attends avec impatience la béta histoire de voir ce qu'il a dans le ventre.
De mon expérience dans le domaine je suis arrivé à quelques conclusions :
- L'architecture d'un serveur de ce type est plutôt technique et demande des connaissances pour être menée à bien dans de bonnes conditions.
- Les besoins basiques (connexion/authentification de client, protection contre le piratage, optimisation de la charge) sont les même quelques soient les serveurs temps réels.
- Jeux vidéos exceptés, ils sont aujourd'hui assez rares (mais là, j'avoue, c'est peut-être un manque de visibilité de ma part). Je vois la bourse qui a une exigence de temps réel, les chats (qui sont quand même super simplistes), et ... pour le reste je bloque. L'explosion massive des technos web comme interface client condamne à utiliser majoritairement des serveurs passifs.
- Je me suis baladé sur le web au niveau des libs open source (et même moins open source), et n'ai trouvé que des libs pour serveurs webs (Apache), bdd (MysSQL/PostGre), master server (Unreal) ... mais pas une seule lib qui soit vraiment utile à mon job (au delà des libs plus bas niveau comme RakNet pour le réseau, les connecteurs bdd...).
- La majorité de mes collègues (pourtant dévs) ont bien du mal à 'comprendre' les contraintes de ma charge. Et j'avoue n'avoir pas trouvé de bible sur le sujet sur le net. Ce qui fait que je me sens un peu seul dans mon job.

En venant ici la bouche en coeur, je suis à la recherche de deux choses :
- Discuter avec des pairs (proches ou lointains), histoire d'échanger des recettes de cuisine, et m'ouvrir de nouveaux horizons.
- Déterminer si le domaine a vraiment besoin d'un défrichage et d'une formalisation. Si c'est le cas, je chercherai à aider. Je peux même voir avec mon boss à faire passer mon code en open source (pas gagné, mais qui n'essaye rien n'a rien).

Voila.
Merci pour toute aide.
SuperBidi.

[Elendhil]

Salut,

Je ne comprend pas trop ce que tu appels "serveurs temps réel" ou encore "serveur passif". Je suppose que tu veux dire un serveur qui répond aux requêtes avec une faible latence ?

L'architecture d'un serveur de ce type est plutôt technique et demande des connaissances pour être menée à bien dans de bonnes conditions.

Oui , vu que l'on est obligé de travailler dans un environnement multi-threads, avec gestion des transactions ...

Jeux vidéos exceptés, ils sont aujourd'hui assez rares (mais là, j'avoue, c'est peut-être un manque de visibilité de ma part). Je vois la bourse qui a une exigence de temps réel, les chats (qui sont quand même super simplistes), et ... pour le reste je bloque. L'explosion massive des technos web comme interface client condamne à utiliser majoritairement des serveurs passifs.

Tu as tous les serveurs d'application modernes comme Glassfish 3.1 ou encore JBOSS.

Et au niveau des serveurs de type mmo , tu en as plein:

- Reddwarf server
- Smartfox server
- Electroserver
- Player.IO
- photon server
...

Pour un apprentissage cela peut être intéressant de réaliser ce genre de serveur , mais dans un cadre professionnel je ne vois pas trop l’intérêt appart pour un projet avec des besoins très spécifique ?

[SuperBidi]

Tu me fais réaliser que ma veille techno laisse vraiment à désirer... en même temps, c'était la raison de mon arrivée ici.

Dans mes deux dernières boîtes, à chaque fois, la techno fut développée en interne intégralement. Ce qui, comme tu le stipules, est pas nécessairement intelligent au vu de ce qui est disponible. Personnellement, je ne m'en plains pas, dans le sens ou ça m'a permis de vraiment comprendre ce domaine.

Sinon, par passif, j'entends le fait qu'un serveur web (par exemple) réponds aux requêtes client, mais ne fait aucun traitement entre celles ci. Ce qui génère un asynchronisme entre les données que tu possèdes sur ton navigateur et les vraies données sur le serveur (tant que tu ne refais pas une requête). Par temps réel, j'entends qu'il y a en permanence synchronisation entre les données client et les données serveur, ce qui fait qu'à tout moment (ping mis de côté) ton client possède les données à jour.
Mais j'avoue, ce sont des termes personnels, je ne sais s'il existe de termes plus appropriés.

Je te remercie pour tes infos. Je cherchais effectivement un projet comme Reddwarf, pour l'utiliser dans un premier temps et pour participer éventuellement. J'ai pris un tel pied sur l'archi serveur que j'ai envie de continuer dans le domaine.
Merci.

Sinon, je suis toujours ouvert à la discussion sur le domaine.

[Elendhil]

Sinon, par passif, j'entends le fait qu'un serveur web (par exemple) réponds aux requêtes client, mais ne fait aucun traitement entre celles ci. Ce qui génère un asynchronisme entre les données que tu possèdes sur ton navigateur et les vraies données sur le serveur (tant que tu ne refais pas une requête)

Ce que tu expliques ici , c'est une des nouveautés de JEE 6 , le traitement asynchrone. Tous les serveurs d'application compatible JEE 6 peuvent traiter ce genre de problèmes. Comme tu vois même si on reste dans un environnement web (en général mais tu peux aussi avoir un client standalone) , les technos web ont la même problématique que la tienne , et des grosses entreprises mettent beaucoup d'argent à développer ce genre de serveur.

Tu peux utiliser côté client un affichage de type flex ou encore du JSF 2.0 ce qui te permet d'avoir des applications vraiment aboutis.

Voici des liens vers les api qui gèrent le JSF 2 , regarde les démos:

Primefaces
Icefaces
Richfaces

Maintenant imagine ce genre d'interface couplé avec un serveur d'application qui gère parfaitement l'asynchrone , la monté en charge, le clustering , les transactions pour la bdd et tous ça dans un environnement thread-safe !

Mais si tu cherches plus à réaliser un jeu de type Dofus ou alors genre wow , ce type de serveur n'est pas vraiment adapté, bien que la différence entre ce que font les serveurs mmo et serveurs d'applications tant à disparaître.
Ils ont la même problématique finalement, de lourds traitements à exécuter en parallèle , un temps de réponse qui reste faible et énormément de requêtes par seconde à traiter.

Sinon dans les serveurs que j'ai cité appart Reddwarf tous les autres sont des serveurs commerciaux, coûtent quelques milliers d'euros pour un serveur en production.

Quand j'avais regardé leurs caractéristiques, ils étaient tous à peu près similaires, ils traitent la partie réseau protocol, la réception/traitement des requêtes, la partie logique de jeu en mémoire.

Ils sont tous conçu de la même manière c'est à dire comme un serveur d'application. On lance le serveur qui va charger ton application en l’occurrence le jeu, qui va évoluer dans l'environnement du serveur. Ils vont communiquer grâce à une api , en général les langages disponibles sont java,c#,as3. Les développeurs n'ont plus qu'à s'occuper de la logique du jeu, et ils travaillent dans un environnement thread-safe.
Comme ce sont des projets commerciaux , ils ajoutent tous une multitude de petits plus / outils pour faciliter la vie des devs , car il y a énormément de points communs dans les mmos / jeux web ou sociaux.

Par exemple , une classe "Loby" , un sytème de zone, un chat , chiffrement des requêtes(bien qu'inutile ^^) , filtrage de mots clés sur le chat, internationalisation, possibilité d'utiliser l'udp en parallèle de tcp , possibilité d'envoyer des types autres que primitifs comme des tableaux, maps ou même des objets ect ...

Maintenant si on prend Reddwarf , lui est un peu appart , il ne gère aucun de ces "petits plus" , c'est du brut de décoffrage. A toi d'ajouter ton propre protocol sur celui de base, tous ce fait avec la classe "ByteBuffer". Tu peux te créer des outils afin de te faciliter la vie pour envoyer directement des tableaux, maps ou objets dans tes requêtes mais c'est pas implémenté de base. Pareil pas de chat de prévu , mais bon il est extrêmement simple d'en implémenter un ...

Bref reddwarf c'est juste une base/ un support pour développer ton jeu , tu ne peux pas être plus libre mais tu n'as plus à développer dans un environnement multi-threads(donc interdiction d'utiliser des méthodes synchronized ou de lancer soit même un thread).

De plus ce projet est open source donc tu as accès au code ce qui n'est pas le cas des autres projets commerciaux, par contre accroche toi si tu veux faire évoluer le code serveur existant. En effet le code a été développé par une équipe d'ingénieurs de chez sun avant qu'oracle rachète l'entreprise.
Et il était pas prévu que de "simples développeurs de jeux" mettent le nez dedans... Donc si tu veux y toucher , il faut une excellente connaissance de java ainsi qu'une très bonne connaissance du multi-threading avec ce langage(pour la partie serveur pur).

Sinon la grosse particularité, qui en fait son point fort et son plus gros point faible c'est la gestion de la base de donnée intégré(les autres projets à ma connaissance ne gèrent pas la persistance des données).
Reddwarf est inclus avec la Base de donnée Berkeley édition java de chez oracle (il y a une licence libre). Ce sgbd peut gérer jusqu'à 4 go par enregistrement et 256 To par base , c'est une base qui fonctionne par clé - valeur pas par table accessible uniquement par api. Elle implémente l'accès concurrent et les transactions ainsi qu'un cache.

Reddwarf s'en sert donc pour enregistrer chaque objet en mémoire grâce à la sérialisation java, donc chaque changement est immédiatement inclus dans la base de donnée. Donc par exemple si tu as une coupure de courant ,tu relances le serveur , tu perds uniquement les tâches en cours donc 1 à 2 secondes de jeu, de plus les tâches qui étaient encours sont juste annulées ou alors carrément relancé car il y a la gestion des transactions , tu te retrouves pas par exemple avec 100 Pièce d'or en moins et ta hache magique resté dans la boutique ...

Sinon la montée en charge est géré grâce aux "Task", chaque requête correspond à une tâche , elle doit jamais dépassé les 100 ms sous peine d'être annulée. Si tu as besoin d'un long traitement il faut le découper en plusieurs tâches. Tu peux aussi lancer des tâches à des dates précises , ou de manière récurrente. De plus par exemple si deux requêtes essaient d'accéder au même objet en même temps, on ne vas pas l'autoriser , car cela va déclencher l'accès concurrent , donc une des tâches sera relancé jusqu'à temps que l'objet soit de nouveau disponible.

Pour en revenir au problème que pose ce genre de base de donnée , si tu veux des statistiques sur tes joueurs , réattribuer un objet sur un personnage, accéder au données client : nom, prénom, adresse , mdp ect ... . C'est impossible sans ajouter un service car la base de données est illisible vu que ce qui est stocké c'est un identifiant et un objet sérialisé. Alors qu'avec une base type MySQl c'est bien plus simple de gérer ce genre de problèmes, surtout les statistiques vu que le sql a été un peu conçu pour ça.

Mais même avec ce genre d'outils comme reddwarf tu as besoin d'avoir pensé clairement l'architecture de ton jeu ! Car le même type de jeu en fonction de comment il aura été envisagé aura des performances totalement différentes sur reddwarf et même sous n'importe quel serveur de jeu , du genre fois 100.
Par exemple si tu essaies d’accéder en écriture régulièrement sur un objet depuis des tâches différentes , tu vas créer énormément de collisions , les performances vont chuter sévèrement. Ou encore si tu rafraîchis continuellement depuis le serveur plusieurs fois par secondes la position de tous les joueurs connectés, ou si tu utilises pas correctement les canaux de communication prévus dans reddwarf ect ...

Je te conseil fortement de lire en entier le tutoriel fournis avec reddwarf cela doit faire à peine 80 pages. Avec ça tu auras les bases pour travailler avec ce serveur, et même si tu ne comptes pas utiliser cette outil , tu pourras apprendre beaucoup de choses sur les choix de leur architecture ce qui ne peut être qu'utile.

D'ailleurs je te donne le lien, ainsi que qu'une interview du chef de projet qui explique un peu les problèmes qu'est censé résoudre le serveur :

interview

Les deux .odt en bas de la page

Et pour te convaincre que ce qu'il dit est loin d'être de merde , je me rappel très bien avoir vécu ce type de bugs quand je jouais sur certains mmo au début des années 2000. Certains de ces jeux étaient conçu par des gros studios. Par exemples certains bug précis permettaient de dupliquer une pièce d'armure précieuse ^^ , ou alors quand le serveur craché on revenais à une position antérieur de 10 min ou encore obliger de tuer de nouveau le monstre/boss.
Tous ces bugs n'existent plus dans les mmo modernes mais ils leur aura fallu pas mal d'années pour savoir éviter ce genre de soucis.

Donc je te déconseille de réaliser tout seul ce genre de serveur surtout pour un usage commercial. Mais c'est sur que pour un "petit" jeu web genre les anciens jeux php type ogame, tu peux réaliser cela toi même mais il te faudra surement beaucoup plus de temps pour aboutir sur quelque chose de certainement moins robuste que ce que tu aurais fait avec un serveur d'application classique comme glassfish.

Voilà , bonne lecture

[SuperBidi]

Je voulais te mettre un lien vers l'autre sujet, mais je vois que tu l'as trouvé seul. Je voulais éviter de ne parler que sur le forum MMO, parce que je pense aussi que ce type de techno ne s'applique pas qu'au domaine du jeu, d'où ce post sur le forum conception.
Il me reste encore beaucoup de lecture sur tout ce que tu as mis, raison pour laquelle ma réponse va se faire attendre.

[Elendhil]

Il me reste encore beaucoup de lecture sur tout ce que tu as mis, raison pour laquelle ma réponse va se faire attendre.

Oui pas de soucis, j'ai écris ce post parce que quand j'ai voulu me lancer dans la création d'un "petit" serveur de jeu j'ai pas mal galéré.

Au début on est super impatient , on se dit c'est aussi simple que les TP qu'on a eu pendant nos études

Une socket qui réceptionne les requêtes, on crée un thread à chaque réception d'un message qui va le traiter. Et la c'est le drame, ton serveur passe plus de temps à instancier les threads qu'à traiter les requêtes. Donc à force de regarder la doc sur le net sur ce sujet on comprend qu'il faut utiliser les pools de threads . Puis on commence à avoir des bugs complètement aléatoire, des deadlocks , on commence un peu à comprendre comment il est compliqué d'écrire du code dans un environnement multi-threading.
Et comme on mélange la logique du jeu avec le code gérant les threads ça deviens du code complètement inutilisable.

Bref à force de chercher on vois qu'il y a énormément de gens qui ont déjà travaillés sur ce sujet , et qu'ils existent une ribambelle de projet presque autant que les moteurs 3D ^^. Donc faut voir si on préfère créer son jeu ou passer son temps à réaliser l'outil qui va permettre de créer le jeu par la suite ...

Sinon je suis assez d'accord avec ce qui a été dis sur l'autre post :

* Eviter d'utiliser l'udp pour un mmo comme l'a très bien expliqué Emmanuel.
* Il est inutile de crypter les requêtes
* Ne jamais faire confiance au client , le serveur vérifie toujours la cohérence de ce qu'envoie le client. Il n'y a que le serveur qui traite la 'logique de jeu' jamais le client (donc à fortiori je suis contre un système décentralisé).

* Ne jamais demander au serveur de jeu d'envoyer les données graphiques, de l'audio, faire du streaming ect ... . Il y a des serveurs déjà spécialisé pour ça, serveur web, ftp , serveur de streaming ect ... . Si il y a besoin on peut utiliser le peer to peer pour économiser la bande passante pour partager les données graphiques comme le fait wow mais cela doit être conçu appart du serveur de jeu.
Il doit s'occuper uniquement du jeu !(d'ailleurs la taille d'un paquet sur reddwarf est limité à 8ko) Bon le chat ça passe , bien qu'en théorie on pourrait avoir un système dédié.

* Le serveur ne doit pas rafraîchir lui même les positions des clients, c'est le client qui demande par exemple à avancer. Et dans ce cas le serveur vérifie la cohérence, informe les autres clients qui ont besoin de l'information et seulement ceux là. Il y a surtout pas de "Heart beat" comme voulait faire l'auteur du post sur un autre sujet. Appart si tu as besoin d'un laps de temps , par exemple toutes les 10 secondes nouveau round, mais seulement dans ce genre de cas.

*Comme on traite des requêtes depuis des threads différents, il faut éviter de vouloir écrire en même temps sur un objet. Sinon il y aura forcement collision ou alors incohérence des données du jeu (encore pire ^^). Il est évident qu'il y aura toujours des cas où cela sera inévitable mais faut éviter au maximum.

*Il est obligatoire d'avoir un système d'atomicité des transactions pour prévenir tout problème du genre de l'algo pickpocket comme l'explique le développeur dans l'article. Attention faut aussi éviter les incohérences entre ce qui est en mémoire et la base de donnée donc le système doit prendre forcement cela en compte. Et donc pouvoir relancer une transaction ultérieurement ou alors l'annuler.

* Il est évident que dans un mmo, il faudra par moment lancer une action/tâche à réaliser dans un futur plus ou moins proche. Et cette tâche ne sera pas forcement connu au lancement du serveur. Donc il faut prévoir un système qui puisse lancer des tâches dynamiquement mais aussi un planificateur. Les tâches non immédiate doivent forcement être sauvées dans le base de données pour ne pas perdre d'information.

* Il est pratique de mettre en place un système de communication par canaux. Pour faciliter l'envoie d'informations à un groupe de personne, et donc que le serveur puisse y souscrire ou désabonner les clients.

Maintenant spécifique à reddwarf :

* Comme chaque objet en mémoire est sérialisé dans une bdd clé-valeur. La sérialisation en java va enregistrer toutes les propriétés de l'objet, donc quand il va rencontrer une autre instance comme champ il va la sérialiser aussi et ainsi de suite donc tout le graphe. Forcement cela va poser problème pour les performances, si on charge en mémoire une instance d'un joueur qui contient une liste d'amis, un inventaire, qu'il possède une maison ect ... . On va se retrouver à charger une quantité énorme de données en mémoire rien que pour accéder à un personnage. Pour palier à cela tu as une interface ManagedReference de prévu qui coupe la sérialisation afin d'éviter ce genre de problèmes. Donc il faut penser à bien découper ses classes, mettre ensemble les données les plus liés qui sont intéressantes à charger ensemble.

* De même tu va trouver des Collections spécialisés(les collections de bases) dans reddwarf qui sont la pour permettre des accès fortement concurrent. Il y a certaine fois tu seras obligé d'utiliser ce genre d'outils, si tu as une arraylist dont tu ne peux pas éviter qu'elle soit accédée à la fois en écriture/lecture par plusieurs tâches.

* Sinon le système d’authentification est très succin c'est à toi de l'adapter à tes besoins. Par défaut c'est juste un nom/mot de passe ...

* Il te faudra surement créer des services cela semble assez inévitable. Un des développeurs explique succinctement comment en créer un, tu as un lien sur le wiki je crois. Car si tu veux accéder à une base de données externe de type relationnel (pratique pour plein de petits trucs comme pour les données clients, identifier l'utilisateur, les statistiques, enregistrer les payements ...) , il va falloir te connecter à la base cela risque de prendre du temps , vu que chaque tâche est limité à 100 ms ... . Donc la règle c'est de ne jamais faire d'opération IO depuis une tâche. Si tu veux réaliser ce genre d'opération tu dois créer ton propre service , que tu greffes au serveur.

* Tu auras aussi un problème si tu veux créer un service pour modifier ou même consulter les données du jeux que ce soit à chaud ou à froid d'ailleurs.
Tu ne peux pas le faire comme sur une bdd sql, c'est le gros problème de cette architecture. Le plus simple c'est de créer un service qui va fonctionner comme un client classique , sauf qu'il fera des opérations particulières d'administrations/maintenances/consultations ect ...

* Sinon le système de node pour le cluster n'est pas finalisé donc tu peux pas lancer reddwarf sur plus d'un serveur. Mais toute l'architecture a été pensé pour cela donc cela demandera relativement peu d'effort si tu as absolument besoin de cette fonctionnalité.

* Et un dernier point qui me semblait abominable au début , comme c'est de la sérialisation si tu veux mettre à jour le code du serveur en production. La chose habituel sur tous les mmo le patch mensuel , il ne faut pas faire de changements qui seraient incompatible avec l'ancienne version des objets contenu dans le datastore. Sinon tu pourras pas charger les données, mais en pratique si tu décides pas de repenser complètement ton jeu , tu peux faire pas mal de chose sans soucis. Bref tu dois suivre les règles de sérialisation indiqué dans la doc de java.

* Par contre pour le backup de la base , c'est vraiment simple suffit de sauvegarder le répertoire data , c'est tout.

On est en plein dans le dilemme des bdds NoSQL vs SQL ! Voir les posts sur le sujet dans le forum.

[SuperBidi]

Excellent !
Je viens de finir l'interview, je retire ce que j'ai pensé (mais pas dit).
C'est proprement hallucinant comme concept.
Après, c'est ultra non conventionnel, notamment le fait que tu puisses pas requêter la bdd, ça limite le nombre d'interactions avec le web. Mais faut reconnaître que c'est un postulat et un modèle de serveur ultra technique et emballant.
Mais ... j'ai comme un gros doute malgré tout. Le fait de supprimer toutes les shards ...

Cas numéro 1 : J'ajoute un joueur dans mes amis. "Bob" devient mon ami. Comment je récupère Bob dans leur super système clé valeur ?
Solution numéro 1 : La clé devient le nom du joueur. J'espère que je n'aurais pas d'autres données exclusives, sinon, je ne sais comment je pourrais les gérer. Pire, si Bob change de nom, son id change ... Donc Bob ne pourra jamais changer de nom sauf à ce que dans l'objet Bob, j'ai de stocké l'intégralité des objets qui lui sont liés (vive la taille de l'objet). Donc s'il s'appelle "N***e sa maman", la seule modération qu'il me reste, c'est le ban ... D'ailleurs, le fait d'user d'une id écrite est aussi limitative pour la modération. Car à l'époque de l'UTF-8, vas y pour kicker un coréen, ou pour suivre dans tes logs le parcourt d'un présumé tricheur ...
Solution numéro 2 : J'ai une table de hachage de toutes les associations noms->id de joueur. Table de hachage qui sera limitative de la totalité de l'architecture, fini l'architecture shardless... Table de hashage qui sera hébergée ... je ne sais où, en bdd ??? Et qui sera accédée en continu...

Cas numéro 2 : J'ai 40 joueurs qui tapent mon dragon millénaire. Comme c'est shardless, Bob envoie ses ordres d'attaques au serveur 1, et moi au 2, Joe au 3... A chaque action impliquant le dragon, je vais devoir faire une synchro à l'accès aux données (s'agirait quand même que Bob passe ses dégâts et moi aussi). 40 synchros + tous les spectateurs + l'IA du dragon ... Est ce que je vais pas bloquer mon serveur ?

Cas numéro 3 : J'ouvre la page de l'hôtel de vente des épées à deux mains. Comment je récupère les épées à deux mains avec leur système clé valeur ? Je stocke 'quelque part' la recherche 'épées à deux mains' et le résultat qu'elle est censée renvoyer ? Espérons que les épées à deux mains n'aient pas trop de succès, sinon, on va se retrouver dans le cas du dragon avec une synchro atroce.
De même, mon manager d'hôtel de vente, je le stocke où vu que c'est multi-serveur ? En bdd ? La synchro va tuer le serveur. En mémoire sur chaque serveur avec des callbacks de modification ? Impossible, ça tuerait leur concept de monde synchronisé à deux secondes près (et j'ai mal à la tête maintenant).

Ok, ils ont des listes super concurrentielles... mais pourquoi je sens que le dév qui va devoir les utiliser va en chier s'il veut les utiliser de manière optimale.

De plus, j'ai quand même de gros doutes quant au nombre de machine qu'on peut ajouter à l'architecture. Dans une archi plus classique, on peut isoler une tâche lourde vers un autre serveur. Je l'ai fait pour le chat (surtout parce qu'un chat évolue en O(nombre de connectés²)). On peut le faire, par exemple, pour les IAs (très couteuses dans un MMORPG). L'IA devient donc un client. Mais là, pas de client, l'IA accède au fameux dragon, pire, le traitement de l'IA étant long, pendant ce temps là, personne ne peut y accèder, ou alors, j'ai des désynchros, avec une IA qui se calcule pour un statut du dragon alors que le dragon aura changé de statut avant que l'IA ait répondu ? Donc, l'IA devient un client alors que ce n'est pas censé être un client ? Ou alors, l'IA doit être suroptimisée ? Ou encore l'IA ne peut pas réagir à toutes les actions joueur, mais juste agir à un instant T, x fois par seconde ?

Enfin, au premier abord, leur modèle qui permet aux dèvs de jeux vidéos de ne pas être des dévs serveur leur permettra que de gérer des petits jeux. Pour un gros jeu, tu as besoin (en tant que dév serveur) de connaître parfaitement les fonctionnements bas niveau de ton serveur, au risque de tomber sur des problèmes de charge majeur (sur le précédent projet sur lequel j'ai bossé, on est monté à 10% des prévisions du nombre de joueurs connectés, avec une explosion de la charge du serveur proxy sans que je sache pourquoi, vu que j'utilisais une archi développée par un tiers... heureusement que le jeu n'a pas marché outre mesure, on aurait du sortir des tonnes de serveur).

Ensuite, tu soulèves le problème de la sérialisation. Perso, je soulèverai celui des accès disque (vu que chaque accès/écriture en bdd génère un loading/sauvegarde sauf à ce qu'ils ne stockent que les transactions, et dans ce cas là, leur fichier bdd va vite monter en taille), le fait que tu stockes tout en bdd, le fait que tu renonces à toute la force des bdd relationnelles (perso, un hôtel de vente, ça se gère avec une bdd dédiée, et tous les traitements exportés de ce côté là, résultat, mon serveur prend pas de charge au delà de la création des requêtes, et je gère un maximum de joueurs).
Enfin, je parle moitié dans le vide, faudrait que je parcoure leur code. Mais j'ai l'impression que c'est une usine à gaz, à lire tout ça. Je suis donc dubitatif, même si, comme indiqué tout en haut, leur modèle est génial sur le papier.

[SuperBidi]

J'ai lu le tutorial.
Ca a l'air extrêmement simple.
Je garde mes craintes quant aux limites de leur modèle (et surtout, le fait de partir du principe qu'on peut développer un serveur sans comprendre les algos bas niveau de son architecture).
Maintenant, il faudrait que je fasse un projet avec pour pouvoir valider la techno. Ce sera pas pour demain, mais qui sait...

Sinon, je reviens aux serveurs temps réel (ou n'importe quel nom qu'on leur donne) parce que j'ai pas envie de me limiter aux MMOs. Comme tu le dis toi même :

Maintenant imagine ce genre d'interface couplé avec un serveur d'application qui gère parfaitement l'asynchrone , la monté en charge, le clustering , les transactions pour la bdd et tous ça dans un environnement thread-safe !

Je connais mal les Glassfish et autre JBoss. Mais à lire sur eux, à chaque fois, je vois des notions qui ne me plaisent pas, notamment sont mis en avant des protocoles web classiques, mails...
J'ai jamais vu d'application professionnelle qui gère la même chose qu'un MMO, i.e. un grand nombre d'utilisateurs connectés en simultané interagissant tous ensemble sur les même données. Mais ça vient peut-être de mon inexpérience dans le domaine (j'ai passé la moitié de ma carrière dans le jeu). Je profite un peu de tes connaissances, pour savoir d'après toi quelles technos s'approchent le plus d'un serveur d'application de MMO.

[Elendhil]

Il est vrai que tu soulèves les bonnes questions, je suis assez d'accord avec toi sur certains points notamment l'absence de bdd relationnel que tu démontres avec ton exemple d'hôtel des ventes.

Mais tous n'est pas si noir je vais essayer de répondre à tes interrogations.

Cas numéro 1 : J'ajoute un joueur dans mes amis. "Bob" devient mon ami. Comment je récupère Bob dans leur super système clé valeur ?
Solution numéro 1 : La clé devient le nom du joueur. J'espère que je n'aurais pas d'autres données exclusives, sinon, je ne sais comment je pourrais les gérer. Pire, si Bob change de nom, son id change ... Donc Bob ne pourra jamais changer de nom sauf à ce que dans l'objet Bob, j'ai de stocké l'intégralité des objets qui lui sont liés (vive la taille de l'objet). Donc s'il s'appelle "N***e sa maman", la seule modération qu'il me reste, c'est le ban ... D'ailleurs, le fait d'user d'une id écrite est aussi limitative pour la modération. Car à l'époque de l'UTF-8, vas y pour kicker un coréen, ou pour suivre dans tes logs le parcourt d'un présumé tricheur ...
Solution numéro 2 : J'ai une table de hachage de toutes les associations noms->id de joueur. Table de hachage qui sera limitative de la totalité de l'architecture, fini l'architecture shardless... Table de hashage qui sera hébergée ... je ne sais où, en bdd ??? Et qui sera accédée en continu...

Alors chaque objet qui aura besoin de persister dans le monde devra implémenter l'interface ManagedObject. J'entend par Objet vraiment tout les genres du joueur en passant au dragon , château, maison,ville,zone/region, hôtel de ville, épée +2 , les monstres ect ...

Il y a un manager le DataManager qui s'occupera lui même de la persistance de ces objets dans le data store. En interne il attribue un identifiant quand tu veux sauver un objet pour la première fois, cette id unique est choisi par le serveur pas par le développeur de jeu. Si tu modifies l'objet par la suite le manager va sauver uniquement la modification et non sauvegarder de nouveau l'objet en entier. L'ID est en fait un objet BigInteger , c'est en standard dans le sdk de java, c'est utilisé couramment notamment les banques/services du genre Paypal. Tu as pas de limite à la taille d'un nombre, tu peux donc sauver 1000 milliards d'objets si tu veux sans que cela pose de soucis(enfin pas celui de l'id ^^).

Maintenant comment faire pour récupérer ton objet principalement par 2 moyens en plus de celui de l'id interne que l'on utilise rarement soi même. Je vais poster du code cela va être plus simple à expliquer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public class MyServer implements ManagedObject, Serializable, AppListener {

    /** Le numéro de version de sérialisation */
    private static final long serialVersionUID = 1L;

    @Override
    public void initialize(Properties props) {
        //On initialise le serveur ici
    }

    // La méthode qui nous intéresse ici, quand un client se log , son point 
    //  d'entré ce fait ici.
    @Override
    public ClientSessionListener loggedIn(ClientSession session) {
        String uid = session.getName();// C'est le nom sous lequel se présente le client (cela peut-être  tous ce que tu veux)

        String playerBinding = Player.PLAYER_BIND_PREFIX + uid;
        Player player = null;
        DataManager dataMgr = AppContext.getDataManager();
        try {
            player = (Player) dataMgr .getBinding(playerBinding);
        }catch (NameNotBoundException e) {
            //nouveau joueur
            player = new Player(uid);
            logger.log(Level.INFO, "New player created: {0}", player);
            dataMgr.setBinding(playerBinding, player);
        }
        player.setSession(session);
        return player;
    }
}

Donc comme tu peux le voir le code est très simple , c'est juste pour la compréhension.
C'est notre point d'entré du serveur quand un joueur arrive, grâce à la méthode getBinding on peut chercher si un objet est dans le datastore, si auparavant on lui a attribué un lien/identifiant en plus donc de l'objetID interne de type BigInteger.

Et la tu vas me dire la galère, comment se souvenir de tous les binds pour retrouver nos objets. En général tous les objets ont un lien , il est très rare qu'il n'y ait pas de relation entre eux. On va donc stocker des références depuis l'objet que l'on a bindé vers ce qui nous intéresse. Par exemple le sac du personnage, sa liste d'amis , sa super épée+2 ect ...

Cela va ce représenter simplement comme cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    // propriétés du joueur
    private final String userID;
    private String name;
    private int pv;
    private  int force;
    ....

    /** Le ClientSession pour le joueur ***/
    private ManagedReference<ClientSession> currentSessionRef = null;

    /** Un cannal de communication*/
    private ManagedReference<Channel> currentChannelRoomRef = null;
    
    /** Sa liste d'amis ***/
    private ManagedReference<List<Players>> friendsListRef;

    /** Son épée +2 **/
    private Sword superSword;
   
    ...

Grâce à leur système de ManagedReference, la sérialisation va sauver uniquement la référence mais pas l'objet vers laquelle elle pointe. Ce qui fait que l'on coupe le graphe de sérialisation. Quand tu charges un objet par exemple avec le getBinding() cité plus haut tu charges en mémoire uniquement les références, pas les objets.

Si tu as besoin de charger l'objet référencé à un moment ou un autre tu fais juste un .get() comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
List<Players> list = friendsListRef.get();

Et la tu peux remarquer que j'ai peut-être fait une erreur de conception. J'aurais surement du sauver la liste comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
private ManagedReference<List<ManagedReference<Players>>> friendsListRef;

Et donc obtenir ceci avec le get:
List<ManagedReference<Players>> list = friendsListRef.get();

Comme ça , cela m'évite de charger en mémoire les 500 joueurs si je veux accéder à la liste d'amis d'un personnage, la on ne charge uniquement les 500 références en mémoires qui pointent vers les objets du datastore. Si j'ai besoin d'un objet je fais juste un get() sur celui la.

Mais pour une liste d'amis , c'est pas terrible comme système , en général on a besoin d'une liste de noms à charger dans l'interface et surtout de pourvoir envoyer des messages à une personne à partir de son nom utiliser dans le jeu.

Donc on pourrait peut-être utiliser une Map comme collection, faut voir. On met en clé le nom du joueur et en valeur un ManagedReference<Player>.
Ou alors on peut se dire que pour une liste d'amis , on va avoir besoin de certaines informations constamment qui sont assez différentes des données du joueurs. Comme par exemple : est-il en ligne ? occupé ? dans une instance ? le message d'humeur du jour ect ...
Ces informations pourront être stockées dans une classe spéciale, qui aura une managed reference vers la classe Player. On pourrait aussi stocker les IDs des bindings ect ...

Bref il y a vraiment une multitude de façon pour concevoir ton architecture , et la manière dont tu l'auras conçue n'est absolument pas anodine. Il est évident que si tu n'utilises jamais Managed reference , ou que tu utilises des Managed Object beaucoup trop gros , tu vas à la catastrophe ! Il ne faut pas non plus partir dans l'excès inverse.

Prenons l'exemple de mon épée +2. J'ai choisi de ne pas utiliser de managed reference dans mon exemple, car c'est un jeu de combat où l'action est omniprésente, j'aurais donc besoin de modifier cette épée qui va s'user, accéder à ses caractéristiques en même tant que celles de mon personnage. C'est un choix de conception. Par contre si c'est un jeu où l'on ne se bat presque jamais , il est inutile de charger l'épée à chaque fois

Bref c'est un système très libre , et foutrement bien pensé je trouve.

Cas numéro 2 : J'ai 40 joueurs qui tapent mon dragon millénaire. Comme c'est shardless, Bob envoie ses ordres d'attaques au serveur 1, et moi au 2, Joe au 3... A chaque action impliquant le dragon, je vais devoir faire une synchro à l'accès aux données (s'agirait quand même que Bob passe ses dégâts et moi aussi). 40 synchros + tous les spectateurs + l'IA du dragon ... Est ce que je vais pas bloquer mon serveur ?

Alors là , je peux pas te dire ! Comme je disais, la fonction de clustering n'est pas en place, elle n'a pas encore été finis d'implémenté. C'est Sun Microsystems qui a lancé ce projet la société qui a conçu java mais avant la sortie d'une première version non beta , Oracle a racheté sun et arrêté le projet.
C'est pour cela qu'il s'appel reddwarf . Il est toujours disponible car Sun l'avait prévu comme un projet open source sinon il n'existerait plus. De plus les gars ont été licenciés par Oracle.

Mais si j'ai bien compris le chef de projet est maintenant dans une société dédié(Nphos) à l'accompagnement des studios de jeux vidéos qui veulent utiliser reddwarf donc il faut voir avec lui si tu as absolument besoin du clustering. Il a travaillé dans une société entre les deux qui développe des jeux facebook en flash, sur leur jeu far ils avaient 5000 joueurs simultanées mais bon c'est pas un jeu de combat , et les joueurs n'interagissent pas vraiment ensemble... Il explique que c'étais un tout petit serveur qui n'a pas dépassé les 50% de charge.

Mais je suppose qu'ils ne feraient pas comme tu l'expliques, ils réaffecteraient à la volé les joueurs qui ont besoin d'interagir entre eux sur la même machine, mais d'une façon totalement transparente ou "presque".

De toute manière tu auras besoin un moment ou un autre de concevoir un système de zone pour te faciliter la vie . Par exemple la zone avec ton dragon qui serait d'une certaine distance , appelons cela une grotte. Tu auras ta Classe grotte qui va contenir un dragon, la liste des joueurs, un cannal de communication ect ...
Toutes les sessions(canaux de communication des requêtes) des joueurs de la zone peuvent être réaffectées à la volé sur le même serveur. Et en ce qui concerne les données je pense que c'est la fonction de réplication de Berkeley Database qui est utilisé , pour que les données soit continuellement les même sur tous les noeuds.

Même si ce n'est pas utilisable pour le moment je suis certain que c'est faisable. En regardant l'outil que Terracotta propose Big Memory(gros buzz en ce moment). Ils arrivent à relier les Java virtuel machine de 150 pc en une seule mémoire continue, donnant l'impression au développeur de travailler sur une seule machine avec une fiabilité annoncée de 99.999% pour des données en mémoires et même si plusieurs pc crachent. Ils expliquent que chez un de leur client , ils changent une machine pendant que 10 000 transaction/sec continuent à ce faire, justement en interne terracotta utilise berkeley DB pour faire cela ...
Faut remarquer que c'était Sun derrière le projet reddwarf donc la même société qui a inventée les premiers serveurs d'applications, ce qui a donné naissance à Tomcat(conteneur léger jsp), Glassfish ect ...

Cas numéro 3 : J'ouvre la page de l'hôtel de vente des épées à deux mains. Comment je récupère les épées à deux mains avec leur système clé valeur ? Je stocke 'quelque part' la recherche 'épées à deux mains' et le résultat qu'elle est censée renvoyer ? Espérons que les épées à deux mains n'aient pas trop de succès, sinon, on va se retrouver dans le cas du dragon avec une synchro atroce.
De même, mon manager d'hôtel de vente, je le stocke où vu que c'est multi-serveur ? En bdd ? La synchro va tuer le serveur. En mémoire sur chaque serveur avec des callbacks de modification ? Impossible, ça tuerait leur concept de monde synchronisé à deux secondes près (et j'ai mal à la tête maintenant).

Ok, ils ont des listes super concurrentielles... mais pourquoi je sens que le dév qui va devoir les utiliser va en chier s'il veut les utiliser de manière optimale.

Alors la je suis d'accord avec toi dans ce genre de cas sans langage de type SQL c'est beaucoup plus chiant ...
Tu as plusieurs solutions, tu décides que les joueurs auront besoin d'accéder à l’hôtel des ventes depuis le web, leur mobile ect ... , tu peux prendre la décision d'externaliser seulement cette partie vers une bdd relationnel-objet (postgresql,mysql ect ...) , c'est pas forcement très gênant tu vas pouvoir greffer un service à reddwarf , avec ton propre manager qui va gérer les opérations du services 'Hotel des ventes'. Le serveur a été pensé dans cette optique dès le départ , bien que tu es besoin d'avoir de bonnes connaissances sur l'architecture de reddwarf pour écrire ce genre de service. Mais c'est pas si difficile que cela.

Autrement tu peux décider de créer ça façon "Objet"/UML, c'est un peu le même principe qu'avec une bdd classique. Tu ne peux pas tout mettre dans une seule table pour ton hôtel de ventes, il va falloir découper en plusieurs tables avec des relations. Ici tu va réfléchir afin d'obtenir cela de façon orienté objet.

Mais pour ce genre de cas précis il est évident que cela demandera plus de code, plus de prise de tête, les performances ne seront surement pas meilleur voir un peu moins bonne ...

Par contre au niveau de la synchronisation, cela pose pas tant de problème que cela, car par exemple si tu prends ton hôtel des ventes la majorité du temps les gens vont plus souvent consulter, les enchères qu'enchérir ou ajouter d'autres items , c'est uniquement de la lecture. Un objet accédé en lecture même par 30 clients ne pose aucun problème donc aucune synchronisation est nécessaire. C'est quand il va y avoir écriture que tu as forcement synchronisation, donc tu vas essayer de réduire au maximum les accès simultanés lecture/écriture ou écriture/écriture.
Pour cela il ne faut pas mettre tout tes objets dans une seule liste ... Si quelqu'un met une enchère sur une épée , il ne faut pas que cela bloque celui qui met enchérit sur une armure . On va découper en plusieurs listes, dans ce cas plus de problème vu qu'on ne modifie pas le même objet(on travaille sur 2 listes).

Maintenant tu sais que tu as une collection, ArrayList, HashMap, HashSet qui sera forcement accédé souvent en écriture/lecture et que tu ne peux pas l'éviter.
Alors tu vas utiliser leurs collections spéciales concurrentes avec exactement les même méthodes que les collections classiques que tu utilises habituellement, qui en interne découpent les données, on va dire "en genre de cellule" de façon à bloquer le moins possible les opérations. C'est identique aux versions mutithreading des collections de base du sdk java sauf qu'elles sont encore plus performantes pour les accès concurrents. Par contre il ne faut pas les utiliser si tu penses que les accès lecture/écriture et écriture/écriture sont assez rare , car dans ce cas tu perd en performance pour rien car elles sont forcement moins efficaces que les versions standards.

De plus, j'ai quand même de gros doutes quant au nombre de machine qu'on peut ajouter à l'architecture. Dans une archi plus classique, on peut isoler une tâche lourde vers un autre serveur. Je l'ai fait pour le chat (surtout parce qu'un chat évolue en O(nombre de connectés²)). On peut le faire, par exemple, pour les IAs (très couteuses dans un MMORPG). L'IA devient donc un client. Mais là, pas de client, l'IA accède au fameux dragon, pire, le traitement de l'IA étant long, pendant ce temps là, personne ne peut y accèder, ou alors, j'ai des désynchros, avec une IA qui se calcule pour un statut du dragon alors que le dragon aura changé de statut avant que l'IA ait répondu ? Donc, l'IA devient un client alors que ce n'est pas censé être un client ? Ou alors, l'IA doit être suroptimisée ? Ou encore l'IA ne peut pas réagir à toutes les actions joueur, mais juste agir à un instant T, x fois par seconde ?

Il ne faut surtout pas faire cela dans leur système. Justement il y a aucun besoin pour cela de plus tu perds les fonctionnalités des tâches. Tu dois concevoir ton dragon comme un simple ManagedObjet.
Il faudra bien entendu utiliser les fonctionnalités de l'héritage ainsi que les interfaces donc développer à fond orienté objet de manière à obtenir un système combat adéquate , et d'éviter d'écrire du code en double. Certaines actions seront les même pour certains types de monstres , tu pourras surcharger certaines méthodes afin d'obtenir des attaques particulières ect ...

Enfin ton dragon VIT (dans la matrice oups je m'égare) dans le système il ne se connecte pas , si quelqu'un l'attaque il répond. Si tu veux qu'il fasse une action particulière , alors qu'il n'y a pas de joueurs , je ne sais pas manger les orcs qui sont dans le coin , cela pose pas de soucis.
Tu vas lancer une tâche , tu peux même lancer une tâche périodique qui vérifie tout les X millisecondes/seconds/heures/jours si les critères sont réunis pour lancer la tâche bouffer des orcs ^^
Elle va regarder si le dragon a pas assez de point de vie par ex si c'est le cas elle lance la tâche bouffer de l'orc , cette tâche pourra lancer autant de tâches dont elle a besoin ...

Pour cela tu as un Manager , qu'on appel le TaskManager qui va prendre en charge le lancement des tâches dans son propre context, avec un scheduler , en fonction des paramètres et des méthodes , tu peux lancer :
- Une tâche unique immédiate
- Une tâche avec un certain retard
- Une tâche qui s’exécute périodiquement lancé immédiatement
- Une tâche qui s’exécute périodiquement lancé avec du retard.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
AppContext.getTaskManager().schedulePeriodicTask(new CheckPVDragonTask(), delay, period);

Une tâche c'est simplement une classe qui implémente l'interface Task et Serializable .
L'interface ne contient qu'une méthode run(). Si le serveur crache comme la tâche a été sauvé en bdd , elle vont être rechargé en mémoire et seront exécutées quand même au moment voulu

Par contre l'exécution de la méthode run() ne doit pas dépasser les 100 ms. Si c'est le cas par exemple à cause de synchronisation, elle sera relancée par le système lui même dans son context ! En gros si ta tâche fait x opérations et bloque sur la dernière en dépassant le délai de 100ms par défaut (configurable évidement ). Il va annuler la transaction puis la relancer ultérieurement. Il y a un algo interne qui gère tous ça, plus la tâche échoue plus elle est relancé beaucoup plus tard, au bout d'un certain nombres de fois je ne sais plus combien , le système s'en débarrasse je crois. En partant du principe que c'est forcement une erreur de code non un problème de 'verrou'.

Par contre cela oblige à concevoir son code de manière très structuré , et parfaitement découpé en tâche simple ! Si qui est encore mieux au niveau des développements des gros projets avec beaucoup de développeur.

Sinon je n'ai pas précisé, quand le serveur reçois une requête d'un client , elle est exécuté aussi dans son propre contexte mais totalement invisible par le développeur tu n'as pas besoin d'utiliser le task manager ou l'interface task. Mais l'opération que va réaliser cette requête ne doit pas non plus dépasser les 100 ms sous peine d'être relancé ultérieurement.
Donc pour résumé le serveur ne répond qu'aux requêtes des clients qui sont les éléments déclencheurs. Et quand il a besoin d'agir en dehors ce ça , il faut programmer des task.

Enfin, au premier abord, leur modèle qui permet aux dèvs de jeux vidéos de ne pas être des dévs serveur leur permettra que de gérer des petits jeux. Pour un gros jeu, tu as besoin (en tant que dév serveur) de connaître parfaitement les fonctionnements bas niveau de ton serveur, au risque de tomber sur des problèmes de charge majeur (sur le précédent projet sur lequel j'ai bossé, on est monté à 10% des prévisions du nombre de joueurs connectés, avec une explosion de la charge du serveur proxy sans que je sache pourquoi, vu que j'utilisais une archi développée par un tiers... heureusement que le jeu n'a pas marché outre mesure, on aurait du sortir des tonnes de serveur).

Comme je l'ai expliqué plus haut il est nécessaire de comprendre parfaitement l'architecture de reddwarf sinon tu vas faire du grand n'importe quoi ! Pour cela tu as besoin de lire les 80 pages du tutorial fournis, de regarder certains exemples , de lire un peu le forum. Mais tu n'as absolument pas besoin de mettre les mains dans le cambouis(sauf cas très précis), coder toi même en utilisant des verrous, gérer des pools de threads ect ...

Ensuite, tu soulèves le problème de la sérialisation. Perso, je soulèverai celui des accès disque (vu que chaque accès/écriture en bdd génère un loading/sauvegarde sauf à ce qu'ils ne stockent que les transactions, et dans ce cas là, leur fichier bdd va vite monter en taille), le fait que tu stockes tout en bdd, le fait que tu renonces à toute la force des bdd relationnelles (perso, un hôtel de vente, ça se gère avec une bdd dédiée, et tous les traitements exportés de ce côté là, résultat, mon serveur prend pas de charge au delà de la création des requêtes, et je gère un maximum de joueurs).
Enfin, je parle moitié dans le vide, faudrait que je parcoure leur code. Mais j'ai l'impression que c'est une usine à gaz, à lire tout ça. Je suis donc dubitatif, même si, comme indiqué tout en haut, leur modèle est génial sur le papier.

Il est certain que la taille de la Bdd, ne va faire que croître ! Bien qu'on est le droit et l'obligation de supprimer les ManagedObject du datastore si ils deviennent inutile ...

Sinon petite remarque, Berkeley Data Base est développé par oracle depuis longtemps c'est un produit open source et sous licence utilisé par de nombreuses sociétés. Elle est très connu c'est quelque chose de fiable ça pas été inventé par l'équipe du project darkstar. Ce sgbd utilise un système ce cache, appelé memcache je crois, c'est un autre produit du monde libre, très publicité pour ces performances. On est limité à 256 Terra octet par base. Avant d'atteindre cette limite tu sera obligé d'avoir un raid assez monstrueux pour stoker autant de données ^^.

Je pense aussi que les disques vont s'user assez vite mais peut-être pas beaucoup plus qu'avec une bdd "classique". De toute façon sur les serveurs même de base 100 euros/mois tu as un raid miroir de prévu si un disque lâche , il est remplacé , le "système" va dupliquer les données du disque restant sur le nouveau disque. De plus il est possible de faire un backup de la bdd de berkeley très facilement juste copier un répertoire, tu peux même utiliser rsync pour tes backups.

Bon voilà je vais m'arrêter là , après ce gros pavé !

@ Plus tard

[Elendhil]

Je garde mes craintes quant aux limites de leur modèle (et surtout, le fait de partir du principe qu'on peut développer un serveur sans comprendre les algos bas niveau de son architecture).

Si un jour tu développes des applications pour un serveur du style JEE , tu ne peux pas connaître tous les algos utilisés derrière, ni savoir exactement comment c'est implémenté, le code source pour ce genre de serveur est autour de 60 Mo ... Par contre tu es obligé de comprendre l'architecture sur lequel ce genre de serveur repose, de connaître certaines api publique , ect ...

Sinon, je reviens aux serveurs temps réel (ou n'importe quel nom qu'on leur donne) parce que j'ai pas envie de me limiter aux MMOs. Comme tu le dis toi même :

Citation:
Envoyé par Elendhil
Maintenant imagine ce genre d'interface couplé avec un serveur d'application qui gère parfaitement l'asynchrone , la monté en charge, le clustering , les transactions pour la bdd et tous ça dans un environnement thread-safe !

Je connais mal les Glassfish et autre JBoss.
Mais à lire sur eux, à chaque fois, je vois des notions qui ne me plaisent pas, notamment sont mis en avant des protocoles web classiques, mails...

On ne peux pas éviter ce genre de serveur, les serveurs d'applications sont partout, si tu es développeur java cela représente 80% des offres d'emplois. Et c'est loin d'être une techno qui s'appréhende en lisant 2 - 3 tutos sur le net. Il vaut mieux un bon gros bouquin de 800 pages , et de l'expérience dans le domaine. Mais même les développeurs JEE professionnels seraient pour la plupart incapable de créer un serveur d'application comme Glassfish, JBOSS, JOnAS, ou encore Websphere d'IBM. Toute proportion gardé c'est la même chose pour reddwarf.

Sinon oui, ils reposent tous sur les technologies/protocoles web , ils ont été conçus pour cela afin de fournir les nouveaux services sur internet , Amazon, Gmail, Services bancaires, portails boursiers, services de trading etc ... Mais en même temps , ils peuvent accepter les connexions de client dit lourd dans une optique d'infrastructure d’entreprise , avec des services interne en entreprise genre ERP.

J'ai jamais vu d'application professionnelle qui gère la même chose qu'un MMO, i.e. un grand nombre d'utilisateurs connectés en simultané interagissant tous ensemble sur les même données. Mais ça vient peut-être de mon inexpérience dans le domaine (j'ai passé la moitié de ma carrière dans le jeu). Je profite un peu de tes connaissances, pour savoir d'après toi quelles technos s'approchent le plus d'un serveur d'application de MMO.

Je pense qu'on les remarques pas c'est tout. Si on prend Amazon, ils ont des centaines de milliers d'utilisateurs connectés en permanence, qui vont parfois interagir sur les même données. On peut prendre l'exemple de liste de mariage ou de cadeaux qui sont modifiées pendant que d'autres les consulte. Les suggestions qui se modifient quand on consulte certains livres , ect ...

Si tu cherches à savoir si il y a d'autres grand type de serveur, à ma connaissance je ne crois pas. Avant ce genre de chose était développé en interne à l'entreprise cela coûtait extrêmement cher. D'où la demande de serveurs d'applications modernes qui sont maintenant omniprésent bâti sur certains standards.

En ce qui concerne les mmo c'est la même chose, mais l'exigence sur les temps de latence pour ce genre de produit on fait qu'il était pas vraiment possible d'utiliser ces serveurs pour le monde du jeux. Mais comme je te dis dans le future je pense que cela peut être envisageable.

Vu l'énorme demande suite aux succès des Web Games, des Socials Games , ou des hack slash genre dofus , il y a énormément d'entreprises qui se sont mis à concevoir des middlewares/serveurs mmo pour diminuer les coûts des studios. Voilà pourquoi on en trouve à la pelle maintenant.

Toujours au niveau du mmo tu as un parfait exemple d'un jeu sans shard , c'est EveOnline pour l'utilisateur il n'y a qu'un seul monde. Tous les joueurs de Eve peuvent communiquer entre eux, ce n'est pas comme sur wow avec monde 1 , monde 2 , ect ..
Bien sur derrière c'est une ferme de serveurs mais l'utilisateur ne s'en rend pas compte. Je crois d'ailleurs qu'ils ont le record de connexions sur le même univers plus de 60 000. Ils ont du concevoir quelques choses de très proche je suppose, ou alors c'est un système de zone, un serveur par zone mais si une machine tombe, tous les clients dessus sont tous déco, de plus la zone devient inaccessible.

Enfin je termine sur le noSQL qui revient avec les grosses startup américaine, Google, Twitter, Facebook qui le réinvente, ils ont été forcé d'abandonner les bdd relationnel-objets à cause des contraintes impossible à tenir pour certains de leur service. Tu prend le moteur de recherche de Google, il donne des recherches "presque en temps réel" , et modifie en "temps réel" aussi les résultats des mots clés en fonction des visites des sites et de nombreux autres critères. Ils ont été obligés d'inventer des BDD spéciales(enfin cela existe depuis longtemps), d'ou le projet Cassandra soutenu par Apache, Google et Facebook.

D'ailleurs il serait possible d'utiliser cette base de données à la place de berkeley, c'est d'ailleurs sur quoi travaille le gars qui donne l'interview , dans la société Nphos où il travaille actuellement, qui est spécialisé dans l'accompagnement des studios de jeux vidéos qui veulent utiliser reddwarf.

Voila je crois avoir répondu à tes questions

[SuperBidi]

Tu m'as convaincu
Du moins, sur la fonctionnalité du système. Faut juste être sûr de ce qu'on fait. Le soucis que j'ai rencontré dans les projets dans lesquels j'ai bossé étaient surtout des demandes du 'client' (dans mon cas le game designer) qui se moquait de la structure interne du système. Or, Reddwarf apporte des limitations non négligeables, qui sont parfaitement gérables si on a d'entrée du projet une bonne description des besoins mais qui peuvent devenir gênantes si trop de changements sont faits en cours de projet. Le défaut de ne pas avoir la main mise sur les threads, la bdd, ni la gestion et sérialisation des objets en interne étant qu'on ne peut pas facilement faire de code 'crade' (ou pragmatique) quand c'est la seule solution pour implémenter la nouvelle feature 'dont on ne peut se passer' dans les temps.
L'autre défaut que je lui trouverai, ce sont ses perfs. Tu parles d'un petit serveur qui gère 5000 connections à 50% de proc, je trouve que pour un jeu facebook, c'est faible, sans être trop faible. Avec une archi plus classique on doit pouvoir faire du 2 fois plus, donc une grosse différence. Mais en même temps... évolution de la puissance des machines + facilité de faire accepter aux joueurs la présence de plusieurs serveurs, et le tour est joué.

La seule chose que je reprocherai au projet, c'est de ne pas s'attacher aux bonnes choses. Ils mettent une importance énorme au fait de remettre le serveur exactement dans son état à l'extinction, et le fait de pouvoir crasher sans perte de données.
Or, quand tu as un crash, en vrai, tu perds pas tant que ça, si tu as réfléchit un tant soit peu aux moments où tu sauvegardes tes données. Dès qu'une donnée importante est modifiée -> sauvegarde. Et puis, faut pas rêver, des crashs on en a presque jamais une fois la béta terminée.
Quant à la persistance, c'est génial d'un point de vue algorithmique, mais d'un point de vu des besoins, je pense que c'est juste un petit plus, et pas un argument choc. Or, un framework permettant de facilement développer un jeu vidéo sera plus facilement utilisé par des petites structures que par des gros géants. Et les petites structures vont rarement chercher les effets secondaires.
Surtout que personne ne sera là pour voir le dragon réapparaître. Parce qu'une fois ton serveur à terre, tu perds tous tes joueurs. Donc la persistance... Je préfèrerai réapparaître dans l'auberge que seul face au dragon qui est toujours bardé de buff et aggressif.

[SuperBidi]

En fait, si je me permettais comme un certain politicien américain d'avoir un rêve, je verrai cette architecture :

Un serveur (tu t'en doutes), et des clients quelconques. Sur le serveur tu aurais des 'fichiers'. Du moins, pour les clients, ça y ressemblerai. Un exemple basique seraient des fichiers de type xml. Clés-valeurs imbriqués. Avec ça, on décrit la quasi totalité des structures de fichiers existantes.
Un client connecté pourrait requêter un fichier. On lui enverrai alors le xml. Il pourrait le modifier par des transactions. N'importe qui pourrait accéder au même fichier, et recevrait les transactions des autres clients.
Le client serait quelconque : Word, Autocad, un MMO, tout ce que tu veux. Le but serait que les requêtes comme les fichiers soient standardisés. Résultat, une fois le standard décrit, tu aurais plus de modif du serveur. Et ensuite, tu pourrais accéder à n'importe quel fichier avec n'importe quel client.
Tu pourrais donc bosser en simultanée sur un doc avec un collègue, alors qu'il est dans le TGV avec juste son smartphone. Son client dégradé par rapport au tien afficherai pourtant très bien les données. Tu serais peut-être le seul à pouvoir faire de la mise en page, tags xml ignorés par le client de ton collègue. Toi, tu serais sous OpenOffice, parce que tu préfères à Word, on s'en moque. Et puis, si au milieu de la 'réunion', ton boss passe, il peut voir ton boulot, apporter un commentaire. Si ton collègue perd la connexion, il peut recommencer à bosser quelques heures plus tard, il aura la dernière version du fichier, éventuellement, les dernières transactions ayant amenées à ce résultat. Toi, tu sauras qu'il sera déconnecté, donc tu n'attendras jamais.

Atout de cette structure :
Externalisation complète de tes documents. Bon, ça, c'est une 'base' du Cloud Computing.
Gestion automatique du versionning. Ok, ce serait pas du SVN, mais tu pourrais avoir juste ce qu'il faut comme versionning pour gérer les cas 'standards', comme l'annulation de tes dernières modifs, ou la sauvegarde d'une version 'bien'.
Sauvegarde automatique, plus jamais de perte de données en cas de bug.
Ton document ne serait jamais trop vieux pour être lu. Surtout que dans beaucoup de technos (traitements de texte, tableur... techno parmi les plus utilisées en entreprises) tu as très peu d'évolutions réelles sur la structure des fichiers.
Tu pourrais choisir le logiciel qui accèderait à quel document. Bon, ça deviendrait certainement la foire à l'empoigne comme on l'a vu avec les browser, mais du moins, tu pourrais choisir le client de ton choix. Et si tu changes de client, tu perds aucun de tes documents.
Et surtout, tu pourrais vraiment bosser en simultanée sur un document avec des collègues. Pas les documents partagés Excel ou une fois sur 10 tu vas perdre des données et où tu es obligé d'apprendre, pour chaque logiciel, comment partager tes données. Non, un vrai partage des données standardisé. Et en temps réel.

Quand tu réfléchis à la quantité de mails qu'on échange pour se coordonner, imagine si tout cela passait par des documents standardisés. Si plutôt que de demander un devis à un fournisseur, puis de le discuter par mail, pourquoi ne pas directement ouvrir un devis, y marquer tes besoins, demander un partage avec ton fournisseur, qui pourrait en temps réel indiquer les prix de la prestation. Discuter de plusieurs devis différents en sauvegardant les versions 'biens'. Ton fournisseur aurait peut-être des macros associées à ses devis (des prix standardisés, que sais je), il pourrait les appliquer, sans soucis. A l'issue, les deux partis signent électroniquement le document, et c'est parti.
Bien sûr, il existe des tas de solutions qui font un peu cela. Mais chaque fois, il faut posséder la bonne version du logiciel. Les risques de bugs sont conséquents (alors que dans le modèle au dessus, si le client bugge, les données ne sont jamais perdues). Plus jamais besoin de sauvegarder, sauf si tu veux conserver une version comme étant 'bien'. Derrière, on pourrait mettre de la sécurité facilement (quoi que ça ralentirait bien le système). On pourrait aussi avoir des structures de dossier, comme sur une machine standard, avec d'autres 'clients' dont le rôle serait d'aller chercher un fichier facilement. Et puis, ce serait facile d'exporter ça sur des tonnes de serveur, load balancés en répartissant les fichiers entre eux.

Enfin, je dois rêver éveillé...

[Elendhil]

Oui 5000 joueurs c'est peut-être pas énorme pour un jeu Facebook... Je me rend pas trop compte, le jeu en question est Zoo Kingdom.

Mais de toute façon le serveur n'est pas fini, le projet était en tout début de beta , les "vrais" développeurs ont été virés depuis il y a plus de devs à temps plein, cela fait plusieurs mois qu'il n'y a pas eu de commit. Bref sans une grosse structure qui déciderait d'investir dans ce projet open source il va mourir lentement... Donc difficile de comparer les performances avec des serveurs fait maison par de gros studios qui sont en production depuis plusieurs années.

Je comprend très bien qu'en tant qu'architecte serveur sur des jeux comme slage, wakfu et consort, tu ne sois pas plus emballé que ça. Vous avez déjà du code solide sur lequel vous appuyer pour vos futures jeux. Réécrire tout ce code pour passer à reddwarf , sans la garantie d'obtenir de meilleurs performances , avec dans la seule optique un code un peu plus maintenable(même pas sur) et de nouvelles fonctionnalités qui ne semble pas super intéressante dans votre cas.

Maintenant si vous êtes 4-5 personnes dans un petit studio sans une grosse expérience dans le domaine ni du code existant sur lequel s'appuyer. Je pense qu'il y a pas photo tu va gagner énormément temps à utiliser ce genre d'outils plutôt que de partir de zéro. C'est surtout sur le temps de dev que ce genre d'outil montre son potentiel.

**********************************************************************

Pour ton deuxième post qui est un peu hors sujet avec le titre. D'ailleurs je comprend mieux maintenant ta question , tu ne cherchais pas une solution pour développer un serveur de mmo , mais un outil/api qui permette un peu les même fonctionnalités (ton fameux temps réel) dans une tout autre optique

Pour donner quelques infos en vrac pas forcement utiles par rapport à ce que tu expliques.
Alors il existe des BDD orienté document/xml. C'est un genre de data base qui connait un certain succès ces derniers temps. Notamment mongoDB orienté document qui s'appuie non pas sur le xml mais du Json mais l'idée est la même. Sinon derrière les premières version de svn , c'était berkeley DB qui était utilisé, comme quoi tout est lié ^^

Pour finir, comme tu le précises il y a déjà tout plein de solutions qui réalisent ce que tu expliques mais tu n'as pas de système associant toutes ces caractéristiques. Peut-être qu'en cherchant bien on trouverait quelque chose de très très proche mais avant que ce soit universel et que tous les logiciels utilisent le même format de données ... Il y a encore un peu de temps.

[SuperBidi]

Clairement, pour une boîte qui n'a pas d'expérience en développement de serveur, Reddwarf est une très bonne opportunité. La vraie difficulté étant qu'il est encore en béta, et qu'une boîte qui ne s'y connaît pas en dév serveur aura du mal à le débugger (pour le coup, l'aide du concepteur originel est pas superflue).

Pour mon titre, j'ai cherché celui qui convenait le mieux. Comme il faut bien partir de quelque chose, je suis parti de ce que je connais. Mais oui, dans l'absolu, je ne veux pas réduire ces technos aux seuls jeux vidéos, elles sont pour moi porteuses d'innovation à court terme.

Pour tout ce qui est bdd, j'ai bossé sur du content management (Stellent à l'époque, Oracle Content Management désormais), donc je sais qu'il existe des solutions pour la partie fichiers. Mais on n'attend pas d'une bdd qu'elle te fournisse plus que du stockage, aussi intelligent soit il. L'application qui l'utilise doit encore être développée.

Bon, je garde l'idée sous le coude, sait on jamais... peut-être que des gens y réfléchissent actuellement et qu'ils chercheront bientôt un architecte serveur