Любые случаи, где close () предпочтительнее shutdown ()?

Question

Я являюсь разработчиком проекта с открытым исходным кодом, и у меня возникли некоторые проблемы с сервером, который думал, что он полностью ответил на сокет (то есть он отправил ответ или закрыл свой конец в ответ на сбой) и клиент застрять в опросе (). После некоторых исследований я обнаружил, что close () не всегда генерирует событие POLLHUP, а shutdown (sock, 2) это делает.

В свете этого я рассматриваю возможность добавления shutdown (sock, 2) в случае обработки ошибок (в дополнение к вызову close ()). Кто-нибудь знает некоторые причины, по которым это может вызвать проблемы? Я лаю не на том дереве? Я думаю, что если сервер считает, что сокет закрыт, клиент определенно не должен пытаться делать что-либо еще с этим сокетом, и я не могу придумать причину не добавлять это, но я не работал с tcp связи на долгое время и хотелось бы несколько советов.

Answer 1

Вы должны выяснить, почему close при использовании сокета не приводит к shutdown. Наиболее вероятная причина в том, что существует другой дескриптор, который обращается к той же конечной точке. Только close в последней конечной точке приводит к неявному shutdown.

Вы когда-нибудь dup описатель файла? Вы уверены, что он равен close d во всех дочерних процессах? Если сокет находился в родительском процессе до того, как он fork редактировал этот процесс, закрыл ли родитель его копию?

Answer 2

POLLHUP - неправильный способ проверки замкнутого соединения.Вы должны проверить, чтобы дескриптор файла стал читаемым и впоследствии возвращал чтение нулевой длины.Это определение конца файла.