07-05-2011, 12:00 AM
J'avais pensé à adopter l'approche de Facebook, à savoir un paramètre qui est juste une chaîne encodée (que le site et/ou le service est capable de décoder), mais tout ça me semble bien compliqué pour si peu. Les clés dont je parle sont échangées entre 2 serveurs : ça ne se spoof pas aussi facilement qu'un ordinateur ! Et HTTPS arrangera le reste.
@ Tyc (bienvenue, au passage) : ton approche est globalement celle que j'ai choisie, à quelques différences près :
Voilà, voilà, j'espère que ma réponse t'aura éclairé sur les intérêts d'un service qui en sait peu et qui est capable de stocker.
@ Tyc (bienvenue, au passage) : ton approche est globalement celle que j'ai choisie, à quelques différences près :
- C'est le serveur du jeu qui envoie les ordres de construction au service, pas le navigateur du client : ceci évite que la personne puisse ajouter ce qu'il veut comme il veut, et même que d'autres personnes puissent ajouter des choses au nom d'autres. À moins de développer le jeu entièrement avec NodeJS, ici, le service n'a pas conscience des joueurs : il ne voit que des queues et ce qu'elles contiennent.
- Utiliser un outil de stockage (ici, j'utilise Redis car c'est terriblement performant puisque ça ne travaille qu'en RAM) permet de stocker l'état de la queue : ton système ne peut pas gérer une queue au sens propre : avec des éléments qui s'enchaînent les uns après les autres.
- Quand un compteur arrive à terme, NodeJS envoie une requête HTTP au serveur de jeu : le jeu fait alors ce qu'il a à faire avec ça : libre à lui de le retransmettre au navigateur client (via du push, par exemple).
Voilà, voilà, j'espère que ma réponse t'aura éclairé sur les intérêts d'un service qui en sait peu et qui est capable de stocker.