Tengo una aplicación de red cliente/servidor que utiliza el socket Boost ASIO TCP. El cliente se ejecuta en un sistema Linux integrado donde hay múltiples interfaces de red disponibles (WiFi, celular, etc.), en cualquier momento solo hay una interfaz de red activa y dirección IP firmada; si la interfaz está inactiva, otra interfaz está activa y firmada. Dirección IP. El problema que tengo es que cuando la aplicación crea un socket TCP en una interfaz disponible, puede transferir datos al servidor remoto, pero cuando la interfaz está inactiva, otra interfaz está activa, la aplicación cliente aún transfiere los datos al servidor remoto. utilizando la misma interfaz inactiva, lo que resulta en que el servidor no pueda recibir los datos. Pensé que la ruta del sistema operativo Linux debería poder manejar la conmutación por error de la interfaz de red, la aplicación TCP del usuario no debería tener que preocuparse por el cambio de la interfaz de red. Agradezco cualquier consejo para arreglar el programa.
El mismo problema lo puedo ver en una computadora portátil que ejecuta Ubuntu 18 con Ethernet y WiFi también, si ejecuto ssh conectado a un sitio remoto cuando Ethernet está conectado, cuando desconecto el cable Ethernet, el WiFi todavía está conectado pero el ssh se congela. no puede desviar la conexión por ruta del sistema operativo.
Gracias.
Atentamente,
- j
¿Está hablando de una conexión TCP existente que cambia de interfaz cuando una interfaz falla? Esto no funcionará, TCP no es multihoming, por lo que es una falla del protocolo y no de Linux. La escucha de OTOH en el socket TCP utilizará de forma predeterminada todas las interfaces, al igual que la apertura de una conexión TCP.
Sí, una conexión TCP existente cambia de interfaz cuando una interfaz deja de funcionar.
Si controla ambos lados de su aplicación cliente-servidor, considere utilizar un protocolo multidireccional como SCTP o Multipath TCP.
Sí, controlo ambos lados de las aplicaciones cliente-servidor. Utilizo el socket Boost ASIO, comprobaré si boost admite TCP de rutas múltiples o no.
Hay otras formas de manejar la conmutación por error de enlaces físicos, como la vinculación, pero también requieren que usted pueda controlar ambos lados.
Sí o no, controlo ambos lados de las aplicaciones cliente-servidor, pero solo controlo el sitio de la plataforma del servidor, no el sitio de la plataforma del cliente. Puedo sugerir el sitio del cliente para cambiar la operación de la red, ¿funcionará?
Gracias.
Respuesta1
¿Está hablando de una conexión TCP existente que cambia de interfaz cuando una interfaz falla? Esto no funcionará, TCP no es multihoming, por lo que es una falla del protocolo y no de Linux. OTOHescuchandoen el socket TCP utilizará de forma predeterminada todas las interfaces, al igual queaperturauna conexión TCP.
Si controla ambos lados en su aplicación cliente-servidor, considere usar un protocolo de alojamiento múltiple comoSCTPoTCP de múltiples rutas.
Pensé que la ruta del sistema operativo Linux debería poder manejar la conmutación por error de la interfaz de red.
No lo hace ni lo hizo nunca, y tampoco lo hace ninguna otra implementación existente de TCP y UDP. De la misma manera, no puedes usar fácilmente varios ISP al mismo tiempo, lo cual es una pregunta frecuente.
Hay otras formas de manejar la conmutación por error de enlaces físicos, como la vinculación, pero también requieren que usted pueda controlar ambos lados.
Editar
Dependiendo de lo que haya entre su servidor y su cliente, esta parte de la red puede permitir o no el paso de SCTP (en caso de duda, pruebe).
Para la mayoría de los sistemas Linux integrados, debería poder recompilar el kernel, que es lo que necesitará para Multipath TCP.
Si no puede hacer esto, probablemente tenga este problema; entonces la única solución es detectar si una interfaz falla y volver a abrir la conexión desde el cliente (asumiendo que el servidor tiene una IP conocida).