Que faire lorsque la demande est envoyée au serveur et en attendant la réponse La connectivité Internet est perdue?

J'envoie une énorme quantité de données au serveur. Maintenant, alors que j'ai envoyé les données et que j'attends la réponse du serveur, soudainement mon appareil Android perd sa connexion Internet.
Donc, ce que j'avais l'habitude de faire était d'afficher une boîte de dialogue d'alerte de perte de connexion, mais côté serveur, les données étaient déjà traitées et mises à jour quelque part, par exemple sur n'importe quelle URL. Mais mon téléphone Android ne le sait pas car il n'a jamais reçu de réponse. Comment le résoudre.
Que cela puisse être fait côté serveur ou sur Android lui-même Comment?
Comment le serveur saurait-il que le téléphone Android ne va pas écouter la réponse?
Il peut s'agir d'une perspective d'optimisation de la communication client-serveur.

— mayank_droid
source

De combien de données parlons-nous? Gigaoctets?

— Daniel Hollinrake

Pas beaucoup de 7 à 8 Mo, mais le temps de réponse du serveur est trop long et le taux de téléchargement depuis le téléphone est d'environ 128 Ko / S. Je ne parle pas de la taille des données mais d'un problème de connexion.

— mayank_droid

Réponses:

Il s'agit d'un problème assez courant avec les transactions asynchrones et qui se divise en plusieurs parties.

Comment les deux parties savent-elles que la demande de transaction a bien été reçue?
Comment renvoyez-vous une demande de transaction qui, selon le client, n'a pas été reçue correctement?
Comment le serveur détecte-t-il les demandes répétées du client lorsque le serveur a reçu avec succès la première demande?
Comment le client sait-il d'où obtenir les résultats de la transaction?

La grande chose à propos de HTTP est qu'il est assez facile de résoudre tous ces problèmes.

Imaginez une structure d'URL comme celle-ci:

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

Utiliser la publication HTTP pour envoyer une demande au serveur, en utilisant un identifiant de demande client unique - et demander au serveur de répondre avec l'ID du travail. Du point de vue des clients, si cette réponse ne se produit pas, la demande doit être renvoyée. Du point de vue des serveurs, l'ID de demande du client doit être mis en cache pendant quelques minutes, au cas où le client enverrait des demandes en double. Les demandes dupliquées sont traitées simplement en renvoyant le même ID de travail au client.

Le client obtient les résultats de la demande à partir de l'URL des résultats. Cet appel peut être répété autant de fois que nécessaire pour obtenir les résultats. Si elle est appelée avant que les résultats ne soient disponibles, alors la réponse pourrait être une réponse NO-CONTENT afin que le client sache que le serveur reconnaît l'ID du travail mais n'a pas encore le contenu. Si l'ID du travail n'est pas reconnu, NOT-FOUND est la réponse appropriée.

Le résultat final est que le client peut toujours effectuer une action sensible lorsque le réseau est perdu et récupéré, et de même le serveur peut toujours traiter les demandes du client de manière sensible

— Michael Shaw
source

Cela, ou simplement faire une courte demande demandant un ID de transaction, puis plusieurs demandes ajoutant des données à la transaction (vous pouvez diviser le transfert en plus petits morceaux ici, pour obtenir des accusés de réception partiels), puis une dernière demande de «validation». Vous pouvez alors avoir différents délais d'expiration pour les transactions complètement vides (le client n'a probablement pas reçu d'ID), les transactions partiellement téléchargées et les résultats (si le client n'a pas reçu les résultats, il peut réessayer la demande de «validation»).

— Simon Richter

Cela permettrait de gérer la situation où la connexion était perdue lors de la transmission de la demande. La question posée concerne la perte de connexion après l'envoi des données, mais avant le traitement de la demande.

— Michael Shaw

Cela est également géré. La transaction "commit" est petite et utilise l'ID de transaction, elle peut donc être réémise à moindre coût sans retransmettre les données, et le serveur peut soit commencer le traitement, soit renvoyer le résultat de l'invocation précédente. C'est très similaire à ce que vous proposez; la différence est que j'ai une demande distincte pour créer l'ID de travail, donc j'ai un point de synchronisation supplémentaire, afin que le client puisse savoir si le travail existe déjà sans retransmettre la demande complète.

— Simon Richter

oui, cela a du sens.

— Michael Shaw

De cette façon, si une transaction contient des données partielles sur le serveur, je sais qu'il existe un client qui connaît cet ID et essaie de terminer la transaction, donc je peux conserver l'état partiel et proposer de reprendre la transmission à mi-chemin, minimisant les besoins en bande passante et supprimant le besoin de comparer le contenu de la demande pour trouver des doublons.

— Simon Richter

Cela relève des principes de base de la communication protocolaire. Une transaction a été demandée par le client Android et le serveur doit effectuer la transaction. Si la transaction dépend de l'accusé de réception du client Android, appelez la communication ACK / NAK.

ACK (accusé de réception) et NAK (accusé de réception négatif) sont utilisés pour dire à l'autre côté le résultat d'une demande.

Ce que vous demandez, c'est un type d' échange de liaison entre le client et le serveur, et il peut être effectué avec un échange ACK / NAK de base.

Voici un exemple de téléchargement par Android d'un fichier avec accusé de réception bidirectionnel.

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

Dans l'exemple ci-dessus, j'ai ajouté un #ididentifiant unique pour la transaction. Le serveur doit recevoir les fichiers, créer un enregistrement de transaction et l'envoyer comme réponse à Android. Android devrait ensuite suivre avec un accusé de réception de cette transaction (ou alternativement un NAK pour un rejet).

Voici un exemple de déconnexion d'Android pendant la prise de contact.

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

Dans l'exemple ci-dessus, le serveur a accepté les fichiers téléchargés et renvoyé une #idréponse ACK à Android, mais Android ne répond jamais avec un ACK. L'appareil Android n'a pas pu terminer la négociation. C'est à vous de décider comment le serveur doit gérer cela. Détruisez la transaction, conservez la transaction et attendez que l'appareil Android revienne plus tard ou terminez la transaction de toute façon.

Le serveur peut supposer que puisque le périphérique n'a pas répondu avec ACK. Que l'appareil Android n'a pas mis à jour son état interne pour indiquer que le téléchargement a réussi. Je rejetterais la transaction et autoriserais l'appareil à la répéter à l'avenir.

— Reactgular
source