Соединения TCP зависают на состоянии CLOSE_WAIT
Клиент близко сокет сначала, когда нет большого количества данных из сервера, завершение работы соединения TCP, хорошо похож:
FIN -->
<-- ACK
<-- FIN, ACK
ACK -->
Когда сервер занимается передающие данные:
FIN -->
<-- ACK,PSH
RST -->
И серверное соединение прибывает в CLOSE_WAIT, указывают и держатся там в течение долгого времени.
Какова проблема здесь? клиент связан, или сервер связан? Это происходит на Redhat5 для локальных сокетов.
Этот разговор о статье о том, почему "RST" отправляется, но я не знаю, почему серверное соединение, застрявшее на CLOSE_WAIT, и, не отсылает FIN.
[РЕДАКТИРОВАНИЕ] я проигнорировал наиболее важную информацию, это происходит на slirp сетевой эмуляции qemu. Это, кажется, проблема slirp ошибки для контакта с близким соединением.
3 ответа
Это означает, что в потоке остались непрочитанные данные, которые клиент еще не закончил читать.
Вы можете принудительно отключить его, используя SO_LINGER вариант. Здесь имеется соответствующая документация для Linux (также см. Сам параметр, здесь ) и [вот функция сопоставления2] для Win32.
Это серверная сторона, которая остается открытой, поэтому на стороне сервера вы можете попробовать отключить SO_LINGER .
Это может означать, что сервер не закрыл сокет. Вы можете легко это определить, используя «lsof» для вывода списка файловых дескрипторов, открытых этим процессом, который будет включать сокеты TCP. Исправление состоит в том, чтобы процесс всегда закрывал сокет по завершении (даже в случаях ошибки и т. Д.)