Gioco di carte client-server a turni - Unicast (TCP) o Multicast (UDP)

Attualmente sto progettando di realizzare un progetto di gioco di carte in cui i client comunicheranno con il server in modo a turni e sincrono utilizzando i messaggi inviati tramite socket. Il problema che ho è come gestire il seguente scenario:

(Il client fa il turno e invia la sua azione al server)

1. Il client invia un messaggio dicendo al server la sua mossa per il turno (ad esempio, gioca la carta 5 dalla sua mano che deve essere posizionata sul tavolo)

2. Il server riceve messaggi e aggiorna lo stato del gioco (il server manterrà tutto lo stato del gioco).

3. Il server scorre attraverso un elenco di client connessi e invia un messaggio per informarne il cambio di stato

4. Tutti i client si aggiornano per visualizzare lo stato

Tutto questo si basa sull'uso di TCP, e guardandolo ora sembra un po 'come il modello Observer. Il motivo per cui questo sembra essere un problema per me è che questo messaggio non sembra essere punto-punto come gli altri come voglio inviarlo a tutti i clienti e non sembra molto efficiente inviare lo stesso messaggio in quel modo.

Stavo pensando di utilizzare il multicasting con UDP, in quanto avrei potuto inviare il messaggio a tutti i client, tuttavia ciò non significherebbe che i client sarebbero in teoria in grado di scambiarsi messaggi? C'è ovviamente anche l'aspetto sincrono, anche se questo potrebbe essere messo in cima all'UDP, credo.

Fondamentalmente, vorrei sapere quali sarebbero le buone pratiche in quanto questo progetto riguarda davvero l'apprendimento, e anche se non sarà abbastanza grande per incontrare problemi di prestazioni da questo, vorrei considerarli comunque.

Tuttavia, tieni presente che non sono interessato a utilizzare il middleware orientato ai messaggi come soluzione (ho esperienza con l'utilizzo di MOM e sono interessato a considerare altre opzioni che escludono MOM se i socket TCP sono una cattiva idea!).

Non ottimizzare prematuramente. Mantienilo semplice. L'uso di TCP in questo caso è OK e non vedo alcun problema con il tuo schema attuale.

UDP viene solitamente utilizzato per scenari critici in termini di prestazioni, ad esempio in un gioco d'azione online, poiché consente il controllo esplicito dei singoli pacchetti anziché lavorare su un'astrazione a strati di flussi come TCP. Tuttavia, sebbene tu abbia un certo guadagno di velocità controllando esattamente come desideri che i dati vengano inviati, UDP non gestisce la perdita di pacchetti o l'ordinamento di pacchetti come TCP, nel qual caso devi codificarli tu stesso. Quindi, poiché si tratta di un gioco di carte a turni, dubito che vorrai sacrificare l'affidabilità sulla velocità, quindi usa TCP.

Anche molti MMO famosi e di grandi dimensioni utilizzano esclusivamente TCP. Farà tutto il necessario con tutte le caratteristiche di efficienza richieste.

UDP richiede molta ulteriore complessità, il multicast richiede ancora più complessità e non ne ricaverete nulla. Se sei solo interessato all'apprendimento, organizza sicuramente una demo tecnica per te, ma non pensare che il progetto stesso sarà in alcun modo migliore grazie a questo.

Se sei interessato a utilizzare UDP, la tua prima attività sarà sostanzialmente quella di reimplementare TCP sopra UDP, solo per assicurarti di capire davvero come affrontare tutti i problemi che TCP risolve per te: congestione controllo, ritrasmissione dei pacchetti persi, gestione duplicata ritardata, ordinamento dei pacchetti, stretta di mano di connessione affidabile, sequenza di disconnessione affidabile, ecc.

Non è necessariamente difficile risolverli tutti, ma richiede una profonda conoscenza della rete, del protocollo IP e di come questi problemi vengono risolti.

Da lì, costruire la libreria per offrire funzionalità che mancano a TCP è dove inizia davvero il divertimento. Utilizzo di un flusso di messaggi multiplexato su un flusso di pacchetti, controllo della congestione più efficiente, gestione del limite di velocità, multi canali, configurazione del canale (se il canale richiede messaggi nell'ordine o meno, se i pacchetti rilasciati sono consentiti, ecc.) E così via.

Suggerirei di leggere le seguenti serie di articoli. Non è perfetto e fa alcune affermazioni molto discutibili (a partire dal suo "non usare mai TCP nei giochi"), ma i suoi dettagli tecnici sono utili ai nuovi programmatori di rete: http://gafferongames.com/networking-for-game- programmatori / UDP-vs-tcp /