Имеем 2 копма в разных "С" подсетях: комп01 и комп02
Операционка - Винды. (если не ошибаюсь 2к чего-то, думаю не принципиально)
Кроме всего прочего, на компе01 работает некий серверный процесс а на компе02 некий клиентский процесс (который в свою очередь является сервлетом под томкатом ) . После ок. (чуть более) недели работы , на сервере видим ок. 60 сокетов , а на клиенте - 2 (для этого приложения + 4 ещё ).
Протираем глаза, выполняем netstat -a на 2х компах и видим явное несоответсвие .... на коме01 соединений гораздо больше ...
Протираем глаза ещё раз, кусаем себя за руку -просыпаемся окончательно.
Перезагружаем комп02 , на компе01 соединения видны как ESTABLISHED.
Идём к психатру - диагноз "здоров" ...
Соединения-приведения на компе01 (кот. не показаны на компе02) исчезают только посля перезапуска серверного процесса на компе01 , но через полдня начинают опять появлятся соединения-привидения
Клиент говорит, всё в порядке , всё остальное работает и это типа наши глюки (приложения , о кот. идёт речь - наши, всё происходит у клиента... инфы о инфраструктуре сети - минимум)
Сетевые глюки... Нетворк админы - есть идеи ?
-
- Уже с Приветом
- Posts: 4412
- Joined: 06 Nov 2003 17:03
- Location: TX
Сетевые глюки... Нетворк админы - есть идеи ?
А ты почему не радуешься?
-
- Уже с Приветом
- Posts: 569
- Joined: 14 Dec 2003 04:06
- Location: Львов->Киев->Торонто
Если количество открытых соединений растет со временем значит клиент не закрывает по какой то причине соединение.
Если есть возможность измените протокол приложения что бы клиент делал регулярный "ping" сервера, а сервер вел таблицу кто когда пинговался и регулярно отстреливал соединения которые на протяжении некоторого времени не подавали признаков жизни. Или сервер пусть посылает клиентам какие нибудь тестовые сообщения, если клиент мертв то tcp стек сам закроет такое соединение по time-out.
<added>
Ваше проблема происходит от того что вы не знаете об особенности tcp соединения оставаться открытым сколь угодно долго без какого либо трафика. То есть если одна сторона тихо умерла или закрыла соединение пока не было связи то другая сторона об этом никогда и не узнает. Технологию проверки жива ли другая сторона необходимо реализовывать в протоколе уровня приложения.
</added>
Если есть возможность измените протокол приложения что бы клиент делал регулярный "ping" сервера, а сервер вел таблицу кто когда пинговался и регулярно отстреливал соединения которые на протяжении некоторого времени не подавали признаков жизни. Или сервер пусть посылает клиентам какие нибудь тестовые сообщения, если клиент мертв то tcp стек сам закроет такое соединение по time-out.
<added>
Ваше проблема происходит от того что вы не знаете об особенности tcp соединения оставаться открытым сколь угодно долго без какого либо трафика. То есть если одна сторона тихо умерла или закрыла соединение пока не было связи то другая сторона об этом никогда и не узнает. Технологию проверки жива ли другая сторона необходимо реализовывать в протоколе уровня приложения.
</added>
Никакой разрухи нет. (с) Проф. Преображенский.
-
- Уже с Приветом
- Posts: 4412
- Joined: 06 Nov 2003 17:03
- Location: TX
Спасибо за ответ , но ....
1. Клиент как раз их закрывает. И на компе клиента комп02 их нет .
Я понимаю, что добавление keepalive в протокол поможет решить проблему ...
Только вот менять протокол из-за одной глючной конфигурации никто не будет ...
2.Про особенность тсп оставаться открытым сколько угодно я знаю...
А вот про особенность тсп оставаться открытым только с одной стороны - в первый раз слышу... Т.е. так чтобы netstat с одной стороны не показывает коннекта , а с другой - ESTABLISHED (не FIN_WAIT, не CLOSE_WAIT ,а именно ESTABLISHED )
Всю жизнь было если один peer закрывает коннект , то read/select на противоположном вне зависимости от языка уведомляется тем или иным способом ... да и нетстат всё видит... Или это очередные глюки винды ?
Если не секрет , откуда инфа , что
1. Клиент как раз их закрывает. И на компе клиента комп02 их нет .
Я понимаю, что добавление keepalive в протокол поможет решить проблему ...
Только вот менять протокол из-за одной глючной конфигурации никто не будет ...
2.Про особенность тсп оставаться открытым сколько угодно я знаю...
А вот про особенность тсп оставаться открытым только с одной стороны - в первый раз слышу... Т.е. так чтобы netstat с одной стороны не показывает коннекта , а с другой - ESTABLISHED (не FIN_WAIT, не CLOSE_WAIT ,а именно ESTABLISHED )
Всю жизнь было если один peer закрывает коннект , то read/select на противоположном вне зависимости от языка уведомляется тем или иным способом ... да и нетстат всё видит... Или это очередные глюки винды ?
Если не секрет , откуда инфа , что
?если одна сторона тихо умерла или закрыла соединение пока не было связи то другая сторона об этом никогда и не узнает.
А ты почему не радуешься?
-
- Уже с Приветом
- Posts: 569
- Joined: 14 Dec 2003 04:06
- Location: Львов->Киев->Торонто
Дед Мороз wrote:Спасибо за ответ , но ....
1. Клиент как раз их закрывает. И на компе клиента комп02 их нет .
Я понимаю, что добавление keepalive в протокол поможет решить проблему ...
Только вот менять протокол из-за одной глючной конфигурации никто не будет ...
2.Про особенность тсп оставаться открытым сколько угодно я знаю...
А вот про особенность тсп оставаться открытым только с одной стороны - в первый раз слышу... Т.е. так чтобы netstat с одной стороны не показывает коннекта , а с другой - ESTABLISHED (не FIN_WAIT, не CLOSE_WAIT ,а именно ESTABLISHED )
Всю жизнь было если один peer закрывает коннект , то read/select на противоположном вне зависимости от языка уведомляется тем или иным способом ... да и нетстат всё видит... Или это очередные глюки винды ?
Если не секрет , откуда инфа , что?если одна сторона тихо умерла или закрыла соединение пока не было связи то другая сторона об этом никогда и не узнает.
Я уже давно не махал шашкой, в смысле не програмировал tcp но насколько я помню если програмно не закрывать сокет то никакого пакета закрытия послано не будет. Так же если приложение было убито из task manager или упало то то же самое, tcp fin послан не будет. Далее, если были проблемы со связью то клиент пытался послать пакет завершения связи, обломался и закрыл свой сокет. Потом связь восстановилась, на клиенте сокета нет а на сервере есть.
То есть то что на клиенте нет сокетов открытых не значит что он их закрыл на сервере.
Это не конфигурация глючная, а природа tcp. Ну не поддерживает он проверку канала. И если это не предусмотрено в приложении то это ошибка.
Никакой разрухи нет. (с) Проф. Преображенский.
-
- Уже с Приветом
- Posts: 13316
- Joined: 13 Jun 1999 09:01
- Location: Yekaterinburg -> Montreal
Strannik223 прав, однако незачем протокол приложения менять, когда можно все это сделать на уровне ТСР, есть ключи в реестре и для keepalive, и для разных таймаутов для открытых сокетов и пр. Это чтобы проблему замазать. Все эти таймауты по умолчанию уже имеют некие конечные значения которые удовлетворяют средним серверным требованиям, то что привидения появляются чересчур быстро говорит о том что Ваш клиент неправильно заканчивает соединения.
-
- Уже с Приветом
- Posts: 569
- Joined: 14 Dec 2003 04:06
- Location: Львов->Киев->Торонто
Ага, точно есть такое SO_KEEPALIVE:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/setsockopt_2.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/setsockopt_2.asp
Никакой разрухи нет. (с) Проф. Преображенский.
-
- Уже с Приветом
- Posts: 13316
- Joined: 13 Jun 1999 09:01
- Location: Yekaterinburg -> Montreal
-
- Уже с Приветом
- Posts: 13316
- Joined: 13 Jun 1999 09:01
- Location: Yekaterinburg -> Montreal