Действительно ли java.net.Socket.setSoTimeout надежный?

С JavaDoc для setSoTimeout Действительно ли java.net.Socket.setSoTimeout надежный?

Включение/выключение SO_TIMEOUT с заданного тайм-аута в миллисекундах. С этой опцией, установленной на ненулевой тайм-аут, вызов read() в InputStream, связанный с этим гнездом , будет блокировать только для этой суммы времени. Если истекает время ожидания, то java.net.SocketTimeoutException - , но Socket по-прежнему действителен. Опция должна быть активирована перед тем, как ввести операцию блокировки . Тайм-аут должен быть> 0. Тайм-аут нуля равен , интерпретируемому как бесконечный тайм-аут.

Из различных сообщений в Интернете я прочитал, что SO_TIMEOUT весьма ненадежна при использовании гнездо C API (например, here).

Следовательно, вопрос, можно ли использовать setSoTimeout для проверки сеансов бегства?

Если нет, то какие техники вы можете порекомендовать установить ограничение времени на сеансы сокетов?

источник

2009-11-09 Alexander Pogrebnyak

Не знаю какой-либо актуальной текущей/текущей операционной системы, на которой (потоковой) тайм-аут сокета не работают так, как они предполагают. Сообщение, на которое вы ссылаетесь, связано с довольно запутанным плакатом, который пытается установить тайм-аут отправки в сокете датаграммы, что совершенно не имеет смысла. Датаграммы либо отправляются немедленно, либо молча отбрасываются.

источник

2009-11-09 23:57:59 jarnbjo

+1 - Связанный пост действительно очень смущен. В дополнение к таймауту в UDP ерунде, он, кажется, думает, что вы должны иметь возможность отправлять произвольно большие UDP-датаграммы. –

Проверьте классы подключения в Java 6 nio, теперь они включают в себя сокеты и выполняют неблокирующую операцию, поэтому вы можете отменить операцию, если хотите.

Apache htmlclient core (?) Теперь может использовать nio-сокеты, поэтому, похоже, они получили эту концепцию. Тем не менее, это все, что я знаю об этом.

источник

2009-11-09 23:12:50

Но независимо от того, будут ли nio сокеты работать должным образом на ОС со сломанным сетевым стеком, все догадываются ... –

Не только вы можете отменить операцию nio, но и Selector.select (long timeout). – Seth

Вы можете это гарантировать? На машине с ** сломанным сетевым стеком? Я бы сказал, что вы не можете, потому что не можете предположить, что syscall, который реализует select, будет корректно работать для сокета. –

Мне неизвестно любая платформа для платформы современных платформ, чей сетевой стек настолько сломан, что таймауты сокетов не работают. Но если кто-нибудь знает пример реальной жизни, добавьте его в качестве комментария!

Я бы не стал беспокоиться об этом сценарии, если вы на самом деле не обязаны поддерживать ваше приложение на такой сломанной ОС. Я подозреваю, что это будет болезненное упражнение.

источник

2009-11-10 00:14:00

Ссылка о SO_RCVTIMEO. Речь идет о Socket.setSoTimeout(). На единственной платформе я знаю, где первое не работает (некоторые версии Solaris), последний сбрасывается с помощью select(), который работает. Контракт метода требует этого. Тебе не нужно беспокоиться об этом, если кто-то на самом деле не придумает платформу, где я никогда не видел ее за 16 лет.

источник

2013-03-20 11:18:41 EJP

Обратите внимание, что даже в Linux setSoTimeout не устанавливает параметр SO_RCVTIMEO. Вместо этого значение тайм-аута сохраняется внутри, а JRE использует системный вызов опроса для реализации таймаута чтения. –

Действительно ли java.net.Socket.setSoTimeout надежный?

ответ

Смежные вопросы