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.
2
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
8
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.