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

我有一个使用HttpURLConnection通过multipart/form-data内容类型上传文件的例程。服务器对上传的文件执行一些处理并返回一个简短的响应代码。这在所有情况下都可以正常工作，除非有一名用户在4G时使用HTC Evo。如果用户切换到3G，那么一切正常。在4G上时，应用程序将等待while ((line = reader.readLine()) != null) {，直到引发套接字连接超时异常为止。我有连接超时设置为70秒。该服务器是在PHP这里是有关片段挂在Sprint 4G网络上的HttpURLConnection readLine（）

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

注意“背景”响应工作，其余导致客户端坐，直到超时异常。我目前有2个概念，但我不在4G领域，所以我只能通过最终用户测试，我真的想限制尝试次数。我的第一个想法是'背景'比'失败QA'稍长，而另一个更长，它有一个数字开始。所以，也许增加空白的回应会有所帮助？另一方面是响应时间。 'BACKGROUND'消息通常比其他消息发送得更快。但是，我在这里有一个反例，所以我不是陛下。例如：'BACKGROUND'消息通常在15到20秒内熄灭。其他消息通常是30-40秒。但是，我举了一个例子，其中'1336757671374T37171FR'风格响应在24秒内熄灭，并且未收到，并且在27秒内收到“背景”消息。

所以总结一下：这只发生在Sprint 4G上。我怀疑这可能是造成问题的内容长度或响应时间，但在两种情况下，我都有相反的反例。除了长度大小的情况下，较长的计数器例子的数值开始，所以就是这样。

来源

2012-05-14 Andrew

我的第一个猜测是用户根本没有良好的4g连接，并且无法使用它连接到服务器。 – Shellum

@Chuck Norris - 行为（'BACKGROUND'工作，其他消息不工作）在20次尝试中是一致的。而且，在所有这些情况下，请求部分（带有文件上载）完成没有问题。所以，这似乎不是一个连接问题。这是我的第一个想法，但我相信我已经排除了。用户表示他们的4G连接上有完整的条形图，但不太确凿的证据。 – Andrew

@Chuck Norris - 也许我在这里仓促。我无法在任何地方找到的是这种行为是否适合一个微弱的信号。即文件总是成功上传，但在X秒后，4G信号变得足够低，从而失去了连接，但是没有意识到，因此仍然等待套接字超时。那可能吗？或者它可以实际上仍然连接，但只是错过响应数据包做噪声？ – Andrew

它似乎是导致问题的响应之前的延迟。我使用本指南Easy Parallel Processing in PHP来设置多任务php配置。通过这种方式，我有一个脚本，可以计算和回应经过的秒数，而另一个人执行作业处理。现在问题已解决。

来源

2012-05-17 17:58:58 Andrew

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

回答

相关问题