Клиент longpoll / comet на основе JVM: маршрутизаторы убивают простаивающие соединения

В настоящее время у меня есть сетевой клиент на основе JVM, который выполняет длинный HTTP-запрос (он же комета), используя стандартный java.net.HttpURLConnection. У меня установлен очень высокий таймаут для подключения (1 час). Для большинства пользователей это работает нормально. Но некоторые пользователи не получают данные, отправленные с сервера, и в конечном итоге время ожидания истекает через 1 час.

Моя теория заключается в том, что маршрутизатор (NAT) истекает по таймауту и ​​сбрасывает свои соединения, потому что они простаивают слишком долго, прежде чем сервер отправит какие-либо данные.

Тогда мои вопросы таковы:

Могу ли я включить поддержку TCP для соединений, используемых java.net.HttpURLConnection? Я не мог найти способ сделать это.

Есть ли другой API (отличный от HttpURLConnection), который я должен использовать вместо этого?

Другие решения?


java keep-alive long-polling httpurlconnection comet
person Dr.Haribo    schedule 29.08.2011    source источник

Ответы (2)


arrow_upward
0
arrow_downward

java.net.HttpURLConnection обрабатывает Keep-Alive заголовок прозрачно, он можно контролировать, по умолчанию он включен. Но ваша проблема не в Keep-Alive, который является флагом более высокого уровня, указывающим, что сервер должен закрыть соединение после обработки первого запроса, а скорее дождаться следующего.

В вашем случае, вероятно, что-то на нижнем уровне стека OSI прерывает соединение. Поскольку сохранение открытого, но неактивного TCP-соединения в течение такого длительного периода времени никогда не является хорошим выбором (протокол FTP с двумя открытыми соединениями: одно для команд и одно для данных имеет ту же проблему), я бы предпочел реализовать какое-то отключение / повторить отказоустойчивую процедуру на стороне клиента.

На самом деле безопасный предел, вероятно, составит всего несколько минут, а не часов. Просто активно отключайтесь от HTTP-сервера каждые 60 секунд или 5 минут. Должен сделать свое дело.

person Tomasz Nurkiewicz    schedule 29.08.2011
comment
Я имею в виду TCP keep-alive, а не HTTP keep-alive. Сервер обычно отвечает в течение 5-15 минут. Лишь у нескольких пользователей есть проблемы - моя теория заключается в том, что у них есть маршрутизаторы, которые более агрессивно уничтожают неактивные соединения. Вы правы, это поможет уменьшить таймаут. Но я бы предпочел, чтобы это работало с таймаутом в 20-30 минут, если это возможно. - person Dr.Haribo; 30.08.2011
comment
java.net.HttpURLConnection поддерживает только HTTP1.1, что означает, что соединения по умолчанию постоянны (в Keep Alive нет необходимости) - person Cratylus; 30.08.2011
comment
Поддержание активности TCP не предназначено для постоянных HTTP-соединений. Он заставляет ваш компьютер отправлять пакеты без каких-либо данных потока TCP через равные промежутки времени, поэтому неактивное соединение получает некоторый трафик. Я думаю, это может помешать маршрутизаторам разорвать соединение. - person Dr.Haribo; 30.08.2011

arrow_upward
0
arrow_downward

Похоже, что нет способа включить поддержку TCP для HttpURLConnection.

Apache HttpComponents станет вариантом, когда выйдет версия 4.2 с поддержкой TCP keep-alive.

person Dr.Haribo    schedule 13.01.2012