0

I have a routine that uses a HttpURLConnection to upload a file via a multipart/form-data content type. The server does some processing on the uploaded file and returns a short response code. This works fine in all cases so far except with one user with an HTC Evo when on 4G. If the user switches to 3G then everything works fine. When on 4G the app will wait on the while ((line = reader.readLine()) != null) { until a socket connection timeout exception is thrown. I have the connection timeout set to 70 seconds. The server is in php here is the relevant snippet

//all ob_ related entries were added because I found some info indicating
//that some clients would not acknowledge the response without the content-length header

ob_end_clean(); 
header("Connection: close");
ob_start();
...
//the response is one of either
echo "BACKGROUND"; //this one works!
//or
echo $rv //$rv = "1336757671374T37171FR"
//or
echo "FailedQA";

$size = ob_get_length();
header("Content-Length: $size");
ob_end_flush(); 
ob_flush();
flush();        
die();
?>

Note that the 'BACKGROUND' response works, and the rest cause the client to sit until the timeout exception. I have currently 2 notions on this, but I am not in a 4G area so I can only test this through the end user and I really want to limit the number of attempts. My first thought is that the 'BACKGROUND' is slightly longer than the 'FailedQA', and while the other one is longer it has a numeric start. So maybe adding white space to the response would help? The other aspect is response time. The 'BACKGROUND' message is normally sent faster than the other ones. But, I do have a counter example here so I am not sire. Example: the 'BACKGROUND' message normally goes out within 15 to 20 seconds. The other messages are normally 30-40 seconds. However, I have one example where the '1336757671374T37171FR' style response went out in 24 seconds and was not received and one where the 'BACKGROUND' message went out in 27 seconds and was received.

So to sum up: This only happens on Sprint 4G. I suspect it might either be content length or response time that is causing the issue, but in both cases I have a counter example to the contrary. Except with the length case the one that is the longer counter example has a numeric beginning, so there's that.

Andrew
  • 141
  • 4
  • 14
  • My first guess would be that the user simply does not have a good 4g connection and cannot hit the server using it. – Shellum May 14 '12 at 16:11
  • @Chuck Norris - The behavior ('BACKGROUND' working, and the other messages not working) is consistent over a sample of ~20 attempts. Also, in all of these cases the request portion (with a file upload) was completed without issue. So, it does not seem to be a connection issue. That was my first thought but I believe I have ruled it out. Of less solid evidence is the user stating that they have full bars on their 4G connection. – Andrew May 14 '12 at 16:57
  • @Chuck Norris - Perhaps I was hasty here. What I can't find anywhere is whether the behavior would fit with a weak signal. i.e. The file always gets uploaded successfully, but after X seconds the 4G signal gets low enough that it loses the connection but doesn't realize it and so still waits for a socket timeout. Is that possible? Or can it actually still be connected, but just miss the response packet do to noise? – Andrew May 16 '12 at 13:23
  • Other than android.telephony.SignalStrength tests, I can't confirm your suspicions. Look at the SignalStrength class and maybe it will help. – Shellum May 16 '12 at 14:56

1 Answers1

0

It seems to be the delay before a response that was causing the problem. I used this guide Easy Parallel Processing in PHP to set up a multi-tasking php configuration. This way I have a script that just counts and echos the elapsed seconds while the other one does the job processing. The problem is now resolved.

Andrew
  • 141
  • 4
  • 14