Observar o desenvolvimento da rede de compartilhamento de arquivos é interessante, mas participar dela é ainda mais empolgante.
Atualmente, ao instalar e executar um moderno hub, o novo administrador tem acesso praticamente a todos os desenvolvimentos e à experiência acumulada de seus antecessores. Ele possui um sistema pronto para expansão e personalização, inclusive com a ajuda de vários scripts.
Com hubs de forma diferente. A estrutura deste protocolo pressupõe escalabilidade. Quer um novo recurso? Então proponha, promova, implemente, utilize.
Como consequência, "pronto para uso" pode, claro, resultar em um hub funcional, mas apenas ligá-lo e esquecê-lo não é o ideal. A escalabilidade, em um contexto histórico, também pressupõe uma variedade de funcionalidades de software cliente e servidor, dependendo da versão. E o que funciona perfeitamente para um usuário pode ser incompatível com o cliente de outro, e isso deve ser considerado.
O mesmo ocorreu com o IPv6. O antigo NMDC não o suporta, mas o ADC, por si só, está pronto. No entanto, nem tudo é tão simples.
Um pouco de teoria
"Usuário ativo" pode aceitar conexões de entrada. De fato, a solicitação de conexão dele é na verdade um convite.
"Usuário passivo" geralmente pode apenas fazer solicitações de saída. Através do hub, ele pede que um usuário ativo envie um convite – e a conexão é estabelecida.
E sim, esse mecanismo não depende da versão do protocolo IP utilizada.
O Cisne, o Caranguejo e a Perch
Vamos falar sobre o software cliente.
O suporte a IPv6 no é experimental. Não há configurações específicas para ele, e fiquei surpreso ao ver diferentes modos de operação para diferentes versões de IP, sendo que o modo passivo é especificamente para a versão seis, mas isso não está garantido.
Não foi possível obter o modo ativo com a configuração manual, mesmo ao usar explicitamente um domínio com um registro AAAA como IP WAN, mas no modo automático com UPnP tudo funcionou corretamente.
também tem suporte a conexões IPv6, implementado de forma totalmente separada do IPv4. Além disso, este cliente modifica as tags de usuários para exibir os modos de operação de ambos os protocolos IP simultaneamente. Os hubs não conseguem fazer isso (ainda), o que é uma pena.
Devo esclarecer de imediato: o AirDC++ faz isso por conta própria. No futuro, para maior conveniência, usarei combinações como AP ou AA como uma indicação dos modos ativo ou passivo para IPv4 e IPv6, respectivamente, e não sua exibição na tag do cliente real em um hub real. Isso é importante.
Em nosso experimento, usaremos FlylinkDC++ como cliente, que não tem conhecimento de IPv6. Também é relevante observar que o suporte a não estava implementado até o momento da redação deste artigo em nenhum lugar.
Início
Primeiro, vamos examinar as conexões claramente impossíveis entre usuários de diferentes versões do protocolo IP. Para o teste, usaremos com registros A e AAAA de recursos para o nome de domínio, que atua como seu endereço.
Note que, aqui, em uma tentativa (real) de se conectar a um usuário com um endereço IP de sexta versão, um erro é exibido.
Hub: [Saída][IPv4:412] DRCM AACX AACU ADCS/0.10 337151563
Hub: [Entrada][IPv4:412] DCTM AACU AACX ADCS/0.10 1988 337151563
Hub: [Saída][IPv4:412] DSTA AACX AACU 240 IPsunknownTraduzindo para o humano, isso soa como
P4: – Posso me conectar a você?
A6: – Conecte-se!
P4: – A vida é dolorosa 0_0
Um pequeno dicionário, se necessário, .
E se, ao contrário, a conexão for iniciada A4, então o erro não é exibido, e a conexão simplesmente "fica presa".
Hub: [Saída][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Ser, e não parecer
O que importa é o modo de conexão exibido no hub.
Clientes sem suporte a IPv6 deverão ver usuários conectados através dele como absolutamente passivos, simplesmente porque para eles o hub não preenche I4 ou I6 o campo correspondente.
FlylinkDC++ vs. IPv6
Na prática, a situação é mais simples e mais complexa ao mesmo tempo.
AirDC++ vs. IPv6
Mais simples, porque IPv6 tem prioridade sobre IPv4, e isso é entendido. É através dele (embora com a opção correspondente disponível para redefinição) que a conexão será estabelecida com o hub, e seu cliente ativo irá sugerir para o passivo se conectar.
Mais complicado, porque se houver usuários no hub com suporte a IPv6, mas conectados estritamente através de um endereço IPv4, então...
… então você pode se conectar a eles (aleatoriamente) sem ter IPv4.
Observe que o cliente remoto se identificou como ativo, mas está sendo tratado como passivo. Por quê?
Deixe ele lá na balança.
Agora vamos tentar conectar clientes uns aos outros com conjuntos de suporte ao protocolo IP que são diversos, mas que compartilham IPv4.
Sim, é uma pena que os usuários passivos tenham que esperar de lado. Mas não há como ajudar, pois o endereço IP visível deles não tem importância – é para isso que eles são passivos.
Olha! O cliente ativo envia ?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.
Por que isso acontece? Consultamos o desenvolvedor e obtemos a resposta:
não é bom se o outro usuário não suportar IPv6.
E não dá para discutir! Mas isso já requer uma lógica interna, independente do hub (veja o código e ). Não há como ajudar os passivos, pois
Modo ativo =
As tentativas de conexão entre clientes com conjuntos de suporte ao protocolo IP comuns em IPv6 parecem ser as seguintes. Lembro que conseguir PA para DC++ não consegui.
E mais uma vez uma surpresa. Conclui-se que o modo passivo para IPv6, que o DC++ demonstra, é ou uma fraude intencional, ou um bug.
E agora?
Atualmente existem exatamente duas maneiras de resolver todos os problemas de conexão possíveis entre usuários em diferentes modos e com diferentes conjuntos de suporte ao protocolo IP.
A primeira – desativar completamente o IPv6 ou, ao contrário, criar um hub para funcionar somente através dele.
A segunda – esta , que está apenas começando a fase de testes.
E, ao ficar relutante em configurar o modo ativo para funcionar no DC, lembre-se:
A quem tem, será dado, e a quem não tem, será tirado até mesmo o que pensa ter. Lc. 8:18
Fonte: habr.com
