Actualmente estoy planeando hacer un proyecto de juego de cartas donde los clientes se comunicarán con el servidor de forma sincronizada y por turnos utilizando mensajes enviados a través de sockets. El problema que tengo es cómo manejar el siguiente escenario:
(El cliente toma el turno y envía su acción al servidor)
El cliente envía un mensaje diciéndole al servidor su movimiento para el turno (por ejemplo, juega la carta 5 de su mano que debe colocarse sobre la mesa)
El servidor recibe mensajes y actualiza el estado del juego (el servidor contendrá todo el estado del juego).
El servidor itera a través de una lista de clientes conectados y envía un mensaje para informarles sobre cambios en el estado
Todos los clientes se actualizan para mostrar el estado
Todo esto se basa en el uso de TCP, y mirándolo ahora parece un poco el patrón Observador. La razón por la que esto parece ser un problema para mí es que este mensaje no parece ser punto a punto como los demás, ya que quiero enviarlo a todos los clientes, y no parece muy eficiente enviar el mismo mensaje en de esa manera.
Estaba pensando en usar la multidifusión con UDP para poder enviar el mensaje a todos los clientes, sin embargo, ¿no significa esto que los clientes en teoría podrían enviarse mensajes entre ellos? Por supuesto, también existe el aspecto síncrono, aunque supongo que esto podría colocarse sobre el UDP.
Básicamente, me gustaría saber qué sería una buena práctica, ya que este proyecto realmente se trata de aprender, y aunque no será lo suficientemente grande como para enfrentar problemas de rendimiento, me gustaría considerarlos de todos modos.
Sin embargo, tenga en cuenta que no estoy interesado en usar middleware orientado a mensajes como solución (¡Tengo experiencia con el uso de MOM y estoy interesado en considerar otras opciones que excluyan MOM si los sockets TCP son una mala idea!).
Incluso muchos MMO grandes y populares utilizan TCP exclusivamente. Hará todo lo que necesite con todas las características de eficiencia que necesita.
UDP requiere mucha complejidad adicional, la multidifusión requiere aún más complejidad, y no obtendrá nada de ellos. Si solo está interesado en aprender, haga una demostración técnica para usted, pero no piense que el proyecto en sí mismo estará mejor de alguna manera.
Si está interesado en usar UDP, su primera tarea básicamente será volver a implementar TCP sobre UDP, solo para asegurarse de que realmente comprende cómo lidiar con todos los problemas que TCP resuelve para usted: congestión control, retransmisión de paquetes perdidos, manejo duplicado retrasado, pedido de paquetes, protocolo de enlace de conexión confiable, secuencia de desconexión confiable, etc.
No es necesariamente difícil resolver todo eso, pero requiere una comprensión profunda de las redes, el protocolo IP y cómo se resuelven esos problemas.
A partir de ahí, la creación de la biblioteca para ofrecer características que TCP carece es donde realmente comienza la diversión. Usar un flujo de mensajes multiplexado sobre un flujo de paquetes, un control de congestión más eficiente, manejo de límite de velocidad, canales múltiples, configuración del canal (si el canal requiere mensajes en orden o no, si se permiten paquetes descartados, etc.), etc.
Te sugiero que leas la siguiente serie de artículos. No es perfecto y hace algunas afirmaciones muy cuestionables (comenzando con su sinsentido "nunca use TCP en juegos"), pero sus detalles técnicos son útiles para los nuevos programadores de red: http://gafferongames.com/networking-for-game- programadores / udp-vs-tcp /
fuente