I am sending a huge amount of data to server. Now while I have sent the data and waiting for server response, suddenly my android device gets internet connection lost.
So what I used to do is, showing an alert dialog of connection lost, but at server side the data was already processed and it updated somewhere e.g. on any URL. But my android phone does not know this as it did not get response ever. How to resolve it.
Whether it could be done on server side or on android itself How?
How server would know that android phone is not going to listen the response?
It may be client-server communication optimization perspective.
What to do when request is sent to server and while waiting for response internet connectivity lost?
-
How much data are we talking about? Gigabytes?– Daniel HollinrakeOct 2, 2013 at 11:04
-
Not much 7-8 MB around, but server response time is too long, and uploading rate from phone is around 128 KB/S. I am not talking about data size but connection problem.– mayank_droidOct 2, 2013 at 11:21
Add a comment
|
2 Answers
This is a fairly common problem with asynchronous transactions, and falls into several parts.
- How do both sides know that the transaction request has been successfully received?
- How do you resend a transaction request that the client believes has not been received properly?
- How does the server detect repeat requests from the client when the server successfully received the first request?
- How does the client know where to get the transaction results from?
The great thing about HTTP is that its fairly easy to solve all of these issues.
Imagine a URL structure like this:
POST http://my.server.com/application/engine/queue GET http://my.server.com/application/engine/results?jobid=43425
Using HTTP post to send a request to the server, using a unique client request id - and have the server respond with the job ID. From a clients perspective, if this response does not occur, then the request needs to be resent. From a servers perspective client request id's need to be cached for a few minutes, in-case the client sends duplicated requests. Duplicated requests are handled simply by returning the same job ID to the client.
The client gets the results of the request from the results URL. This call can be repeated as often as needed to get the results. If its called before the results are available, then the response could be a NO-CONTENT response so the client knows that the server recognises the job id but does not have the content yet. If the job id is not recognised then NOT-FOUND is the appropriate response.
End result is that the client can always make a sensible action when the network is lost and recovered, and likewise the server can always process requests from the client sensibly
answered Oct 2, 2013 at 11:46
-
3That, or simply doing a short request asking for a transaction ID, then several requests adding data to the transaction (you could split the transfer into smaller chunks here, to get partial acknowledgements), then a final "commit" request. You can then have different timeouts for completely empty transactions (client most likely did not receive ID), partially uploaded transactions, and results (if the client did not receive the results, it may retry the "commit" request). Oct 2, 2013 at 15:19
-
That would manage the situation where the connection was being lost during the transmission of the request. The question as asked is talking about connection lost after the data was sent, but before processing the request has completed. Oct 2, 2013 at 15:23
-
1That is also handled. The "commit" transaction is small and uses the transaction ID, so it can be reissued cheaply without retransmitting the data, and the server can either start processing, or return the result from the earlier invocation. This is very similar to what you are suggesting; the difference is that I have a separate request to create the job ID, so I have an additional synchronisation point, so the client can know whether the job already exists without retransmitting the full request. Oct 2, 2013 at 16:03
-
-
This way, if a transaction contains partial data on the server, I know that a client exists that knows this ID and tries to complete the transaction, so I can keep the partial state and offer to resume transmission halfway, minimizing bandwidth requirements and removing the need to compare request content to find duplicates. Oct 2, 2013 at 16:12
This falls under the basics of protocol communication. A transaction has been requested by the Android client, and the Server has to perform the transaction. If the transaction is dependant upon the Android client acknowledgment than this is call ACK/NAK communication.
ACK (acknowledgment) and NAK (negative-acknowledgment) are used to tell the other-side the result of a request.
What you are asking about is a type of handshaking exchange between the client and server, and it can be performed with a basic ACK/NAK exchange.
Here is an example of Android uploading a file with two way acknowledgment.
Android -> upload files -> Server
Android <- ACK #id <- Server
Android -> ACK #id -> Server
In the above example I've added a #id unique identifier for the transaction. The server should receive the files, create a transaction record and send that as the response back to Android. Android should then follow with an acknowledgement of that transaction (or alternatively a NAK for a rejection).
Here is an example of an Android disconnecting during the handshaking.
Android -> upload files -> Server
Android <- ACK #id <- Server
/** no ACK response **/
In the above example the Server has accepted the uploaded files and sent a #id ACK response back to Android, but Android never responds with an ACK. The Android device has failed to complete the handshaking. It's up to you to decide how the Server should handle this. Destroy the transaction, keep the transaction and wait for the Android device to return later or complete the transaction anyway.
The Server can assume that since the device did not respond with ACK. That the Android device did not update it's internal state to indicate that the upload was successful. I would discard the transaction and allow the device to repeat it in the future.
answered Oct 2, 2013 at 12:19
