HttpURLConnection readLine() зависает в сети Sprint 4G

У меня есть процедура, которая использует HttpURLConnection для загрузки файла через тип содержимого multipart/form-data. Сервер выполняет некоторую обработку загруженного файла и возвращает короткий код ответа. Пока это работает нормально во всех случаях, за исключением одного пользователя с HTC Evo при подключении к 4G. Если пользователь переключается на 3G то все работает нормально. В 4G приложение будет ждать while ((line = reader.readLine()) != null) {, пока не будет выдано исключение тайм-аута подключения к сокету. У меня тайм-аут подключения установлен на 70 секунд. Сервер находится в php, вот соответствующий фрагмент

//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();
?>

Обратите внимание, что ответ 'BACKGROUND' работает, а остальные заставляют клиента сидеть до исключения тайм-аута. В настоящее время у меня есть 2 идеи по этому поводу, но я не нахожусь в зоне 4G, поэтому я могу проверить это только через конечного пользователя, и я действительно хочу ограничить количество попыток. Моя первая мысль заключается в том, что «ФОН» немного длиннее, чем «FailedQA», и хотя другой длиннее, он имеет числовое начало. Так может быть, добавление пробела к ответу поможет? Другой аспект — время отклика. Сообщение 'BACKGROUND' обычно отправляется быстрее, чем другие. Но у меня есть контрпример, так что я не сир. Пример: сообщение «ФОН» обычно выходит в течение 15–20 секунд. Другие сообщения обычно 30-40 секунд. Тем не менее, у меня есть один пример, когда ответ в стиле «1336757671374T37171FR» был отправлен через 24 секунды и не был получен, и один, где сообщение «ФОН» было отправлено через 27 секунд и было получено.

Подводя итог: это происходит только на Sprint 4G. Я подозреваю, что причиной проблемы может быть либо длина контента, либо время отклика, но в обоих случаях у меня есть противоположный пример. За исключением случая с длиной, тот, который является более длинным контрпримером, имеет числовое начало, так что вот оно.


person Andrew    schedule 14.05.2012    source источник
comment
Мое первое предположение будет заключаться в том, что у пользователя просто нет хорошего 4g-соединения и он не может подключиться к серверу, используя его.   -  person Shellum    schedule 14.05.2012
comment
@Chuck Norris - поведение («ФОН» работает, а другие сообщения не работают) соответствует выборке из ~ 20 попыток. Кроме того, во всех этих случаях часть запроса (с загрузкой файла) была выполнена без проблем. Так что проблема не в подключении. Это была моя первая мысль, но, кажется, я ее исключил. Менее веским доказательством является заявление пользователя о том, что у него есть полные полосы на их соединении 4G.   -  person Andrew    schedule 14.05.2012
comment
@ Чак Норрис - Возможно, я поторопился. Чего я нигде не могу найти, так это того, будет ли поведение соответствовать слабому сигналу. т. е. файл всегда успешно загружается, но через X секунд сигнал 4G становится настолько низким, что он теряет соединение, но не понимает этого и поэтому все еще ждет тайм-аута сокета. Это возможно? Или он может на самом деле все еще быть подключенным, но просто пропустить ответный пакет, сделать шум?   -  person Andrew    schedule 16.05.2012
comment
Кроме тестов android.telephony.SignalStrength, я не могу подтвердить ваши подозрения. Посмотрите на класс SignalStrength и, возможно, это поможет.   -  person Shellum    schedule 16.05.2012


Ответы (1)


Похоже, проблема была в задержке перед ответом. Я использовал это руководство Простая параллельная обработка в PHP, чтобы настройте многозадачную конфигурацию php. Таким образом, у меня есть скрипт, который просто подсчитывает и отображает прошедшие секунды, в то время как другой выполняет обработку задания. Теперь проблема решена.

person Andrew    schedule 17.05.2012