Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[win32] веменное решение для 5000 close_wait 01.02.07 08:32 Число просмотров: 5178
Автор: void <Grebnev Valery> Статус: Elderman
|
Есть приложения - сервер и клиент, написанные не мной. Исходники есть, весьма сложные.
История болезни:
Сервер периодически периодически перестаёт работать (клиент не может соединиться).
Диагностика мне не известна, и холопов до барского кода не допускают подебагить.
Тем не менее, мне надоб выдать рекомендации, как привязать костыли, чтоб работало, а баре-девелоперы ревью код потом сделают.
Что я мог посмотреть, и что стало ясно 100% - сервер не закрывает сокеты. Это видно потысячам(может 4000 а может и 10000) соединениям на серверной стороне в состояни CLOSE_WAIT, которые живут своей жизнью днями (нетрудно смотриться netstat -a > 1.txt). На клиентах, возможно есть соответствующие FIN_WAIT, но не долго и это не критично.
Чтобы я предложил, и что даст эффект сразу же:
1) - серверный сокет перевести в _isetopt( socket, SO_KEEPALIVE, TRUE );
Смысл в том, что это только одно место в коде, где код фиксится в секунду. К томуже - это ни кого ни к чему не обязывает по дальнейшей логике и не приведёт потенциально к скруап аппликации.
2) В реестре задать KeepAliveTime = 3000 ms. Тоже не критично для аппликаций на этом компьютере. Кроме того, там, на этом компьютере, ни кто ни в одной аппликации не использует keepalive TCP опции.
ПС.
Проверил на простых тестовых клиент/сервер аппликациях - работает железно. Стек TCP стек Windows автоматически прикрывает все соединения CLOSE_WAIT в 10-20 секунд.
Прошу высказаться. Девелоперы смогут пересмотреть код только через неделю-месяц?, а надо, чтоб заработало завтра и без крашей. Вот я и думаю подсказать им такое временное решение.
Спасибо.
|
- [win32] веменное решение для 5000 close_wait - void 01.02.07 08:32 [5178]
|
|
|