vendredi 25 janvier 2008

L'architecture est prête

Un peu de code ajouté, beaucoup de code retiré, et me voilà avec un début d'architecture prometteur. Au démarrage, 10 threads sont lâchés dans la nature. Chacun se connecte à la base de données, et écoute sur la queue venant du serveur. Il aurait été (théoriquement) possible de garder l'ensemble dans un seul thread, en utilisant les méthodes asynchrones de réseau et d'accès à la base de données, mais cela aurait été beaucoup plus compliqué. La queue des évènements, notamment, est triviale lorsqu'elle est basée sur un mutex et une condition!

jeudi 17 janvier 2008

La base de données

Je me suis peut-être trop concentré sur la séparation entre l'accès aux donnés d'une part, et la sérialization sur le disque lorsque le système est éteint. Le système actuel charge l'ensemble des données en début de session, et recharge périodiquement certaines donnés qui pourraient changer sur le disque (les comptes, par exemple). Pourtant, il existe une autre solution, qui est d'avoir un serveur presque totalement acontextuel, et d'accéder aux données directement dans la base de données. C'est l'occasion de mieux utiliser les capacités d'accès concurrent de la base de données: le temps de réponse à la requête d'un client sera probablement plus long, mais en revanche il sera possible de paralléliser les requêtes pour une meilleure montée en charge.

D'une part, chaque serveur doit maintenir une série de processus (potentiellement légers) chacun associé à une connexion à la base de données. Une tâche, c'est à dire une requête d'un client ou un évènement interne, sera donné au prochain processus libre, qui ira l'exécuter sur la base de données. Pendant que la base de données tourne, un autre processus peut recevoir une autre requête et l'exécuter à son tour sur la base de données.

D'autre part, à condition de s'assurer que les serveurs ne sont pas contextuels, il est possible de multiplier les serveurs, et de les faire se connecter à la même base de données. Une grosse machine faisant tourner la base, avec de bons accès réseau à d'autres machines plus modestes faisant chacune tourner un serveur, devrait permettre une bonne montée en charge.

samedi 5 janvier 2008

Bonne année!

Bonne année à tous, 2008 c'est beau, ses chiffres ne sont que des puissances de 2. Si ça ce n'est pas une preuve que l'année qui s'annonce sera binaire!

En parlant de binaire, mes plus gros soucis sont actuellement de mettre au point ce système de collision basé sur les cubes (le code que j'ai écrit jusqu'à présent est moche, ce qui est une forte indication qu'on doit pouvoir faire mieux), et l'architecture générale, avec notamment des réflexions sur comment ajouter un moteur pour commerce (pour l'instant, je pense à quelque chose de très similaire à un système boursier). On est pas sortis...