2013-02-17 1 views
1

Une application d'échecs à faible latence est-elle possible avec Rails? Le cadre de Rails est principalement orienté vers être afaik apatrie. Une approche pour implémenter des échecs dans Rails serait donnée un mouvement (la "demande"), lire la position actuelle de la base de données, vérifier que le mouvement est valide dans la position actuelle et calculer la nouvelle position, écrire ce nouveau position à la base de données, et l'envoyer à l'autre joueur.Chess Rails application avec une faible latence possible?

Ceci a l'avantage d'être sans état car rien n'est conservé en mémoire entre les requêtes. Mais cela implique de récupérer la position actuelle de la base de données à chaque fois. Et vraisemblablement ce sera un coup significatif sur la latence. Supposons que les positions des jeux soient maintenues en mémoire. Un mouvement met à jour cette position en mémoire et envoie une réponse à l'autre joueur. Après quoi la base de données est mise à jour. Si les jeux sont répartis sur plusieurs processus Unicorn/Thin/Mongrel, comment les requêtes seront-elles routées vers le processus Unicorn correct pour ce jeu? Ai-je besoin d'un processus de routage entre mon processus Nginx/Lighty/Apache et mes processus Unicorn/Thin/Mongrel avec une table qui mappe les jeux sur leur partition Unicorn correcte?

Ce type de problème me semble être quelque chose que beaucoup d'autres ont dû rencontrer. Existe-t-il une manière idiomatique de le faire dans Rails? Pourquoi ne stockez-vous pas tout cela dans une file d'attente de messages comme RabbitMQ ou Redis?

+1

Je ne pense pas que stocker l'état du jeu dans la RAM est une bonne idée - sans la persistance offerte par dbms vos données peuvent être perdues à tout moment temps ... Pourquoi pensez-vous que l'extraction de l'état de jeu de DB donnera une faible latence? – 907th

+0

Je voulais dire que, après la mise à jour de l'état du jeu dans la RAM, la base de données est également mise à jour. J'ai édité mon post pour ajouter cela. – user782220

+0

Pour moi, il semble que la latence DB ne sera pas le problème pour une telle application. Si vous voulez des opérations db asynchrones - vous devriez donc regarder [EventMachine] (https://github.com/eventmachine/eventmachine) ou [node.js] (http://nodejs.org/) + protocole websockets – 907th

Répondre

0

Pourquoi ne stockez-vous pas tout cela dans une file d'attente de messages comme RabbitMQ ou Redis? Les files d'attente de messages sont persistantes et performantes. Ce Railscast utilise beanstalkd (une autre file d'attente de messages) pour introduire une application très similaire à la vôtre: http://railscasts.com/episodes/243-beanstalkd-and-stalker

Questions connexes