Je prévois actuellement de faire un projet de jeu de cartes où les clients communiqueront avec le serveur au tour par tour et de manière synchrone en utilisant des messages envoyés via des sockets. Le problème que j'ai est de savoir comment gérer le scénario suivant:
(Le client prend son tour et envoie son action au serveur)
Le client envoie un message indiquant au serveur son coup pour le tour (par exemple joue la carte 5 de sa main qui doit être placée sur la table)
Le serveur reçoit des messages et met à jour l'état du jeu (le serveur conservera tout l'état du jeu).
Le serveur parcourt une liste de clients connectés et envoie un message pour les informer du changement d'état
Les clients sont tous rafraîchis pour afficher l'état
Tout cela est basé sur l'utilisation de TCP, et en le regardant maintenant, cela ressemble un peu au modèle Observer. La raison pour laquelle cela semble être un problème pour moi est que ce message ne semble pas être point à point comme les autres car je veux l'envoyer à tous les clients, et ne semble pas très efficace pour envoyer le même message dans de cette façon.
Je pensais à utiliser la multidiffusion avec UDP, car je pourrais alors envoyer le message à tous les clients, mais cela ne signifierait-il pas que les clients pourraient en théorie se transmettre des messages? Il y a bien sûr l'aspect synchrone également, bien que cela puisse être placé au-dessus de l'UDP, je suppose.
Fondamentalement, je voudrais savoir ce qui serait une bonne pratique car ce projet est vraiment une question d'apprentissage, et même s'il ne sera pas assez important pour rencontrer des problèmes de performance, j'aimerais les considérer de toute façon.
Cependant, veuillez noter que je ne suis pas intéressé à utiliser un middleware orienté message comme solution (j'ai de l'expérience avec MOM et je suis intéressé à envisager d'autres options à l'exclusion de MOM si les sockets TCP sont une mauvaise idée!).
Même de nombreux grands MMO populaires utilisent exclusivement TCP. Il fera tout ce dont vous avez besoin avec toutes les caractéristiques d'efficacité dont vous avez besoin.
UDP nécessite beaucoup de complexité supplémentaire, la multidiffusion nécessite encore plus de complexité et vous n'allez rien en retirer. Si vous êtes juste intéressé par l'apprentissage, préparez certainement une démonstration technologique pour vous-même, mais ne pensez pas que le projet lui-même sera en aucune façon mieux à cause de cela.
Si vous souhaitez utiliser UDP, votre toute première tâche consistera essentiellement à réimplémenter TCP par-dessus UDP, juste pour vous assurer que vous comprenez réellement comment gérer tous les problèmes que TCP résout pour vous: congestion contrôle, retransmission de paquets perdus, traitement des doublons retardés, commande de paquets, prise de contact de connexion fiable, séquence de déconnexion fiable, etc.
Il n'est pas nécessairement difficile de résoudre tous ces problèmes, mais cela nécessite une compréhension approfondie de la mise en réseau, du protocole IP et de la manière dont ces problèmes sont résolus.
À partir de là, la création de la bibliothèque pour offrir des fonctionnalités qui manquent à TCP est l'endroit où le plaisir commence vraiment. Utilisation d'un flux de messages multiplexé sur un flux de paquets, contrôle plus efficace de l'encombrement, gestion des limites de débit, multicanaux, configuration du canal (si le canal nécessite ou non des messages dans l'ordre, si les paquets abandonnés sont autorisés, etc.), etc.
Je vous suggère de lire la série d'articles suivante. Ce n'est pas parfait et fait quelques affirmations très discutables (à commencer par son non-sens "ne jamais utiliser TCP dans les jeux"), mais ses détails techniques sont utiles aux nouveaux programmeurs de réseau: http://gafferongames.com/networking-for-game- programmeurs / udp-vs-tcp /
la source