MQTT
Io faccio riferimento a questo strumento perché l'ho messo su e quindi è già pronto e disponibile. Mi è utile in contesti diversi, non solo chat.
Come dici giustamente tu, non è una stretta necessità nel contesto di Penny visto che hai attivi i ws.
Parto dal fondo, essendo mancino
(logica stringente).
So che hai lavorato con MQTT; quello che non so è se hai lavorato a sufficienza anche con websocket b4j, perché io vedo solo vantaggi, in questo, rispetto al primo. Secondo me se inizi a smanettare con i websocket, ti innamori e molli MQTT. Unico vero vantaggio che vedo in MQTT è che tu possa usare un broker "esterno", un servizio pubblico, senza quindi dover avere un tuo server, sia fisico che software. Però avrà dei costi e, soprattutto, hai poco controllo.
Vedrebbe la situazione aggiornata
La vedrebbe ma solo dopo l'esecuzione "bloccante" da parte del server (chiamiamola così, che sia la forzata disconnessione da parte del server oppure l'invio di uno stop da parte di questo).
Ecco, a stomaco pieno si ragiona... peggio. Una qualche idea mi era venuta proprio mangiando
.
[pausa - rifflessione - tentativo di ricordare...]
(c'è un piccolo tarlo che mi bucherella il cervelletto - non la zona specifica, proprio il cervello, di dimensioni minime
), ovvero il fatto che feci una prova, misi in background il client (app) Zynga e una volta ripreso, apparve la scritta "riconnessione..." e subito dopo vidi il nuovo stato. Fin qui tutto ok, logico e regolare; però vidi che il tempo a disposizione di un giocatore era X, ovvero erano passati alcuni secondi ed aveva ancora modo di giocare. Da dove prende quel valore il server? Ammesso che faccia partire un timer al proprio interno (classe-oggetto stanza), poi che fa, manda i singoli tick ogni secondo a tutti i client (cosa che avevo fatto anch'io) oppure invia solo il comando "tocca a tizio, fate partire i vostri timer"?
Va beh, ma ciò che avevo pensato masticando (!?!) era:
1) client perde connessione - ok, gli si manda tutto lo stato, ammesso che il gioco sia ancora in corso e che la stanza esista ancora;
2) client mette in pausa l'app - tutto come al punto precedente;
3) rallentamento. A me non interessa se l'utente vedrà azioni varie con ritardo fino al momento in cui... lui voglia eseguire un'azione (di gioco o non).
Solo a questo punto io, "server", devo prendere provvedimenti, non prima.
Questo potrebbe essere fatto proprio basandosi sul ID del comando.
Esempio (i numeri sono gli ID comando progressivi, io utente "ritardatario" sono giocatore3):
1) giocatore1 riceve il turno - comando inviato a tutti, me compreso, e l'app avvia animazione countdown;
2) giocatore2 manda un asino a giocatore4 - sempre comando per tutti e relativa animazione;
3) giocatore1 esegue la propria azione - sempre comando a tutti
4) giocatore2 riceve turno - ....
Se io, giocatore3, non decido, ad esempio, di inviare qualcosa mentre NON è il mio turno, il server deve fregarsene se io vedrò tutto quanto sopra istantaneamente o in ritardo.
Quando io decidessi di inviare qualcosa pur non avendo il turno oppure di compiere la mia azione possedendo il turno, il mio client invierà un comando con tanto di ID. Il server confronterà questo ID con l'ultimo che ha inviato a tutti i client; se la differenza fosse maggiore di 1, significherebbe che il mio client è in ritardo. A questo punto dovrebbe inviare un comando di "azzera tutto" e "questa è la nuova situazione" (praticamente queste sarebbero le stesse cose inviate in caso di disconnessione completa o riattivazione app).
Mi pare logico, ma tra il dire e il fare c'è di mezzo... la pratica.
N.B. Una volta pubblicata Penelope, metterò in vendita i sorgenti di server e client per la modica cifra di 999€; copie gratuite a qualche membro italiano
(sw in inglese).
P.S. a costo di perdere altro tempo (tanto so che lo perdo volutamente), ti invierò una base client-server,
@udg, per farti rendere conto di quanto sia semplice e più utile di MQTT.
