Eu tenho um aplicativo de rede cliente/servidor usando o soquete Boost ASIO TCP. O cliente está rodando em um sistema Linux embarcado onde múltiplas interfaces de rede estão disponíveis (WiFi, celular, etc), a qualquer momento há apenas uma interface de rede ativa e com endereço IP assinado, se a interface estiver inativa, outra interface está ativa e assinada Endereço de IP. O problema que tenho é que quando o aplicativo cria um soquete TCP em uma interface disponível, ele pode transferir dados para o servidor remoto, mas quando a interface está inativa, outra interface está ativa, o aplicativo cliente ainda transfere os dados para o servidor remoto usando a mesma interface inativa, resultando que o servidor não pode receber os dados. Eu pensei que a rota do sistema operacional Linux deveria ser capaz de lidar com o failover da interface de rede, o aplicativo TCP do usuário não deveria precisar se preocupar com a mudança da interface de rede. Agradeço todas as dicas para consertar o programa.
O mesmo problema que posso ver em um laptop rodando Ubuntu 18 com Ethernet e WiFi também, se eu executar o ssh conectado a um site remoto quando a Ethernet estiver conectada, quando retirei o cabo Ethernet, o WiFi ainda está conectado, mas o ssh congelou, ele não pode desviar a conexão pela rota do sistema operacional.
Obrigado.
Atenciosamente,
- j
Você está falando de uma conexão TCP existente que alterna interfaces quando uma interface fica inativa? Isso não vai funcionar, o TCP não é multi-homing, então isso é uma falha do protocolo, e não do Linux. A escuta OTOH no soquete TCP usará, por padrão, todas as interfaces, assim como a abertura de uma conexão TCP.
Sim, uma conexão TCP existente alterna interfaces quando uma interface fica inativa.
Se você controla ambos os lados do seu aplicativo cliente-servidor, considere usar um protocolo multi-homing como SCTP ou Multipath TCP.
Sim, eu controlo ambos os lados dos aplicativos cliente-servidor. Eu uso o soquete Boost ASIO, vou verificar se o boost suporta Multipath TCP ou não.
Existem outras maneiras de lidar com o failover de links físicos, como a ligação, mas elas também exigem que você seja capaz de controlar ambos os lados.
Sim ou não, eu controlo ambos os lados dos aplicativos cliente-servidor, mas controlo apenas o site da plataforma do servidor, não o site da plataforma do cliente. Posso sugerir que o site do cliente altere a operação da rede, isso funcionará?
Obrigado.
Responder1
Você está falando de uma conexão TCP existente que alterna interfaces quando uma interface fica inativa? Isso não vai funcionar, o TCP não é multi-homing, então isso é uma falha do protocolo, e não do Linux. OTOHaudiçãono soquete TCP usará por padrão todas as interfaces, assim comoaberturauma conexão TCP.
Se você controla ambos os lados da sua aplicação cliente-servidor, considere usar um protocolo multi-homing comoSCTPouTCP multicaminho.
Achei que a rota do sistema operacional Linux deveria ser capaz de lidar com failover de interface de rede
Isso não acontece e nunca aconteceu, e nem qualquer outra implementação existente de TCP e UDP. Da mesma forma, você não pode usar facilmente vários ISPs ao mesmo tempo, o que é um FAQ.
Existem outras maneiras de lidar com o failover de links físicos, como a ligação, mas elas também exigem que você seja capaz de controlar ambos os lados.
Editar
Dependendo do que há entre o seu servidor e o seu cliente, esta parte da rede pode ou não deixar passar o SCTP (na dúvida, teste).
Para a maioria dos sistemas Linux embarcados, você poderá recompilar o kernel, que é o que você precisará para o Multipath TCP.
Se você não puder fazer isso, provavelmente está com esse problema - então a única solução alternativa é detectar se uma interface cai e reabrir a conexão do cliente (assumindo que o servidor tenha um IP conhecido).