09-12-2018, 11:57 PM
Ah, présenté ainsi, pour moi, le websocket n'a pas les règles métier (les règles du jeu) dans sa base de connaissances. C'est donc nécessairement la machin à état qui gère cela.
Si je fais le parallèle avec ma propre archi, le Websocket est remplacé par mon code PHP de site, et la machine à état par la BDD (au fond, la BDD est une machine à état, donc dans les faits, c'est même exactement le même cas). Tout ce que le PHP (le websocket) se charge alors de faire, c'est de récupérer le message du client (la requête HTTP), de vérifier la structure des données (ie: 104 est bien un integer positif strict) et de le passer à la BDD. Charge alors à elle de vérifier les règles du jeu, et, dans mon cas, si elles sont violées alors la BDD ne change pas d'état (ROLLBACK). Elle remonte une erreur à son client (= au PHP, via SIGNAL + un identifiant de l'erreur, comme "No such card available"), qui va alors transcrire ça en un message d'erreur potable pour le client final ("Une erreur serveur est survenue", ou, si je veux être plus précis, "La carte demandée (104) n'est pas disponible"). Cette transcription est indispensable pour logger les éventuelles erreurs non-attendues, mais aussi (et surtout) pour formatter correctement l'erreur que la BDD a sortie (que ce soit en la "masquant", pour juste dire "HTTP 500", ou en la détaillant, pour dire qu'une planète de Variispace a été détruite entre le moment où le joueur a affiché la page du jeu et le moment où le serveur a reçu la requête de déplacement d'une flotte spatiale par exemple).
Si je fais le parallèle avec ma propre archi, le Websocket est remplacé par mon code PHP de site, et la machine à état par la BDD (au fond, la BDD est une machine à état, donc dans les faits, c'est même exactement le même cas). Tout ce que le PHP (le websocket) se charge alors de faire, c'est de récupérer le message du client (la requête HTTP), de vérifier la structure des données (ie: 104 est bien un integer positif strict) et de le passer à la BDD. Charge alors à elle de vérifier les règles du jeu, et, dans mon cas, si elles sont violées alors la BDD ne change pas d'état (ROLLBACK). Elle remonte une erreur à son client (= au PHP, via SIGNAL + un identifiant de l'erreur, comme "No such card available"), qui va alors transcrire ça en un message d'erreur potable pour le client final ("Une erreur serveur est survenue", ou, si je veux être plus précis, "La carte demandée (104) n'est pas disponible"). Cette transcription est indispensable pour logger les éventuelles erreurs non-attendues, mais aussi (et surtout) pour formatter correctement l'erreur que la BDD a sortie (que ce soit en la "masquant", pour juste dire "HTTP 500", ou en la détaillant, pour dire qu'une planète de Variispace a été détruite entre le moment où le joueur a affiché la page du jeu et le moment où le serveur a reçu la requête de déplacement d'une flotte spatiale par exemple).