Was ist zu tun, wenn die Anforderung an den Server gesendet wird und die Internetverbindung unterbrochen wird, während auf die Antwort gewartet wird?

Ich sende eine große Datenmenge an den Server. Jetzt, während ich die Daten gesendet habe und auf die Antwort des Servers warte, verliert mein Android-Gerät plötzlich die Internetverbindung.
Früher habe ich einen Warndialog für Verbindungsverlust angezeigt, aber auf der Serverseite wurden die Daten bereits verarbeitet und irgendwo aktualisiert, z. B. auf einer beliebigen URL. Aber mein Android-Handy weiß das nicht, da es nie eine Antwort bekommen hat. Wie man es löst.
Ob es auf dem Server oder auf Android selbst gemacht werden könnte, wie?
Woher weiß der Server, dass das Android-Telefon die Antwort nicht abhört?
Dies kann eine Perspektive zur Optimierung der Client-Server-Kommunikation sein.

— mayank_droid
quelle

Über wie viele Daten sprechen wir? Gigabyte?

— Daniel Hollinrake

Nicht viel zwischen 7 und 8 MB, aber die Antwortzeit auf dem Server ist zu lang und die Upload-Rate vom Telefon liegt bei 128 KB / s. Ich spreche nicht von Datengröße, sondern von Verbindungsproblemen.

— Mayank_Droid

Antworten:

Dies ist ein recht häufiges Problem bei asynchronen Transaktionen und gliedert sich in mehrere Teile.

Woher wissen beide Seiten, dass die Transaktionsanforderung erfolgreich empfangen wurde?
Wie können Sie eine Transaktionsanfrage erneut senden, von der der Kunde glaubt, dass sie nicht ordnungsgemäß empfangen wurde?
Wie erkennt der Server wiederholte Anforderungen vom Client, wenn der Server die erste Anforderung erfolgreich empfangen hat?
Woher weiß der Kunde, woher er die Transaktionsergebnisse bezieht?

Das Tolle an HTTP ist, dass es ziemlich einfach ist, all diese Probleme zu lösen.

Stellen Sie sich eine URL-Struktur wie diese vor:

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

Verwenden von HTTP-Post zum Senden einer Anforderung an den Server unter Verwendung einer eindeutigen Clientanforderungs-ID. Der Server antwortet dann mit der Job-ID. Wenn diese Antwort aus Client-Sicht nicht auftritt, muss die Anforderung erneut gesendet werden. Aus Sicht des Servers müssen die Client-Anforderungs-IDs einige Minuten zwischengespeichert werden, falls der Client doppelte Anforderungen sendet. Doppelte Anforderungen werden einfach bearbeitet, indem dieselbe Job-ID an den Client zurückgegeben wird.

Der Client erhält die Ergebnisse der Anforderung über die Ergebnis-URL. Dieser Aufruf kann beliebig oft wiederholt werden, um die Ergebnisse zu erhalten. Wenn es aufgerufen wird, bevor die Ergebnisse verfügbar sind, kann die Antwort eine NO-CONTENT-Antwort sein, sodass der Client weiß, dass der Server die Job-ID erkennt, aber noch nicht über den Inhalt verfügt. Wenn die Job-ID nicht erkannt wird, ist NOT-FOUND die geeignete Antwort.

Das Endergebnis ist, dass der Client immer eine sinnvolle Aktion ausführen kann, wenn das Netzwerk verloren geht und wiederhergestellt wird, und ebenso kann der Server Anforderungen vom Client immer sinnvoll verarbeiten

— Michael Shaw
quelle

Das, oder einfach eine kurze Anfrage nach einer Transaktions-ID, dann mehrere Anfragen, die der Transaktion Daten hinzufügen (Sie könnten die Übertragung hier in kleinere Teile aufteilen, um Teilbestätigungen zu erhalten), dann eine letzte "Festschreibungsanfrage". Sie können dann unterschiedliche Zeitlimits für vollständig leere Transaktionen (Client hat höchstwahrscheinlich keine ID erhalten), teilweise hochgeladene Transaktionen und Ergebnisse festlegen (wenn der Client die Ergebnisse nicht erhalten hat, wird möglicherweise die Festschreibungsanforderung wiederholt).

— Simon Richter

Dies würde die Situation handhaben, in der die Verbindung während der Übertragung der Anforderung unterbrochen wurde. Die gestellte Frage bezieht sich auf einen Verbindungsverlust, nachdem die Daten gesendet wurden, aber bevor die Verarbeitung der Anforderung abgeschlossen ist.

— Michael Shaw

Das wird auch gehandhabt. Die "Festschreibungs" -Transaktion ist klein und verwendet die Transaktions-ID. Sie kann daher kostengünstig erneut ausgegeben werden, ohne dass die Daten erneut übertragen werden müssen, und der Server kann entweder mit der Verarbeitung beginnen oder das Ergebnis des früheren Aufrufs zurückgeben. Dies ist dem, was Sie vorschlagen, sehr ähnlich. Der Unterschied besteht darin, dass ich eine separate Anforderung zum Erstellen der Job-ID habe, sodass ich einen zusätzlichen Synchronisierungspunkt habe, sodass der Client wissen kann, ob der Job bereits vorhanden ist, ohne die vollständige Anforderung erneut zu senden.

— Simon Richter

Ja, das macht Sinn.

— Michael Shaw

Wenn eine Transaktion Teildaten auf dem Server enthält, weiß ich, dass ein Client vorhanden ist, der diese ID kennt und versucht, die Transaktion abzuschließen. Auf diese Weise kann ich den Teilstatus beibehalten und anbieten, die Übertragung auf halbem Wege fortzusetzen, um den Bandbreitenbedarf zu minimieren und die zu entfernen müssen den Anforderungsinhalt vergleichen, um Duplikate zu finden.

— Simon Richter

Dies fällt unter die Grundlagen der Protokollkommunikation. Der Android-Client hat eine Transaktion angefordert, und der Server muss die Transaktion ausführen. Wenn die Transaktion von der Bestätigung des Android-Clients abhängt, ist dies die ACK / NAK-Kommunikation.

ACK (Acknowledgement) und NAK (Negative Acknowledgement) teilen der Gegenseite das Ergebnis einer Anfrage mit.

Sie fragen nach einer Art Handshake- Austausch zwischen Client und Server, der mit einem einfachen ACK / NAK-Austausch durchgeführt werden kann.

Hier ist ein Beispiel dafür, wie Android eine Datei mit bidirektionaler Bestätigung hochlädt.

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

Im obigen Beispiel habe ich einen #ideindeutigen Bezeichner für die Transaktion hinzugefügt . Der Server sollte die Dateien empfangen, einen Transaktionsdatensatz erstellen und diesen als Antwort an Android zurücksenden. Android sollte dann eine Bestätigung dieser Transaktion (oder alternativ eine NAK für eine Ablehnung) folgen.

Hier ist ein Beispiel für eine Android-Verbindung, die während des Handshakes getrennt wird.

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

Im obigen Beispiel hat der Server die hochgeladenen Dateien akzeptiert und eine #idACK-Antwort an Android zurückgesendet, Android antwortet jedoch nie mit einer ACK. Das Android-Gerät konnte den Handshake nicht abschließen. Sie müssen entscheiden, wie der Server damit umgehen soll. Zerstören Sie die Transaktion, behalten Sie die Transaktion bei und warten Sie, bis das Android-Gerät später zurückkehrt, oder schließen Sie die Transaktion trotzdem ab.

Der Server kann davon ausgehen, dass das Gerät nicht mit ACK geantwortet hat. Das Android-Gerät hat seinen internen Status nicht aktualisiert, um anzuzeigen, dass der Upload erfolgreich war. Ich würde die Transaktion verwerfen und dem Gerät erlauben, sie in Zukunft zu wiederholen.

— Reactgular
quelle