Не получается отследить потерю связи по сети. Linux, сокеты

@051Demon · Регистрация: 12.02.2014

Author24 — интернет-сервис помощи студентам

Всем привет.
Работаю с неблокирующими сокетами под Linux.

Не получается отследить ситуацию потери сети. Т.е., например, вынули разъем из сетевой карты.

метод

C++

1	select(ss[0]+1, &read_fs, &write_fs, &error_fs, &rwe_timeout);

в этом случае сообщает всё время, что для записи готов дескриптор write_fs
результат вызова select = 1

в итоге не могу поймать переподключение клиента после восстановления связи по сети, т.к. всё время кручусь в цикле опроса дескрипторов и повода для выхода из него нет...

Как быть?

@vxg · 26.07.2018, 07:45

051Demon, send 0 байт?

@051Demon · 26.07.2018, 08:21 **[ТС]**

Сообщение от vxg

051Demon, send 0 байт?

Да вот именно что нет.
Посылка уходит в сокет и send возвращает отправленное кол-во байт, соответствующее длине посылки...
никаких ошибок не возникает...

@NoMasters · 26.07.2018, 18:07

Как ни странно, временное выдергивание кабеля ещё не значит, что tcp-соединение разорвано.

@vxg · 27.07.2018, 06:47

051Demon, я имею ввиду: пробовали ли вы проверять наличие подключения посылая тестовые пакеты, возможно нулевой длины

@051Demon · 27.07.2018, 07:58 **[ТС]**

Сообщение от vxg

051Demon, я имею ввиду: пробовали ли вы проверять наличие подключения посылая тестовые пакеты, возможно нулевой длины

я же написал, что "Посылка уходит в сокет и send возвращает отправленное кол-во байт, соответствующее длине посылки...
никаких ошибок не возникает..."!!

Добавлено через 1 минуту

Сообщение от NoMasters

Как ни странно, временное выдергивание кабеля ещё не значит, что tcp-соединение разорвано.

т.е. как это не значит?
интерфейс ( в моем случае etc0) сразу после отключения кабеля переходит в состояние DOWN !!

@vxg · 27.07.2018, 08:03

051Demon, давайте уточним на какой стороне вынули кабель, если на отправляющей то странно что возвращает успех при упавшем адаптере

@051Demon · 27.07.2018, 08:06 **[ТС]**

Сообщение от vxg

051Demon, давайте уточним на какой стороне вынули кабель, если на отправляющей то странно что возвращает успех при упавшем адаптере

на моей стороне

):

у меня и прием и отправка. естественно. что ничего не приходит, когда кабель вынут. но в сокет данные уходят "без проблем"!

@NoMasters · 27.07.2018, 10:11

Может быть данные просто пишутся в буфер сокета и никуда на самом деле не уходят? Стоит попробовать TCP_NODELAY.

Сообщение от 051Demon

т.е. как это не значит?

TCP ничего не знает про физический уровень передачи, сильно далеко они друг от друга. Если ничего не слать, пока "кабель выдернут", то про восстановлении физического соединения всё может продолжить работать как будто ничего и не случилось.

@051Demon · 27.07.2018, 10:19 **[ТС]**

ничего не делать не получается

клиент разрывает подключение, т.к. он не получает ответы на запросы.
а переподключиться он уже не может, т.к. сервер не знает, что отваливалась сеть.

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

@Ygg · 27.07.2018, 13:11

Если ничего не путаю, то у винды, отключение сетевого кабеля на компе с открытым клиентским TCP сокетом приводит к штатной ситуации отключения: в селекте сокет помечается как ожидающий приёма, при попытке приёма данных возвращается 0 принятых байт, после этого сокет нужно убирать из селектов. Если кабель отключается где-то между или на конечном устройстве, то соединение не рвётся и программа не получает никаких уведомлений. Понять о разрыве можно только через ошибку при отправке данных. Альтернатива, у TCP сокетов есть опция KEEPALIVE, при её включении можно отловить любую потерю связи, но, опять же, не моментально. В зависимости от текущих настроек алгоритм гарантированной доставки может довольно долго пытаться передать данные прежде чем сообщит об ошибке.

@051Demon · 27.07.2018, 14:00 **[ТС]**

Сообщение от Ygg

Если ничего не путаю, то у винды, отключение сетевого кабеля на компе с открытым клиентским TCP сокетом приводит к штатной ситуации отключения: в селекте сокет помечается как ожидающий приёма, при попытке приёма данных возвращается 0 принятых байт, после этого сокет нужно убирать из селектов. Если кабель отключается где-то между или на конечном устройстве, то соединение не рвётся и программа не получает никаких уведомлений. Понять о разрыве можно только через ошибку при отправке данных. Альтернатива, у TCP сокетов есть опция KEEPALIVE, при её включении можно отловить любую потерю связи, но, опять же, не моментально. В зависимости от текущих настроек алгоритм гарантированной доставки может довольно долго пытаться передать данные прежде чем сообщит об ошибке.

Если заголовок прочитать внимательно, то тема не про винду

можно сокету задать опцию KEEPALIVE.
но в стандартной ситуации эта проверка примерно раз в 2 часа выполняется.
можно с помощью танцев в бубном поменять таймаут на меньший, но это будет установлено на СИСТЕМУ В ЦЕЛОМ - по крайней мере в линуксе.
А это полное... в общем нехорошо. Т.к. кроме моего сокета там ещё куча других может быть и к чему всё это приведет - х.з.

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

@Ygg · 27.07.2018, 14:32

Я видел, что не про винду, но и отличия, как я полагаю, не столь уж разительны.
Индивидуальные настройки KEEPALIVE для сокета в линуксе можно задать через setsockopt.

C++

  setsockopt( SOL_SOCKET, SO_KEEPALIVE )
  setsockopt( SOL_TCP, TCP_KEEPCNT )
  setsockopt( SOL_TCP, TCP_KEEPIDLE )
  setsockopt( SOL_TCP, TCP_KEEPINTVL )

Отправка может не возвращать ошибку по той же причине, попытки переслать данные ещё не закончились. Может нужно было подождать пару часов)

@051Demon · 27.07.2018, 14:40 **[ТС]**

Ygg, на сколько я понимаю (или не понимаю?

), параметры TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL доступны для компонентов ядра линукса. А не для прикладных программ/сервисов/демонов.

И устанавливают параметры на ВСЮ СИСТЕМУ.

@Ygg · 27.07.2018, 15:30

Сетями занимался крайне редко и под виндой, не специалист я в этой теме. Сравнительно недавно коллеги переносили сетевую часть на линукс (CentOS) и проблемы определения разрывов соединения успешно решили с помощью описанных выше настроек KEEPALIVE. Как я понимаю, есть глобальные настройки системы через файлы конфигурации или реестр, которые позволяют задать начальные значения сетевых опций при создании сокета, так сказать, настройки по умолчанию. Вызов же setsockopt позволяет программно менять настройки конкретного сокета.

@051Demon · 27.07.2018, 16:36 **[ТС]**

Ygg, сижу изучаю возможности...

@vxg · 28.07.2018, 07:09

051Demon, все это очень детективно но... почему одна сторона раз в х секунд не пошлёт запрос другой стороне и если не получит на него ответ за у секунд не порвёт подключение?

@051Demon · 30.07.2018, 11:02 **[ТС]**

Сообщение от vxg

051Demon, все это очень детективно но... почему одна сторона раз в х секунд не пошлёт запрос другой стороне и если не получит на него ответ за у секунд не порвёт подключение?

Потому что сие не заложено в протоколе обмена. Упустили...

@vxg Модератор 3387 / 2159 / 352 Регистрация: 13.01.2012 Сообщений: 8,378
	28.07.2018, 07:09	17
	051Demon, все это очень детективно но... почему одна сторона раз в х секунд не пошлёт запрос другой стороне и если не получит на него ответ за у секунд не порвёт подключение? 0

@vxg Модератор 3387 / 2159 / 352 Регистрация: 13.01.2012 Сообщений: 8,378
	26.07.2018, 07:45	2
	051Demon, send 0 байт? 0

@051Demon 1 / 1 / 0 Регистрация: 12.02.2014 Сообщений: 76
	26.07.2018, 08:21 [ТС]	3
	Сообщение от vxg 051Demon, send 0 байт? Да вот именно что нет. Посылка уходит в сокет и send возвращает отправленное кол-во байт, соответствующее длине посылки... никаких ошибок не возникает... 0

@NoMasters Псевдослучайный 1946 / 1145 / 98 Регистрация: 13.09.2011 Сообщений: 3,215
	26.07.2018, 18:07	4
	Как ни странно, временное выдергивание кабеля ещё не значит, что tcp-соединение разорвано. 0

@vxg Модератор 3387 / 2159 / 352 Регистрация: 13.01.2012 Сообщений: 8,378
	27.07.2018, 06:47	5
	051Demon, я имею ввиду: пробовали ли вы проверять наличие подключения посылая тестовые пакеты, возможно нулевой длины 0

@051Demon 1 / 1 / 0 Регистрация: 12.02.2014 Сообщений: 76
	27.07.2018, 07:58 [ТС]	6
	Сообщение от vxg 051Demon, я имею ввиду: пробовали ли вы проверять наличие подключения посылая тестовые пакеты, возможно нулевой длины я же написал, что "Посылка уходит в сокет и send возвращает отправленное кол-во байт, соответствующее длине посылки... никаких ошибок не возникает..."!! Добавлено через 1 минуту Сообщение от NoMasters Как ни странно, временное выдергивание кабеля ещё не значит, что tcp-соединение разорвано. т.е. как это не значит? интерфейс ( в моем случае etc0) сразу после отключения кабеля переходит в состояние DOWN !! 0

@vxg Модератор 3387 / 2159 / 352 Регистрация: 13.01.2012 Сообщений: 8,378
	27.07.2018, 08:03	7
	051Demon, давайте уточним на какой стороне вынули кабель, если на отправляющей то странно что возвращает успех при упавшем адаптере 0

@051Demon 1 / 1 / 0 Регистрация: 12.02.2014 Сообщений: 76
	27.07.2018, 08:06 [ТС]	8
	Сообщение от vxg 051Demon, давайте уточним на какой стороне вынули кабель, если на отправляющей то странно что возвращает успех при упавшем адаптере на моей стороне ): у меня и прием и отправка. естественно. что ничего не приходит, когда кабель вынут. но в сокет данные уходят "без проблем"! 0

@NoMasters Псевдослучайный 1946 / 1145 / 98 Регистрация: 13.09.2011 Сообщений: 3,215
	27.07.2018, 10:11	9
	Может быть данные просто пишутся в буфер сокета и никуда на самом деле не уходят? Стоит попробовать TCP_NODELAY. Сообщение от 051Demon т.е. как это не значит? TCP ничего не знает про физический уровень передачи, сильно далеко они друг от друга. Если ничего не слать, пока "кабель выдернут", то про восстановлении физического соединения всё может продолжить работать как будто ничего и не случилось. 0

@051Demon 1 / 1 / 0 Регистрация: 12.02.2014 Сообщений: 76
	27.07.2018, 10:19 [ТС]	10
	ничего не делать не получается клиент разрывает подключение, т.к. он не получает ответы на запросы. а переподключиться он уже не может, т.к. сервер не знает, что отваливалась сеть. решения тут два - первое и самое правильное вводить служебный обмен между сервером и клиентом. сервер постоянно шлет некий технический запрос, если клиент не отвечает, то значит пиндец. глушим сокет и ждем переподключения второе - и не самое правильное проверять состояние интерфейса - UP или DOWN, но для этого нужно чтобы служба сервера всегда под рутом работала. 0

@Ygg 2376 / 834 / 317 Регистрация: 10.02.2018 Сообщений: 1,968
	27.07.2018, 13:11	11
	Если ничего не путаю, то у винды, отключение сетевого кабеля на компе с открытым клиентским TCP сокетом приводит к штатной ситуации отключения: в селекте сокет помечается как ожидающий приёма, при попытке приёма данных возвращается 0 принятых байт, после этого сокет нужно убирать из селектов. Если кабель отключается где-то между или на конечном устройстве, то соединение не рвётся и программа не получает никаких уведомлений. Понять о разрыве можно только через ошибку при отправке данных. Альтернатива, у TCP сокетов есть опция KEEPALIVE, при её включении можно отловить любую потерю связи, но, опять же, не моментально. В зависимости от текущих настроек алгоритм гарантированной доставки может довольно долго пытаться передать данные прежде чем сообщит об ошибке. 0

	30.07.2018, 11:02

@051Demon 1 / 1 / 0 Регистрация: 12.02.2014 Сообщений: 76
	27.07.2018, 14:00 [ТС]	12
	Сообщение от Ygg Если ничего не путаю, то у винды, отключение сетевого кабеля на компе с открытым клиентским TCP сокетом приводит к штатной ситуации отключения: в селекте сокет помечается как ожидающий приёма, при попытке приёма данных возвращается 0 принятых байт, после этого сокет нужно убирать из селектов. Если кабель отключается где-то между или на конечном устройстве, то соединение не рвётся и программа не получает никаких уведомлений. Понять о разрыве можно только через ошибку при отправке данных. Альтернатива, у TCP сокетов есть опция KEEPALIVE, при её включении можно отловить любую потерю связи, но, опять же, не моментально. В зависимости от текущих настроек алгоритм гарантированной доставки может довольно долго пытаться передать данные прежде чем сообщит об ошибке. Если заголовок прочитать внимательно, то тема не про винду можно сокету задать опцию KEEPALIVE. но в стандартной ситуации эта проверка примерно раз в 2 часа выполняется. можно с помощью танцев в бубном поменять таймаут на меньший, но это будет установлено на СИСТЕМУ В ЦЕЛОМ - по крайней мере в линуксе. А это полное... в общем нехорошо. Т.к. кроме моего сокета там ещё куча других может быть и к чему всё это приведет - х.з. при отправке данных никаких ошибок не возникает! писал уже об этом выше. при опросе дескриптора на чтение - там читать нечего, поэтому и не читается! читать принудительно пробовал, но ситуация ровно такая же, как если бы подключение было исправно, а в сокете ничего не было. операция чтения возвращает -1, никаких системных ошибок нет! 0

@051Demon 1 / 1 / 0 Регистрация: 12.02.2014 Сообщений: 76
	27.07.2018, 14:40 [ТС]	14
	Ygg, на сколько я понимаю (или не понимаю? ), параметры TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL доступны для компонентов ядра линукса. А не для прикладных программ/сервисов/демонов. И устанавливают параметры на ВСЮ СИСТЕМУ. 0

@Ygg 2376 / 834 / 317 Регистрация: 10.02.2018 Сообщений: 1,968
	27.07.2018, 15:30	15
	Сетями занимался крайне редко и под виндой, не специалист я в этой теме. Сравнительно недавно коллеги переносили сетевую часть на линукс (CentOS) и проблемы определения разрывов соединения успешно решили с помощью описанных выше настроек KEEPALIVE. Как я понимаю, есть глобальные настройки системы через файлы конфигурации или реестр, которые позволяют задать начальные значения сетевых опций при создании сокета, так сказать, настройки по умолчанию. Вызов же setsockopt позволяет программно менять настройки конкретного сокета. 0

@051Demon 1 / 1 / 0 Регистрация: 12.02.2014 Сообщений: 76
	27.07.2018, 16:36 [ТС]	16
	Ygg, сижу изучаю возможности... 0

@051Demon 1 / 1 / 0 Регистрация: 12.02.2014 Сообщений: 76
	30.07.2018, 11:02 [ТС]	18
	Сообщение от vxg 051Demon, все это очень детективно но... почему одна сторона раз в х секунд не пошлёт запрос другой стороне и если не получит на него ответ за у секунд не порвёт подключение? Потому что сие не заложено в протоколе обмена. Упустили... 0