Comunicação peer to peer em LAN multi-sub-redes complicada

Question

Estamos desenvolvendo uma aplicação P2P e estamos empenhados em fazer a comunicação entre 2 peers que estão na mesma LAN local, mas 2 sub-redes diferentes.

Sabemos que há muitos casos em que 2 determinados PCs na mesma LAN são definitivamente "não conectáveis" por causa das configurações de alguns roteadores. O que estamos tentando é apenas entender a situação & descubra o melhor que podemos fazer. (com nosso conhecimento limitado sobre redes e sua ajuda)

Considere uma LAN com estrutura como a figura a seguir. Suponha que a LAN seja projetada por nosso cliente e não saibamos nada. Estamos apenas observando a LAN do ponto de vista de um PC que instalou nosso programa. Assim, tudo o que sabemos é o nosso localIP / subnetMask & o IP público comum de toda a LAN. (O restante é desconhecido & é exibido como uma nuvem)

Temosváriasperguntasquesãoaltamenteapropriadasparaqualquerresposta:

1. SuponhaquequandooPC1fizeromulticastdeumpacoteeopacoteatingiroPC2dealgumaforma.QueendereçoIPPC2veráparaoremetentedopacote:LocalIPdePC1(comonafigura192.168.1.111)ouIPexternodeRouter_A_1ouRouter_A?

2. Depoisde#1,seoPC2respondercomoutropacote(unicast)aoIPqueoPC2vêem#1,opacotealcançaráoPC1?

3. Noscasosglobaisde#2,oquepodeserapropriado?IPAddressthatPC1&PC2usaparaenviarpacotesparaooutro?(OuéomesmoquefazemosnaInternetcom2PCsatrásderoteadoresNAT:upnp,hole-punchingouumintermediário-superNode?)

4. ExistealgumcasoquePC1&PC2sãoatribuídoscomomesmoendereçoIP?Seéverdadeentão:

   • a.Issoéumcaso"legal"?
   • b. E quanto ao IP do remetente que o PC2 vê em # 1 e responde por # 2?

Atualize a pergunta adicional:

5. Isso é verdade se 1 multicast e & o pacote pode alcançar o outro ponto, em seguida, os 2 PCs são "unicast-capaz" - e se o pacote multicast não pode atingir o outro par, em seguida, 2 PCs estão condenados? Isso é verdade para "unicast-able - > multicast-able"?

Answer 1

Escrevi poucos aplicativos peer-to-peer e posso dizer que a acessibilidade de peers é o principal problema com esse tipo de aplicativo. Aqui estão alguns ponteiros:

• se você usar o TCP, sua única esperança é o UPnP. No entanto, você não pode presumir que está sempre disponível. Na verdade, o UPnP é (a) geralmente suportado por roteadores de redes domésticas (b) é freqüentemente desativado, pois as pessoas veem pouco ou nenhum valor nele, então o suporte para ele é bastante esporádico. Suas chances são ainda menores se seus clientes estiverem atrás de duas camadas de roteadores, cada qual fazendo seu próprio NAT. Mas, se você puder dizer aos seus clientes para habilitar o UPnP ou especificar o UPnP como pré-requisito para o seu aplicativo, então é um caminho a ser seguido.

• Outra opção é usar o UDP e inserir um orifício no roteador, mas você precisaria de um agente externo que rastreie o endereço de mesmo nível e corresponda à identidade do host a um endereço IP acessível globalmente (no seu caso, ele provavelmente será implantado "Desconhecido"). Note que o TTL de buracos de pinos UDP é geralmente muito curto (pela minha estimativa é entre 20 segundos e 5 minutos), então você precisaria pingar seu agente com bastante frequência. Outro problema com o UDP é que você pode precisar implementar seu próprio protocolo de controle de fluxo se seu aplicativo trocar bits de dados maiores que 1 pacote.

Espero que isso ajude.

    

Answer 2

Sua topologia de rede, no melhor dos casos, não é confiável e é difícil de manter.

Considere isto (assumindo / 24 sub-redes): PC1 (192.168.1.111) tenta enviar um pacote para o PC2 (192.168.1.22). Por que o Router_A_1 (ou mesmo o Router_A) deve encaminhar esse pacote pela nuvem "desconhecida" para a outra sub-rede? No que diz respeito aos roteadores "A", o pacote já está na sub-rede à qual pertence. Não é impossível hackear algumas tabelas de roteamento nos roteadores para encaminhar endereços específicos - mas você descobrirá de onde vem a parte "não confiável e difícil" (e pode nem mesmo ser prática dependendo do que está na nuvem "desconhecida").

Existe alguma razão pela qual você não pode simplesmente alocar uma diferente / 24 para as sub-redes do roteador "B"? Tal como 192.168.2.0/24?

    

Answer 3

Você não disse, mas ...
Se você estiver usando a máscara de sub-rede tradicional de 24 bits (ou seja, ambas as redes são 192.168.1.0/24), essas máquinas nunca poderão se comunicar porque, por definição, tentarão Resolva o endereço MAC por transmissão em vez de ir ao gateway para o roteamento porque ele assumirá que a máquina está na rede local.

Você poderia consertar isso atribuindo ao PC1 um endereço em uma rede diferente.
SO PC1 = 192.168.2.111

Nesse caso, contanto que os roteadores intermediários tenham as entradas corretas da tabela de roteamento e permitam multicast e permitam qualquer porta / protocolo que você esteja tentando, deve funcionar.