Jump to content
×
×
  • Create New...

Architecture BDD-Serveur


Nicosti
 Share

Quelle est selon vous la meilleure architecture ?  

5 members have voted

  1. 1. Quelle est selon vous la meilleure architecture ?

    • Architecture 1
      0
    • Architecture 2
      2
    • Architecture 3
      3


Recommended Posts

  • Retraité

Bonjour à tous,

 

développant depuis quelques mois un émulateur, j'en suis venu à me demander comment organiser au mieux le multi-serveur concernant la base de données. Je fais donc ce sujet pour débattre des différentes architectures auxquelles j'ai pensé et aussi pour voir si vous en avez d'autres à proposer.

 

Architecture 1

Schéma

.png

 

Explications

1. Le realm se lance et se connecte à la BDD.

2. Le game se lance.

3. Le game se connecte au realm.

4. Le realm vérifie les identifiants du game. Si le game est ok, le realm crée un utilisateur à session unique pour la BDD.

5. Le realm renvoie les identifiants créés au game.

6. Le game se connecte à la BDD via les identifiants reçus.

 

Avantages

- Créer un site par dessus est facile grâce à la centralisation de toutes les données statiques et dynamiques.

- Un debug BDD est répercuté sur tous les game.

 

Inconvénients

- Les games doivent être exactement les mêmes, ce qui offre donc peu de personnalisation possible en cas de serveurs multiples.

 

 

Architecture 2

Schéma

.png

 

Explications

1. Le realm se lance et se connecte à sa BDD.

2. Le game se lance et se connecte à sa propre BDD pour charger ses données statiques.

3. Le game se connecte au realm.

4. Le realm vérifie les identifiants du game. Si le game est ok, le realm crée un utilisateur à session unique pour la BDD.

5. Le realm renvoie les identifiants créés au game.

6. Le game se connecte à la BDD via les identifiants reçus pour charger les données dynamiques.

 

Avantages

- Les données dynamiques sont centralisées ce qui permet de créer facilement un site par dessus.

- Les opérations ne sont pas complexifiées pour le realm

- Chaque game ayant sa BDD statiques, la personnalisation du serveur est possible

 

Inconvénients

- La vérification des données dynamiques s'en trouve complexifiée (foreign key)

 

 

Architecture 3

Schéma

.png

 

Explications

1. Le realm se lance et se connecte à sa db.

2. Le realm se connecte aux db des games.

3. Le game se lance et se connecte à sa db.

4. Le game se connecte au realm.

 

Avantages

- Chaque game est très personnalisable

 

Inconvénients

- Le realm doit connaitre toutes les adresses et identifiants des BDD des games lesquelles doivent toujours être on pour éviter les incohérences.

 

 

Voila, le débat est ouvert, ainsi qu'un sondage pour voir quelle architecture vous semble la meilleure en vue d'une implémentation  ;)

java style =)

Link to comment
Share on other sites

  • Replies 14
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

  • Funkiest

Je t'ai remercié car tu montres les différentes méthodes qui existent en matière d'architecture en montrant les avantages & inconvénients, ce qui permet, même si ce n'est pas le but premier, d'offrir aux gens la possibilité de choisir. Mon commentaire paraît ambigu cependant.

 

Sinon je ne saurait pas te répondre, je ne suis pas dans l'émulation dofus. ^^

Link to comment
Share on other sites

Bonsoir,

 

La 3ème méthode est celle que j'utilise et je la trouve plus "simple" que les autres.

En effet, la base de donnée et le realm doivent être remplit d'informations basique mais elle permet une gestion simple des données puisque il n'y aucune interférence entre le realm et le game.

 

-Zo

Link to comment
Share on other sites

  • Retraité

Bonsoir,

 

La 3ème méthode est celle que j'utilise et je la trouve plus "simple" que  les autres.

En effet, la base de donnée et le realm doivent être remplit d'informations basique mais elle permet une gestion simple des données puisque il n'y aucune interférence entre le realm et le game.

 

-Zo

 

Qu'entend-tu exactement par interférence ?

java style =)

Link to comment
Share on other sites

  • Retraité

Oui mais le realm a besoin très tôt dans la connexion du client de savoir quels sont ces personnages et sur quels serveurs ils se trouvent. Cette donnée doit être récupérée dans la base de données des games. Donc plus on a de games, plus on va devoir multiplier les connexions à des BDD différentes...

 

Je ne cache pas que c'est l'alternative qui me convient le moins, déjà à cause de cette multiplicité des connexions mais aussi parce qu'à moins d'avoir les sources, les adresses et identifiants des BDD doivent être stockées quelque part, ce qui niveau sécurité est pas génial... 

java style =)

Link to comment
Share on other sites

Après j'ai développé ma sécurité, donc sur ce point je suis pas très inquiét mais c'est vrai que c'est un peu foutoir comme utilisation de l'architecture principale mais je trouve que, pour ma part, ça tourne bien. :)

Link to comment
Share on other sites

  • 9 months later...

Personnellement aucune des 3.

 

Pour moi ça serais ça :

 

Bdd_realm + Bdd_game

 

Le realm ce connecte a ça base de donnée.

Le game ce connecte a ça base de donnée.

 

Une communication ce fait entre le realm et le game pour passer des informations.

 

Exemple :

On créer un personnage, le game envois les infos au realm de façon a que celui ci mette dans ça base de donnée la relation entre compte - serveur - character.

Link to comment
Share on other sites

  • Retraité

Personnellement  aucune des 3.

 

Pour moi ça serais ça :

 

Bdd_realm + Bdd_game

 

Le realm ce connecte a ça base de donnée.

Le game ce connecte a ça base de donnée.

 

Une communication ce fait entre le realm et le game pour passer des informations.

 

Exemple :

On créer un personnage, le game envois les infos au realm de façon a que celui ci mette dans ça base de donnée la relation entre compte - serveur - character.

 

Pourquoi pas, mais cela augmente drastiquement la charge de travail du realm et ce n'est pas des plus sûr. Ce système entraîne une grosse dépendances de tes programmes, du coup si ton realm est down, tous tes games ne pourront plus fonctionner (ou plutôt les actions des games ne seront plus sauvegardées correctement)...

java style =)

Link to comment
Share on other sites

bien sure que si, la connexion entre le realm et le game possède une file d'envois de donner. Une fois le realm relancer le game lui envois la suite.

Le problème d'avoir plusieurs connexion sur ta base de donnée vas renvoyer énormément d'erreur ou des données non mis a jour.

Le fait de tester seul ne permet pas de voir vraiment les problème liée a la base de donnée, mais arriver entre 50 a 100 joueurs tu ne pourras pas avoir deux joueurs simultané qui font une action qui requière la base de donnée.

 

Du coup je te conseil de tout charger au lancement et de communiquer entre tes serveurs.

Personnellement je travail mon émulateur comme ça et ça fonctionne très bien. Si mon realm est couper le game essaie toute les 30 secondes de ci reconnecter, une fois la connexion rétabli je demande a file d'attente de reprendre la ou elle en étais.

Sachant que mon game envois uniquement la création ou la suppression de personnage rien d'autre. Par contre le realm envois un peux plus de chose, le realm envois surtout les informations du compte (modérateur ou non), le ticket de connexion (2.0+), ...

Link to comment
Share on other sites

  • Retraité

J'avoue que les problèmes d'interblocage sont à prendre en compte. Cependant je n'y ai été confronté que récemment et le sujet datant un peu je n'y avais pas encore pensé.

 

Cela dit je n'aime pas l'idée d'une file d'attente pour l'aspect prise de mémoire mais aussi parce qu'en cas de problème et de non reconnexion du realm toutes ces données sont perdues (à moins d'enregistrer physiquement les requêtes).

java style =)

Link to comment
Share on other sites

Pourquoi le realm ne ce relancerais pas ? Apres si jamais c'est le cas tu peux mettre la config de la base de donnée du realm et si tu close ton game et qu'il n'est pas connecter tu envois les requêtes directement depuis ton game.

Link to comment
Share on other sites

  • Retraité

Il est possible de ne pas remarquer tout de suite que le serveur est down ou que suite à un problème d'hébergement il ne soit pas relancable dans l'immédiat. Cela dit c'est vrai qu'en sauvegardant les requêtes en cas de fermeture expresse du game, ca devient jouable.

 

Après un truc que je trouve dommage dans le client Dofus, c'est un gros manque de message box pour dire "Un problème imprévu est survenu", ou alors je l'ai pas encore trouvé... Pour ce genre de problème de déconnexion, signaler au joueur que les actions qu'il entreprend à partir de maintenant pourraient ne pas être sauvegardées, ce serait assez pratique

java style =)

Link to comment
Share on other sites

 Share



Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.