HttpURLConnectionを使用して、multipart/form-dataコンテンツタイプを介してファイルをアップロードするルーチンがあります。サーバーはアップロードされたファイルに対して何らかの処理を行い、短い応答コードを返します。これは、4GでHTC Evoを使用している1人のユーザーを除いて、これまでのすべてのケースで正常に機能します。ユーザーが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領域にいないので、これをテストできるのはエンドユーザーのみであり、試行回数を制限したいと考えています。私の最初の考えは、「BACKGROUND」は「FailedQA」よりもわずかに長く、もう一方は長いが数値で始まるということです。では、応答に空白を追加すると役立つでしょうか？もう1つの側面は応答時間です。'BACKGROUND'メッセージは通常、他のメッセージよりも速く送信されます。しかし、私はここに反例があるので、私は父ではありません。例：「BACKGROUND」メッセージは通常15〜20秒以内に消えます。他のメッセージは通常30〜40秒です。ただし、1つの例があります。
要約すると、これはSprint4Gでのみ発生します。問題の原因はコンテンツの長さまたは応答時間のいずれかである可能性がありますが、どちらの場合も、逆の反例があります。長さの場合を除いて、長い反例であるものは数字で始まるので、それがあります。