2015-05-15 3 views
0

В OSX я продолжаю получать сокетную ошибку 316 после вызова accept() на связанном соте &. Я получаю верный сокет, и я считаю, что я использую его в порядке (хотя, возможно, и не так, мне нужно дважды проверить это, поскольку я принимаю сотни соединений в любой момент), но errno был установлен.Что такое SOCKET accept() error errno 316?

Я пытаюсь понять the documentation on the unix accept(2) man pages, который отмечает (что, кстати, отсутствует в apple's accept() documentation)

Linux принимают() (и accept4()) проходит уже ожидающие сетевые ошибки на новом сокете как код ошибки от accept(). Такое поведение отличается от других реализаций сокетов BSD. Для надежной работы приложение должно обнаруживать сетевые ошибки, определенные для протокола после accept(), и обрабатывать их как EAGAIN путем повторной попытки.

сейчас, 316 работает как 256 OR'd with ETIMEDOUT (60). Итак, мне любопытно, как я должен справляться с этим;

  1. Если ANY error установлен после accept(), должен ли я снова принять()?
  2. Должен ли я закрыть() SOCKET, который принимает возврат DID?
  3. Являются ли unix кодом errno 8 бит? (все коды, которые я вижу, это < 128) и это ошибочный бит , установленный в памяти, или это специальный флаг, как предупреждение (я не могу найти документацию по формату errno)
  4. Имеет ли эта ошибка соединение, которое я только что выскочил из стека, приурочен ... сам и ОС отключили их, или не принимали() 'd мной достаточно быстро?
+0

Как это «* ... продолжать получать ошибку сокета 316 после вызова accept() в подключенном и прослушивающем сокете. Я получаю верный сокет, возвращенный, *« работает? Вы просто хотите проверить 'errno', если' accept() 'return' -1', что, в свою очередь, не является допустимым дескриптором сокета. – alk

+0

Это то, что я изначально думал, но цитируемые документы говорят, что «пропускает уже ожидающие сетевые ошибки в новом сокете». Новый сокет здесь означает ... мой существующий сокет? или новый сокет, который он генерирует? –

+0

Хотя я только что нажал все ошибки, прежде чем вызывать 'accept()', и я чувствую, что это просто старый код ошибки после этого, поэтому я не проверяю ошибки после некоторого другого вызова ... –

ответ

1

Не проверять errno, если только accept() не вернулся -1. Если accept() возвращает действительный файловый дескриптор, тогда значение errno равно undefined.

+0

Я принял это как ответ. Реальное разрешение заключалось в том, что эта ошибка запускалась с помощью моего * успешного * 'socket()' создания (и я получаю его в UDP и TCP), и на самом деле я рассматривал эту ошибку, а не для принятия. Что же касается самого странного errono, это может быть для отдельного вопроса –

+0

meta: нужно ли «разрешить» этот вопрос каким-то образом, например, «не настоящая проблема»? –

+0

Я не знаю, как сказать это более явно: ** Никогда не ** проверять 'errno' _unless_, самая последняя функция возвращала указание на фактическую ошибку! Он не имеет значения, и его значение не определено ни в одном, ни во всех случаях, когда последняя функция преуспела. –