close () не закрывает гнездо правильно

Вот несколько кодов, которые я использовал во многих Unix-подобных системах (например, SunOS 4, SGI IRIX, HPUX 10.20, CentOS 5, Cygwin), чтобы закрыть сокет:

 int getSO_ERROR(int fd) { int err = 1; socklen_t len = sizeof err; if (-1 == getsockopt(fd, SOL_SOCKET, SO_ERROR, (char *)&err, &len)) FatalError("getSO_ERROR"); if (err) errno = err; // set errno to the socket SO_ERROR return err; } void closeSocket(int fd) { // *not* the Windows closesocket() if (fd >= 0) { getSO_ERROR(fd); // first clear any errors, which can cause close to fail if (shutdown(fd, SHUT_RDWR) < 0) // secondly, terminate the 'reliable' delivery if (errno != ENOTCONN && errno != EINVAL) // SGI causes EINVAL Perror("shutdown"); if (close(fd) < 0) // finally call close() Perror("close"); } } 

Но вышеописанное не гарантирует отправку буферизованных записей.

Изящное закрытие: мне потребовалось около 10 лет, чтобы выяснить, как закрыть розетку. Но еще 10 лет я просто лениво называл usleep(20000) за небольшую задержку, чтобы «обеспечить», чтобы буфер записи был сброшен до закрытия. Это, очевидно, не очень умно, потому что:

• Задержка была слишком длинной большую часть времени.
• Задержка была слишком коротка в течение некоторого времени - может быть!
• Сигнал, такой SIGCHLD может произойти, чтобы закончить usleep() (но я обычно usleep() дважды, чтобы обработать этот случай - взломать).
• Не было никаких признаков того, работает ли это. Но это, возможно, не важно, если: a) жесткие сбрасывания в порядке, и / или b) у вас есть контроль над обеими сторонами ссылки.

Но делать правильный флеш удивительно сложно. Использование SO_LINGER по-видимому, не способ; см., например:

• http://msdn.microsoft.com/en-us/library/ms740481%28v=vs.85%29.aspx
• https://www.google.ca/#q=the-ultimate-so_linger-page

И SIOCOUTQ похоже, SIOCOUTQ для Linux.

Примечание shutdown(fd, SHUT_WR) не прекращает писать, вопреки его имени, и, возможно, противоречит man 2 shutdown .

Этот код flushSocketBeforeClose() ждет до считывания нулевых байтов или до истечения таймера. Функция haveInput() является простой оболочкой для select (2) и имеет значение для блокировки до 1 / 100th секунды.

 bool haveInput(int fd, double timeout) { int status; fd_set fds; struct timeval tv; FD_ZERO(&fds); FD_SET(fd, &fds); tv.tv_sec = (long)timeout; // cast needed for C++ tv.tv_usec = (long)((timeout - tv.tv_sec) * 1000000); // 'suseconds_t' while (1) { if (!(status = select(fd + 1, &fds, 0, 0, &tv))) return FALSE; else if (status > 0 && FD_ISSET(fd, &fds)) return TRUE; else if (status > 0) FatalError("I am confused"); else if (errno != EINTR) FatalError("select"); // tbd EBADF: man page "an error has occurred" } } bool flushSocketBeforeClose(int fd, double timeout) { const double start = getWallTimeEpoch(); char discard[99]; ASSERT(SHUT_WR == 1); if (shutdown(fd, 1) != -1) while (getWallTimeEpoch() < start + timeout) while (haveInput(fd, 0.01)) // can block for 0.01 secs if (!read(fd, discard, sizeof discard)) return TRUE; // success! return FALSE; } 

Пример использования:

  if (!flushSocketBeforeClose(fd, 2.0)) // can block for 2s printf("Warning: Cannot gracefully close socket\n"); closeSocket(fd); 

В приведенном выше getWallTimeEpoch() my getWallTimeEpoch() похож на time(), а Perror() является оболочкой для perror().

Редактировать: Некоторые комментарии:

• Мое первое признание немного смущает. OP и Nemo оспаривали необходимость очистки внутреннего so_error до закрытия, но теперь я не могу найти никаких ссылок на это. Эта система была HPUX 10.20. После неудачного connect() просто вызов функции close() не освободил дескриптор файла, потому что система пожелала доставить мне выдающуюся ошибку. Но я, как и большинство людей, никогда не удосужился проверить возвращаемое значение close. Поэтому у меня в конечном итоге закончились файловые дескрипторы (ulimit -n), которые, наконец, привлекли мое внимание.

• (очень незначительная точка). Один комментатор возражал против жестко заданных числовых аргументов shutdown() , а не, например, SHUT_WR для 1. Самый простой ответ заключается в том, что Windows использует разные # SD_SEND / SD_SEND например SD_SEND . И многие другие авторы (например, Beej) используют константы, как и многие устаревшие системы.

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

Пример кода для установки CLOEXEC:

  static void setFD_CLOEXEC(int fd) { int status = fcntl(fd, F_GETFD, 0); if (status >= 0) status = fcntl(fd, F_SETFD, status | FD_CLOEXEC); if (status < 0) Perror("Error getting/setting socket FD_CLOEXEC flags"); } 

Большой ответ от Джозефа Куинси. У меня есть комментарии к функции haveInput . Удивительно, насколько вероятно, что select возвращает fd, который вы не включили в свой набор. Это будет серьезная ошибка ОС IMHO. Это то, что я хотел бы проверить, писал ли я модульные тесты для функции select , а не в обычном приложении.

 if (!(status = select(fd + 1, &fds, 0, 0, &tv))) return FALSE; else if (status > 0 && FD_ISSET(fd, &fds)) return TRUE; else if (status > 0) FatalError("I am confused"); // <--- fd unknown to function 

Мой другой комментарий относится к обработке EINTR. Теоретически, вы могли бы застрять в бесконечном цикле, если бы select продолжал возвращать EINTR, поскольку эта ошибка позволяет начать цикл. Учитывая очень короткий тайм-аут (0,01), представляется маловероятным. Тем не менее, я думаю, что подходящим способом борьбы с этим было бы вернуть ошибки вызывающему ( flushSocketBeforeClose ). Вызывающий может продолжать вызов haveInput тех пор, пока его таймаут не истек, и объявить отказ для других ошибок.

ДОПОЛНЕНИЕ № 1

flushSocketBeforeClose не выйдет быстро в случае read возвращая ошибку. Он будет продолжать цикл до истечения таймаута. Вы не можете полагаться на select внутри haveInput чтобы предвидеть все ошибки. read есть собственные ошибки (например: EIO ).

  while (haveInput(fd, 0.01)) if (!read(fd, discard, sizeof discard)) <-- -1 does not end loop return TRUE; 

Это звучит для меня как ошибка в вашем дистрибутиве Linux.

Документация библиотеки GNU C гласит:

Когда вы закончите использовать сокет, вы можете просто закрыть его дескриптор файла с помощью close

Ничего об очистке каких-либо флагов ошибки или ожидании сброса данных или какой-либо такой вещи.

Ваш код в порядке; ваш O / S имеет ошибку.