Jeu de cartes client-serveur au tour par tour - Unicast (TCP) ou Multicast (UDP)

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)

1. 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)

2. Le serveur reçoit des messages et met à jour l'état du jeu (le serveur conservera tout l'état du jeu).

3. Le serveur parcourt une liste de clients connectés et envoie un message pour les informer du changement d'état

4. 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!).

N'optimisez pas prématurément. Rester simple. L'utilisation de TCP dans ce cas est OK et je ne vois aucun problème avec votre schéma actuel.

UDP est généralement utilisé pour les scénarios critiques de performances comme dans un jeu d'action en ligne, car il permet un contrôle explicite sur les paquets individuels au lieu de travailler au-dessus d'une couche d'abstraction de flux comme TCP. Cependant, bien que vous ayez un certain gain de vitesse en contrôlant exactement la façon dont vous voulez que les données soient envoyées, UDP ne gère pas la perte de paquets ou l'ordre des paquets comme TCP, auquel cas vous devez le coder vous-même. Donc, comme il s'agit d'un jeu de cartes au tour par tour, je doute que vous souhaitiez sacrifier la fiabilité à la vitesse, alors utilisez TCP.

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 /