Потоки сокетов Java неожиданно заканчиваются - PullRequest
2 голосов
/ 01 ноября 2009

У меня есть приложение, обрабатывающее несколько соединений сокетов Java с различными типами удаленных машин (некоторые ПК, другие являются встроенными устройствами). Эти сокеты и потоки не должны закрываться бесконечно, за исключением очень веской причины (например, сбой удаленной системы).

Я часто сталкиваюсь с проблемой, когда входной поток неожиданно завершается без какой-либо причины (значение равно -1), то есть удаленный компьютер не сообщает об обрыве соединения. Но когда я отбрасываю чтение -1 и продолжаю чтение из потока, удаленный компьютер на самом деле отправляет новые данные позже. Это может продолжаться очень долго. Я также все еще могу писать в выходной поток тоже.

В текущей ситуации у меня есть выбор между обработкой -1 как концом потока и закрытием сокета (с ложными срабатываниями), или игнорированием ввода -1 и риском не быть уведомленным о реальных разъединениях.

Мне не удалось создать рабочий пример этой проблемы, и проблемы появляются случайным образом.

Есть идеи, что не так?

Отредактировано, чтобы добавить: Конечная точка Java - это перезапись существующего приложения VB, у которого не было этих проблем (по крайней мере, насколько мне известно).

Ответы [ 4 ]

1 голос
/ 01 ноября 2009

Если вы получите -1, означающее, что поток закрыт, вы не сможете читать дальше и найти больше данных. Как только поток закрыт, он не может быть прочитан снова.

Звучит так, будто вы выполняете чтение () и приводите его к байту. Это означает, что вы не можете определить разницу между значением 255 (которое вы можете прочитать за пределами) и значением закрытого потока -1 (которое вы не можете)

0 голосов
/ 01 ноября 2009

Очевидно, что в вашей среде есть проблемы с сетью, и вы можете попытаться отследить их, но пока безопаснее закрыть поток и снова открыть его . Это то, что предполагает API.

0 голосов
/ 01 ноября 2009

Вы когда-нибудь использовали Wireshark? Его очень легко настроить, и он может дать вам знать, если что-то необычное происходит с разговором по TCP, когда это произойдет.

Однажды у меня было нечто похожее на вашу проблему, и я решил ее, посылая сообщение ping каждую минуту между сервером и клиентом. (Позже выяснилось, что проблема с брандмауэром иногда закрывала половину соединения, если в течение 10 минут по нему не проходил трафик.)

Я знаю, что вы делаете сообщения KeepAlive, но возможно, что что-то на маршруте их не поддерживает. Если вы отправите свое собственное ping-сообщение с несколькими байтами, вы можете быть уверены. В обоих случаях я собираю фактические пакеты с обоих концов с помощью Wireshark, чтобы убедиться, что сообщения KeepAlive действительно достигают конечной точки.

0 голосов
/ 01 ноября 2009

Проверьте роутеры inbewteen. Для дешевых маршрутизаторов, особенно для тех, кто использует NAT, характерно, что они время от времени очищают свои таблицы соединений, в результате чего ваши соединения устаревают.

В любом случае ваше приложение должно быть устойчивым к этим вещам (они произойдут снова), и вы можете помочь ему, регулярно отправляя пакеты без деловой ценности по сети.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...