Как правильно поддерживать порт прослушивания в течение длительного времени?

Question

Я написал это небольшое серверное приложение в чистом C, которое слушает входящие соединения в данном порту, очень простые вещи.

Это идет с обычной процедурой инициализации сокета, создать socket() затем bind() к порту, говорит сво listen() и ifinitely петли через select() ожидая входящие соединения с accept().

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

Итак, вопрос в том, что, черт возьми, порт закрыт без беспокойства моего приложения и что я могу сделать, чтобы предотвратить его?

Ожидаемое поведение? Должен ли я проверить какие-то исключения или сделать «проверку работоспособности» в гнезде для прослушивания, если это необходимо?

Код: https://gist.github.com/Havenard/e930be035a3bee75c018 (да, я понимаю, что я использую 0 в реплике на наличие ошибок, и это плохо pratice и прочее, но это не имеет отношения к вопросу, как я объяснил в комментариях, когда я устанавливаю дескриптора файла сокета для 0 - остановить цикл и закрыть приложение).

Answer 1

Я хотел бы начать с очисткой его:

• вырезать его на более мелкие, считываемые, сверяемый, проверяемые функции
• связанного использование списков выглядит неаккуратно; его можно было бы упростить, возможно, путем введения некоторых общих функций.
• заменить все глупые «\ x20» символьные константы на более читаемые «эквиваленты»
• избегать манифестных магических констант, как здесь if (n_case > 0) memcpy(nick, node->nick, (n_case > 32 ? 32 : n_case));; sizeof - ваш друг.
• не использовать нуль в качестве значения дозорного значения для неиспользуемого дескриптора файла; вместо этого используйте -1.
• использовать беззнаковые типы для размеров и индексов; отрицательные индексы будут повреждать память, сбрасываемые неподписанные типы будут работать быстро. (failfast - ваш друг)

Это только несколько часов редактирования.

Я предполагаю, что после очистки/рефакторинга ваша «ошибка» выйдет на поверхность магически.

Сноска: Нет, я не буду делать вашу работу за вас. Не для 100 очков, не для 1000. Пожалуйста, уберите свой беспорядок.

Answer 2

Похоже, ваш код должен иметь 2 последовательных ошибки, чтобы вызвать сбой.

Если у вас есть ошибка в выборе, почему бы не распечатать, почему сразу?

В строке 281, printf errno/perror, чтобы узнать, в чем проблема?

Answer 3

Ошибка в том, что вы используете 0 как недопустимый дескриптор файла. 0 отлично действует и обычно является stdin. Затем слушатель устанавливается в 0 в обработчике сигнала.Затем вы используете 0 как нет fd, и в какой-то момент вы закрываете (0) на каком-то сокете, есть ветви, которые закрываются (fd), не проверяя его на 0, и это фактически закрывает слушателя. Другой возможной возможностью остановить прослушиватель от работы является переполнение отставания.

И еще одна проблема - использование unsigned int для fds. системные вызовы return -1 при ошибке ... и эта ошибка не будет обнаружена с, если присвоено unsigned int struct identd_node -> unsigned int handle; struct thread_node -> unsigned int skt_clnt, skt_serv;

Answer 4

Этот ответ, главным образом, обзор кода мест, в которых вы звоните close().

Строка 330: вы закрываете розетку, но не продолжаете сразу же, как в других местах вашего кода. Это может привести к странному поведению.

Линия 928: В большинстве мест вы устанавливаете клиентский или серверный сокет на 0 после звонка на close(). После этого звонка вы этого не сделаете.

Line 1193: Тот же комментарий, как линии 928.

Line 1195: Тот же комментарий, как линии 928.

Line 1218: Тот же комментарий, как линии 928.

Line 1234: Тот же комментарий, как линии 928.

Line 1236: Тот же комментарий, как линии 928.

Когда я скомпилировал код с полными предупреждениями, я видел ряд мест, где ком piler отметил функции, объявленные для возврата значения, но значение не возвращается.

x.c:582: warning: no return statement in function returning non-void 
x.c:591: warning: no return statement in function returning non-void 
x.c:598: warning: no return statement in function returning non-void 
x.c:609: warning: no return statement in function returning non-void 
x.c:620: warning: no return statement in function returning non-void 
x.c:728: warning: no return statement in function returning non-void 
x.c:779: warning: no return statement in function returning non-void 

Есть много других проблем, как указано в других сообщениях.

Что касается отладки этой проблемы, если я подозревал, что сокет привязки закрывается раньше, я бы перехватил вызов close() своей собственной версией, которая утверждает, что дескриптор, который должен быть закрыт, не должен соответствовать привязке.

Однако, как отметил wildplasser, select() вернет ошибку о недопустимом дескрипторе, если он был закрыт.

Answer 5

Хотя система не должна вести себя так, как описано, она иногда делает это. Для серверных систем обычно вам нужно выполнить вызов healthcheck, либо извне (из сценария), либо из специального потока в вашем коде.

Итак, если вы обнаружите, что не можете подключиться к серверу в несколько последовательных попыток (требуется несколько из-за возможного состояния перегрузки), вы можете рассмотреть сокет сломанный и воссоздать его или перезапустить сервер.