Discussion :

[ChatCureuil]

Bonjour,

Je viens de me lancer dans un petit projet personnel de jeu multijoueur avec un serveur Java WebSocket utilisant la lib Tyrus.

J'ai de l'expérience dans le développement, mais très peu en Java et surtout pas en application multi-threading, alors je me pose des questions basiques :

Chaque ServerEndPoint (la connexion avec le client WebSocket côté serveur) peut lire et écrire sur des objets qu'il partage avec les autres ServerEndPoint (les modèles du jeu, qui stockent l'état de la partie), et en regardant dans le débogueur je vois que chacun est susceptible de s'exécuter sur son propre thread "Grizzly-worker", donc à priori je devrais rendre mon code thread-safe, mais n'y connaissant rien je me dis que Tyrus gère peut-être ça de son côté, pour rendre les ServerEndPoint thread-safe ? Est-ce seulement possible ?

J'ai fait quelques recherches mais rien trouvé de spécifique sur Tyrus, pour l'instant je lis de la doc sur les threads et je me demande comment je vais pouvoir gérer ça. Par exemple quand je créé un message pour le client en lisant les données d'un modèle, il faudrait empêcher un autre thread client de modifier ce modèle pendant la création du message. Actuellement chaque ServerEndPoint accède aux modèles, peut-être devrais-je ajouter un adaptateur entre les ServerEndPoint et les modèles, et qui synchronize les accès aux modèles ?

Des questions de débutant je vous dis... mais Ô combien importantes, surtout que je risque de devoir refactoriser assez large si j'ai pas choisi la bonne conception...

[thelvin]

Hello,

je me dis que Tyrus gère peut-être ça de son côté, pour rendre les ServerEndPoint thread-safe ? Est-ce seulement possible ?

Possiblement si c'est lui qui fournit les classes des objets manipulés. Si c'est toi, alors non, il est impossible pour qui que ce soit d'autre que toi de les rendre thread-safe.

Actuellement chaque ServerEndPoint accède aux modèles, peut-être devrais-je ajouter un adaptateur entre les ServerEndPoint et les modèles, et qui synchronize les accès aux modèles ?

C'est de loin le plus simple. Mais forcément ça marche pas quand on a des millions d'accès aux données en même temps.

En général quand on veut passer à l'échelle il faut prévoir un modèle de cohérence concurrente des données. Mais bon ça dépend énormément de ce qu'on essaie de faire au juste.

[ChatCureuil]

Merci pour la réponse. En effet ça paraît logique que le framework ne fasse rien pour moi, sinon ce serait un goulet d'étranglement et plus aucun intérêt d'utiliser les threads... Mais bon, n'y connaissant pas grand chose, ta réponse m'enlève les derniers doutes.

Mon appli c'est du poker, donc jeu coup-par-coup, ça limite la casse niveau concurrence mais il y a une gestion des spectateurs, et c'est surtout eux, en se connectant, qui peuvent lire l'état de la table pendant qu'il est modifié par un joueur.
Et il y a aussi les connections/déconnections, qui ajoutent/suppriment les joueurs à une collection qui est parcourue notamment pour l'envoie de quasi tous les messages serveur->client.
Et une collection qui liste toutes les parties en cours, en ajoute de nouvelles pour le matchmaking, supprime les parties abandonnées, place les joueurs dans l'une ou l'autre...

Après quelques lectures, pour les connections/déconnections j'ai l'impression que je pourrais m'en sortir en utilisant les collections thread-safe et en ajoutant un synchronized sur les méthodes addUser/removeUser.

Et pour la sérialisation des messages, peut-être que je peux les faire construire entièrement par le modèle concerné dans une méthode synchronized ?
Je ne suis pas sûr d'avoir tout compris sur les thread... ^^ Par exemple si GameModel a une méthode changeData() (qui change les données ^^) et une getGameState() (qui les récupère dans un objet Message), est-ce que mettre un synchronized sur getGameState() va mettre en attente les appels de changeData() ? Ou faut-il utiliser les méthodes wait() et notify() ?...

Ma dernière grosse interrogation est au sujet des tests unitaires, comme je ne suis pas sûr de ce qui va merder dans mon appli tout ça me paraît un peu flou et j'aimerais mettre l'appli en défaut avec des tests, histoire de savoir ce que je corrige...
Pour l'instant j'ai trouvé cet article, que je vais essayer d'appliquer à mon code...

Je me permets de mettre le code de mon projet, si jamais des gens ont du temps pour regarder le code des autres et critiquer... Le ServerEndPoint est fr.chatcureuil.pokerplatform.socket.GameUser et les events qu'il envoie sont captés par des commandes (les mappings event->command sont dans fr.chatcureuil.pokerplatform.Mappings) comme fr.chatcureuil.pokerplatform.socket.command.GameUserConnectedCommand qui ajoute l'utilisateur dans une partie. Je vais sûrement commencer mes tests thread-safe par ici...