Messaggi persi su XMPP sul dispositivo disconnesso

Question

Sto provando a sviluppare un gioco di turno su XMPP. (L'unica soluzione che ho trovato per il gioco multipiattaforma). Posso inviare messaggi senza problemi. Se l'altro utente non è online, il server (OpenFire) lo salva per una consegna successiva.

Il problema si verifica quando un dispositivo cambia rete (passa da 3g a WiFi, cambia IP 3g ...) o il dispositivo perde la rete (disattiva 3g, wifi o connessione persa). Il server pensa che il dispositivo sia online e invia il messaggio, ma (ovviamente) non arriva mai, quindi il pacchetto è perso.

Conosco una soluzione. Implementa ACK sul mio protocollo di gioco, ma non mi piace molto questa idea. Hai qualche altro suggerimento? Penso che questo sia un problema del server. Conoscete un altro server che implementa TCP o ACK?

Grazie !!

MODIFICA: lo faccio: Connetti il ​​dispositivo al server. Abbasso la connettività 3G e WiFi al dispositivo. Android e il server continuano a pensare che la connessione sia attiva.

http://issues.igniterealtime.org/browse/SMACK-331

PD: chiedo di OpenFeint perché API Multigiocatore, ma non mi hanno asnwer ...

Answer 1

In alcune condizioni TCP/IP non è affidabile. Questo è il motivo per cui ACK, ricevute di messaggi, QI o altre estensioni in XMPP possono risolvere questo problema.

Ho fatto molti programmi di telefonia mobile nel corso degli anni, spesso anche con Openfire. Ma non ho visto messaggi persi. Quindi presumo che ci sia un problema sia nella libreria che stai usando su Android, sia nella versione Openfire che usi.

Invece di utilizzare socket raw è anche possibile utilizzare BOSH:
http://xmpp.org/extensions/xep-0124.html
BOSH si basa su WebRequests come Cometa e funziona molto bene in ambienti in cui si passa o perdere spesso la connessione. Può mantenere in vita la connessione fino a quando la rete è tornata e non si verifica un calo della connessione quando una o più richieste non riescono in una riga.

Answer 2

Sebbene BOSH funzioni probabilmente in questo caso, un'altra opzione è XEP-0198: Gestione flusso. Ciò ti consentirà di avere tutte le prestazioni di una presa completamente connessa, insieme a ricollegamenti rapidi, acrobazie positive e accodamenti mentre non sei collegato o disconnesso in entrambe le direzioni.

Answer 3

Anche io ho riscontrato questo problema e ho cercato di trovare un modo corretto per risolvere il problema.

Il problema per me è che ho impostato la politica dei messaggi non in linea su "Memorizza sempre" e quindi XEP-0184 non è di grande aiuto per determinare se un messaggio non viene recapitato al destinatario.

Fornire questo scenario: - ho 2 utenti in chat, li chiamano A e B - A invia B un messaggio durante la connessione di B appena si è perso - Il messaggio siamo lasciati e A non viene notificato - In questo caso a non sa che il messaggio siamo lasciati, sarà solo supporre che il messaggio viene recapitato al server, il server finirà per consegnarlo a B - B perde il messaggio sempre

Così ho mettere temporaneamente in un lavoro in giro per questo ... immagazzino tutti quei messaggi che non vengono consegnati (esnon hanno ricevuto la ricevuta di consegna del messaggio) in una coda, quindi periodicamente (ad esempio, 6 minuti - è il momento in cui le connessioni morte vengono cancellate) controlla ogni messaggio della coda per vedere se il destinatario previsto è "Online" E la ricevuta ancora non ricevuto ... Se è il caso, quindi contrassegno tale messaggio come "Consegna non riuscita"

Questo è un modo piuttosto terribile per risolverlo (si prega di avvisare se si dispone di un modo migliore di farlo). Penso che la cosa migliore da fare sia fare in modo che il server faccia ciò: se il messaggio non è stato consegnato e il criterio dei messaggi offline è "Always Store", lo memorizziamo su "ofoffline" per la consegna ritardata.

Answer 4

Questo è un vecchio, ma stavo risolvendo un problema di recente. Mi ha aiutato quando ho impostato la risorsa XMPP (l'ultima parte del JID completo) su qualcosa di ragionevole, quando si creava la connessione. Altrimenti sarà generato casualmente su ogni riconnessione e questo cambierà il JID completo.