HttpURLConnection을 사용하여 multipart/form-data 콘텐츠 형식을 통해 파일을 업로드하는 루틴이 있습니다. 서버는 업로드 된 파일에 대해 일부 처리를 수행하고 짧은 응답 코드를 반환합니다. 이것은 4G에서 HTC Evo를 사용하는 한 명의 사용자를 제외하고 지금까지 모든 경우에 유효합니다. 사용자가 3G로 전환하면 모든 것이 정상적으로 작동합니다. 4G에서 소켓 연결 시간 초과 예외가 발생할 때까지 응용 프로그램은 while ((line = reader.readLine()) != null) {에서 대기합니다. 연결 시간 제한을 70 초로 설정했습니다. 서버는 여기에 PHP에있는 '배경'응답이 작동 관련 조각HttpURLConnection Sprint 4G 네트워크에 매달려있는 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 영역에 있지 않아 최종 사용자를 통해서만 테스트 할 수 있으며 실제로 시도 횟수를 제한하려고합니다. 저의 첫 번째 생각은 '배경'이 'FailedQA'보다 약간 길며, 다른 하나는 더 길지만 숫자 시작을가집니다. 그래서 응답에 공백을 추가하는 것이 도움이 될까요? 다른 측면은 응답 시간입니다. 'BACKGROUND'메시지는 일반적으로 다른 것보다 빠르게 전송됩니다. 그러나 나는 여기에 반대 표본을 가지고있어서 나는 폐하가 아니다. 예 : 'BACKGROUND'메시지는 일반적으로 15-20 초 내에 소등됩니다. 다른 메시지는 일반적으로 30-40 초입니다. 그러나 '1336757671374T37171FR'스타일의 응답이 24 초 만에 전달되어 수신되지 않은 사례와 'BACKGROUND'메시지가 27 초 만에 전달되어 수신 된 사례가 있습니다.
총계 : 이것은 Sprint 4G에서만 발생합니다. 콘텐츠 길이 또는 문제의 원인이되는 응답 시간이 의심 스럽지만 두 가지 경우 모두 반대로 반대 사례가 있습니다. 길이가 긴 경우를 제외하고 더 긴 카운터 예제는 숫자 시작 부분을 가지므로 그 부분이 있습니다.
내 첫 번째 추측은 사용자가 좋은 4g 연결이 없으며이를 사용하여 서버를 공격 할 수 없다는 것입니다. – Shellum
@Chuck Norris - 동작 ('BACKGROUND'작동 및 다른 메시지가 작동하지 않음)은 ~ 20 회 시도의 샘플에서 일관됩니다. 또한이 모든 경우 요청 부분 (파일 업로드 포함)은 문제없이 완료되었습니다. 따라서 연결 문제가 아닌 것 같습니다. 그것은 나의 첫 번째 생각 이었지만 나는 그것을 배제했다고 믿는다. 덜 확실한 증거는 사용자가 4G 연결에 전체 막대가 있음을 나타내는 것입니다. – Andrew
@Chuck Norris - 아마도 나는 여기서 성급했다. 내가 어디에서 찾을 수없는 것은 그 행동이 약한 신호에 맞는지 아닌지입니다. 즉 파일은 항상 성공적으로 업로드되지만 X 초 후에 4G 신호는 연결이 끊어 지지만 실제로 깨닫지 못하고 소켓 대기 시간 제한을 기다리고 있습니다. 그게 가능하니? 아니면 실제로 연결되어있을 수 있지만, 응답 패킷을 놓치지 마십시오. – Andrew