Cosa fare quando la richiesta viene inviata al server e durante l'attesa della risposta si perde la connettività Internet?

Sto inviando un'enorme quantità di dati al server. Ora mentre ho inviato i dati e aspetto la risposta del server, all'improvviso il mio dispositivo Android perde la connessione a Internet.
Quindi quello che ero solito fare è mostrare una finestra di avviso di connessione persa, ma sul lato server i dati erano già stati elaborati e aggiornati da qualche parte su qualsiasi URL. Ma il mio telefono Android non lo sa perché non ha mai ricevuto risposta. Come risolverlo
Se potrebbe essere fatto sul lato server o su Android stesso Come?
Come server saprebbe che il telefono Android non ascolterà la risposta?
Potrebbe essere una prospettiva di ottimizzazione della comunicazione client-server.

— mayank_droid
fonte

Di quanti dati stiamo parlando? Gigabyte?

— Daniel Hollinrake,

Non ci sono 7-8 MB in giro, ma il tempo di risposta del server è troppo lungo e la velocità di caricamento dal telefono è di circa 128 KB / S. Non sto parlando di dimensioni dei dati ma di problemi di connessione.

— mayank_droid,

Risposte:

Questo è un problema abbastanza comune con le transazioni asincrone e si divide in più parti.

Come fanno entrambe le parti a sapere che la richiesta di transazione è stata ricevuta con successo?
Come si reinvia una richiesta di transazione che il cliente ritiene non sia stata ricevuta correttamente?
In che modo il server rileva le richieste ripetute dal client quando il server ha ricevuto correttamente la prima richiesta?
Come fa il cliente a sapere da dove ottenere i risultati della transazione?

La cosa grandiosa di HTTP è che è abbastanza facile risolvere tutti questi problemi.

Immagina una struttura URL come questa:

POST http://my.server.com/application/engine/queue 
OTTIENI   http://my.server.com/application/engine/results?jobid=43425

Utilizzo di HTTP post per inviare una richiesta al server, utilizzando un ID richiesta client univoco e fare in modo che il server risponda con l'ID lavoro. Dal punto di vista dei clienti, se questa risposta non si verifica, è necessario inviare nuovamente la richiesta. Dal punto di vista dei server, è necessario che gli ID di richiesta del client vengano memorizzati nella cache per alcuni minuti, nel caso in cui il client invii richieste duplicate. Le richieste duplicate vengono gestite semplicemente restituendo lo stesso ID lavoro al client.

Il client ottiene i risultati della richiesta dall'URL dei risultati. Questa chiamata può essere ripetuta tutte le volte che è necessario per ottenere i risultati. Se viene chiamato prima che i risultati siano disponibili, la risposta potrebbe essere una risposta SENZA CONTENUTO in modo che il client sappia che il server riconosce l'ID lavoro ma non ha ancora il contenuto. Se l'ID lavoro non viene riconosciuto, NOT-FOUND è la risposta appropriata.

Il risultato finale è che il client può sempre compiere un'azione sensata quando la rete viene persa e ripristinata, e allo stesso modo il server può sempre elaborare le richieste dal client in modo ragionevole

— Michael Shaw
fonte

Che, o semplicemente facendo una breve richiesta che richieda un ID transazione, quindi diverse richieste che aggiungono dati alla transazione (è possibile suddividere il trasferimento in blocchi più piccoli qui, per ottenere riconoscimenti parziali), quindi una richiesta finale di "commit". È quindi possibile avere diversi timeout per transazioni completamente vuote (il client molto probabilmente non ha ricevuto l'ID), transazioni parzialmente caricate e risultati (se il client non ha ricevuto i risultati, potrebbe ritentare la richiesta "commit").

— Simon Richter,

Ciò gestirà la situazione in cui si è persa la connessione durante la trasmissione della richiesta. La domanda posta riguarda la connessione persa dopo l'invio dei dati, ma prima che l'elaborazione della richiesta sia stata completata.

— Michael Shaw,

Anche questo è gestito. La transazione "commit" è piccola e utilizza l'ID transazione, quindi può essere riemessa in modo economico senza ritrasmettere i dati e il server può iniziare l'elaborazione o restituire il risultato dall'invocazione precedente. Questo è molto simile a quello che stai suggerendo; la differenza è che ho una richiesta separata per creare l'ID lavoro, quindi ho un punto di sincronizzazione aggiuntivo, in modo che il client possa sapere se il lavoro esiste già senza ritrasmettere la richiesta completa.

— Simon Richter,

sì, ha senso.

— Michael Shaw,

In questo modo, se una transazione contiene dati parziali sul server, so che esiste un client che conosce questo ID e cerca di completare la transazione, quindi posso mantenere lo stato parziale e offrire di riprendere la trasmissione a metà, minimizzando i requisiti di larghezza di banda e rimuovendo il è necessario confrontare il contenuto della richiesta per trovare duplicati.

— Simon Richter,

Ciò rientra nelle basi della comunicazione del protocollo. È stata richiesta una transazione dal client Android e il server deve eseguire la transazione. Se la transazione dipende dal riconoscimento del client Android, questa è la comunicazione ACK / NAK.

ACK (riconoscimento) e NAK (riconoscimento negativo) vengono utilizzati per comunicare all'altro lato il risultato di una richiesta.

Quello che stai chiedendo è un tipo di scambio di handshaking tra client e server e può essere eseguito con uno scambio ACK / NAK di base.

Ecco un esempio di caricamento di un file Android con riconoscimento bidirezionale.

Android -> upload files -> Server
Android <- ACK #id <- Server
Android -> ACK #id -> Server

Nell'esempio sopra ho aggiunto un #ididentificatore univoco per la transazione. Il server dovrebbe ricevere i file, creare un registro delle transazioni e inviarlo come risposta ad Android. Android dovrebbe quindi seguire con un riconoscimento di tale transazione (o in alternativa un NAK per un rifiuto).

Ecco un esempio di disconnessione da Android durante l'handshaking.

Android -> upload files -> Server
Android <- ACK #id <- Server
/** no ACK response **/

Nell'esempio sopra, il server ha accettato i file caricati e ha inviato una #idrisposta ACK ad Android, ma Android non risponde mai con un ACK. Il dispositivo Android non è riuscito a completare l'handshaking. Sta a te decidere come il Server dovrebbe gestirlo. Distruggi la transazione, mantieni la transazione e attendi che il dispositivo Android restituisca in seguito o completi comunque la transazione.

Il server può presumere che dal momento che il dispositivo non ha risposto con ACK. Il fatto che il dispositivo Android non abbia aggiornato lo stato interno indica che il caricamento è andato a buon fine. Scarterei la transazione e consentirei al dispositivo di ripeterla in futuro.

— Reactgular
fonte