У меня есть клиентское/серверное сетевое приложение, использующее сокет Boost ASIO TCP. Клиент работает на встроенной системе Linux, где доступно несколько сетевых интерфейсов (WiFi, сотовая связь и т. д.), в любой момент времени только один сетевой интерфейс работает и имеет подписанный IP-адрес, если интерфейс отключен, другой интерфейс работает и имеет подписанный IP-адрес. Проблема, с которой я столкнулся, заключается в том, что когда приложение создает сокет TCP в одном доступном интерфейсе, оно может передавать данные на удаленный сервер, но когда интерфейс отключен, другой интерфейс работает, клиентское приложение все равно передает данные на удаленный сервер, используя тот же отключенный интерфейс, в результате чего сервер не может получить данные. Я думал, что маршрут ОС Linux должен иметь возможность обрабатывать отказоустойчивость сетевого интерфейса, пользовательское TCP-приложение не должно беспокоиться об изменении сетевого интерфейса. Буду признателен за любые советы по исправлению программы.
Такую же проблему я наблюдаю на ноутбуке под управлением Ubuntu 18 с Ethernet и WiFi. Если я запускаю SSH-подключение к удаленному сайту при подключенном Ethernet, то при отключении кабеля Ethernet WiFi все еще подключен, но SSH зависает и не может перенаправить соединение по маршруту ОС.
Спасибо.
С уважением,
- дж
Вы говорите о существующем TCP-подключении, переключающем интерфейсы, когда один интерфейс выходит из строя? Это не сработает, TCP не является многосетевым, так что это недостаток протокола, а не Linux. OTOH, прослушивающий TCP-сокет, по умолчанию будет использовать все интерфейсы, как и открытие TCP-подключения.
Да, существующее TCP-соединение переключает интерфейсы при выходе из строя одного из интерфейсов.
Если вы контролируете обе стороны клиент-серверного приложения, рассмотрите возможность использования протокола множественной адресации, например SCTP или Multipath TCP.
Да, я контролирую обе стороны клиент-серверных приложений. Я использую Boost ASIO socket, проверю, поддерживает ли Boost Multipath TCP или нет.
Существуют и другие способы управления отказоустойчивостью физических соединений, например, объединение, но они также требуют возможности контролировать обе стороны.
Да или нет, я контролирую обе стороны клиент-серверных приложений, но я контролирую только сайт серверной платформы, а не сайт клиентской платформы. Я могу предложить клиентскому сайту изменить работу сети. Сработает ли это?
Спасибо.
решение1
Вы говорите о существующем TCP-подключении, переключающем интерфейсы, когда один интерфейс выходит из строя? Это не сработает, TCP не является многоадресным, так что это недостаток протокола, а не Linux. OTOHслушаюна TCP-сокете по умолчанию будут использоваться все интерфейсы, как иоткрытиеTCP-соединение.
Если вы контролируете обе стороны в своем клиент-серверном приложении, рассмотрите возможность использования протокола множественной адресации, напримерСКТПилиМногопутевой TCP.
Я думал, что маршрут ОС Linux должен уметь обрабатывать отказоустойчивость сетевого интерфейса.
Этого нет и никогда не было, как и любая другая существующая реализация TCP и UDP. Точно так же вы не можете легко использовать несколько провайдеров одновременно, что является часто задаваемым вопросом.
Существуют и другие способы управления отказоустойчивостью физических соединений, например, объединение, но они также требуют возможности контролировать обе стороны.
Редактировать
В зависимости от того, что находится между вашим сервером и вашим клиентом, эта часть сети может пропускать или не пропускать SCTP (если есть сомнения, протестируйте).
Для большинства встраиваемых систем Linux вы сможете перекомпилировать ядро, что вам и понадобится для Multipath TCP.
Если вы не можете этого сделать, то, вероятно, вы столкнулись с этой проблемой. Тогда единственным решением будет обнаружить отключение интерфейса и повторно открыть соединение с клиента (при условии, что у сервера известный IP-адрес).