закрытие сокета

С моей чайниковской точки зрения — посылать keepalive периодически.

таймайт

Я могу ошибаться, но при ошибке соединения запрос чтения вернет ошибку (-1) или 0. Хотя это зависит от ЯП.

На это форуме есть один парень с ником telepathy, он большой спец в сокетах и прочем, но кажется куда-то уехал. Он должен точно знать.

Тестировал на локалхосте или через сеть?

тестирую через глобальную сеть.

сервер - пока классический пример на сокетах на С.

хм с чем это связано?

роутер или удалённая сторона прибил соединение

как мне сделать

keepalive. Можно на уровне протокола периодически посылать данные, можно на уровне сокета выставить keepalive interval(через setcokopt, если не путаю, подробности в гугле).

может быть

а почему же тогда сервер никак на это не реагирует...клиентский процесс на стороне сервера продолжает ждать жить

В смысле не отваливается? Это реальность с которой приходится жить :(. Я правильно понимаю что как минимум одна из тачек у тебя за натом? Серваки с реальными ипами так не тупят потому что между ними нет таких вот маршрутизаторов которые молча дропают пакеты.

роутер или удалённая сторона прибил соединение

Простите за мою безграмотность, если что, но разве роутер может прибить соединение, он ведь работает на уровне IP, а не на уровне TCP.

нет, тачки в разных углах города

Может дурацкий вопрос, но его следует задать. Вы ведь там проверяете возврат функции write(), т. е. нет ошибок, и самое главное число реально записанных байт в сокет соответствует тому, что вы собирались записать?

по идее nat может. Не будет же он держать соединение в таблице вечно

да как бы дочерний процес на стороне сервера блокируется на ожидании данных, т.е. на read() и функция ничего не возвращает...после долгого таймайта со стороны клиента

если что, но разве роутер может прибить соединение, он ведь работает на уровне IP, а не на уровне TCP.

nat и фаерволы(не все, только stateful) работают на уровне tcp. Более того, они даже udp отслеживают, иначе бы за натом udp не работал.

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

а это ничего не значит. write вернёт количество байт которое влезло в буфера ядра. Это не значит что эти данные дойдут до получателя. Поэтому если нужно убедиться что данные дошли надо чтобы удалённая сторона явно присылала подтверждение.

нет, тачки в разных углах города

ну, в общем, снифер всё покажет. Но можно с этим не париться, явно проблема с таймаутами и keepalive спасёт.

Я полагаю что если с одного сервера на другой зайти по ssh и долго не трогать консольку то она тоже отвалится. Не наблюдал такого?

наблюдал, кстати, и сервер засыпал( если его по ssh запускать

а это ничего не значит. write вернёт количество байт которое влезло в буфера ядра. Это не значит что эти данные дойдут до получателя.

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

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

нет, тачки в разных углах города

Кстати, это ведь не локальная сеть. Вам провайдер(ы) разве обещал(и) стабильное соединение двух компов?

да нет, ошибки точно нет в исходниках

*адский смех*

Думаю жизнь тебе ещё не раз докажет, что нельзя ни в чём до конца быть уверенным.

Хотя в данном случае наиболее вероятно, что проблема именно в самой сети (NAT-ы или ещё что-нибудь).

Соединения имеют свойство отваливаться после периода неактивности случайным образом. NAT равнодушно дропает запись из таблицы, и после этого пакеты между двумя точками никуда идти не могут. Самое забавное, что при этом никакой информации о закрытии соединения (FIN) никуда не посылается, таким образом оба участника искренне верят, что соединение живо и готовы посылать и читать оттуда данные.
Способ с этим бороться (неправильный) - keep-alive.
Правильный - строить свое приложение таким образом, чтобы оно умело детектировать разрыв сети и устанавливать соединение повторно.

Потестируй на локалхосте, обычно обвинения в сторону 3х программ типа натов, компиляторов, библиотек итд не проходят проверок ;)

Программа многопоточная?

Я откуда знаю? Я отвечаю на вопрос топикстартера :)

fork() на каждый коннект

на локалхосте погоняй, чтобы исключить ошибки в сети. И насколько я понимаю если НАТ забудет о соединии, то ты получишь от него RST, это приведет к появлению ошибки чтения из сокета.

Оффтоп. Вообще так не надо. Это плохо.

>> fork() на каждый коннект

Оффтоп. Вообще так не надо. Это плохо.

Обычная техника. Например. такую использует Postgres, SSH и куча Ъ-Unix программ. Или ты ничего не видел, кроме Web-серверов?

Думаю там каждый такой форк умеет много коннектов обслуживать, кроме ssh, там действительно так логичнее. Такой подход кроме простоты и изоляции процессов ничего особенно не дает, кроме неудобства взаимодействия, шарить все ручками надо. Если есть возможность, особенно для софта с большим количеством длительный соединений лучше использовать epoll и его друзей в других ОС

> Думаю там каждый такой форк умеет много коннектов обслуживать

Нет.

Такой подход кроме простоты и изоляции процессов ничего особенно не дает,

Как будто этого мало.

кроме неудобства взаимодействия, шарить все ручками надо.

Зависит от задачи. Тебе всё кажется вебелью.

Понятно что зависит от задачи. Почему тебе кажется что ты знаешь что мне кажется? Просто если процессы не взаимодействуют особо, то можно и форкать. Иначе это просто глупо себя ограничивать. В линукс все равно процессы и потоки одинаково описываются в ядре, просто парочка флажков других. Но каких флажков. «Я прошу продублировать с помощью COW мое адресное пространство». Это блин вообще бред, только выглядит так мило в коде. Начинешь писать что-то сложнее и нагруженнее (или наоборот много висящих соединений), то даже легковеснейшие потоки, без единого копированого пускай даже через COW, становятся слишком дорогими. Это не ssh, который друг с другом не взаимодействует, идеально ложится на парадигму parent-child и потом все равно другой процесс дергает. И главное чтобы сегфолт в одном не валил остальные

> Почему тебе кажется что ты знаешь что мне кажется?

По тому, что ты говоришь.

Просто если процессы не взаимодействуют особо, то можно и форкать.

Совсем недавно ты говорил «не делай так вообще, это плохо».

Это thumb rule. Обычно люди не понимаю что форк подходит в 5% случаев