Question

我有一个例程，它使用HttpURLConnection通过multipart / form-data内容类型上传文件。服务器对上传的文件进行一些处理并返回一个简短的响应代码。到目前为止，这种方法在所有情况下都能正常工作，除了一个用户在4G上使用HTC Evo。如果用户切换到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();
?>

请注意＆＃39; BACKGROUND＆＃39;响应有效，其余的使客户端坐到超时异常。我目前有2个概念，但我不在4G区域，所以我只能通过最终用户测试，我真的想限制尝试次数。我的第一个想法是＆＃39;背景＆＃39;比'FailedQA＆＃39;稍长，而另一个更长，它有一个数字开头。因此，为响应添加空格可能会有所帮助吗？另一方面是响应时间。＆＃39;背景＆＃39;消息通常比其他消息发送得更快。但是，我在这里有一个反例，所以我不是陛下。示例：＆＃39; BACKGROUND＆＃39;消息通常在15到20秒内消失。其他消息通常为30-40秒。但是，我有一个例子，其中＆＃39; 1336757671374T37171FR＆＃39;样式响应在24秒内消失，但没有收到，而且还有一个＆＃39; BACKGROUND＆＃39;消息在27秒内消失并被收到。

总结一下：这只发生在Sprint 4G上。我怀疑它可能是导致问题的内容长度或响应时间，但在这两种情况下我都有一个相反的例子。除了长度的情况，较长的计数器示例之一具有数字开头，所以就是这样。

Answer 1

似乎是导致问题的响应之前的延迟。我使用本指南Easy Parallel Processing in PHP来设置多任务php配置。这样我就有一个脚本，只需计算并回显经过的秒数，而另一个脚本完成作业处理。问题现在得到解决。

HttpURLConnection readLine（）挂在Sprint 4G网络上

1 个答案: