C’est intéressant d’observer le développement du réseau de partage de fichiers, mais c’est encore plus intéressant d’y participer.
Aujourd'hui, l'installation et le lancement d'un hub, le nouvel administrateur a accès à presque tous les développements et expériences accumulés dans ce domaine par ses prédécesseurs. Il dispose d'un système prêt à être étendu et personnalisé, notamment à l'aide de nombreux scripts.
С autrement. La conception de ce protocole se veut extensible. Voulez-vous une nouvelle fonctionnalité? Eh bien, proposez-le, promouvez-le, mettez-le en œuvre, mettez-le en œuvre, utilisez-le.
En conséquence, vous pouvez bien sûr obtenir un hub prêt à l'emploi, mais simplement le lancer et l'oublier ne sera pas une bonne chose. L'extensibilité dans un contexte historique implique également la présence d'un nombre différent de fonctions différentes de logiciels client et serveur, selon la version. Et ce qui fonctionnera sans problème pour un utilisateur peut être incompatible avec le client d'un autre, et il faut en tenir compte.
Cela s'est produit avec IPv6. Le vieil homme NMDC ne sait pas comment le faire en principe, mais l'ADC lui-même est prêt pour cela. Cependant, tout n’est pas si simple.
Juste un peu de théorie
L'utilisateur "actif" peut accepter les connexions entrantes. En fait, la demande de connexion qui en émane est en fait invitation.
Un utilisateur « passif » ne peut généralement utiliser que des requêtes sortantes. Grâce au hub, il просит l'utilisateur actif envoie une invitation - et la connexion est établie.
Et oui, ce mécanisme ne dépend pas de la version du protocole IP utilisé.
Cygne, cancer et brochet
Parlons du logiciel client.
Prise en charge d'IPv6 est de nature expérimentale. Il n'y a pas de paramètres séparés pour cela, et c'était d'autant plus surprenant pour moi de voir différents modes de fonctionnement pour différentes versions d'IP, avec passif juste pour la sixième, mais ce n'est pas exact.
Il n'a pas été possible d'obtenir le mode actif lors de la configuration manuelle, même en utilisant explicitement un domaine IP avec un enregistrement AAAA comme WAN, mais en mode automatique utilisant UPnP, tout a fonctionné comme prévu.
prend également en charge les connexions IPv6 et est implémenté de manière complètement distincte d'IPv4. De plus, ce client modifie les tags utilisateur de manière à afficher simultanément les modes de fonctionnement des deux protocoles IP. Les hubs eux-mêmes ne savent pas (encore) comment faire cela, ce qui est dommage.
Je dois immédiatement faire une réservation : AirDC++ le fait seul et pour lui-même. À l'avenir, pour plus de commodité, j'utiliserai des combinaisons comme AP ou AA comme indication des modes de fonctionnement actifs ou passifs pour IPv4 et IPv6, respectivement, plutôt que leur affichage dans la balise client réelle sur le hub réel. C'est important.
Dans notre expérience, nous utiliserons FlylinkDC++ en tant que client pas du tout familier avec IPv6. Il convient également de noter que le soutien pour lui, au moment de la rédaction de cet article, cet article n'était implémenté nulle part.
début
Tout d’abord, nous examinerons les connexions évidemment impossibles entre utilisateurs de différentes versions du protocole IP. Sera utilisé pour le test avec les enregistrements de ressource A et AAAA pour le nom de domaine faisant office d'adresse.
Veuillez noter que lorsque vous essayez (réellement) de contacter un utilisateur avec une adresse IP version XNUMX, une erreur s'affiche.
Hub: [Outgoing][IPv4:412] DRCM AACX AACU ADCS/0.10 337151563
Hub: [Incoming][IPv4:412] DCTM AACU AACX ADCS/0.10 1988 337151563
Hub: [Outgoing][IPv4:412] DSTA AACX AACU 240 IPsunknownEn traduction humaine, cela ressemble à
P4 : – Puis-je m'accrocher à toi ?
A6 : – Accrochez-vous !
P4 : – La vie est une douleur 0_0
Un petit dictionnaire, si nécessaire, .
Et si c'est l'inverse et que la connexion s'initie A4, aucune erreur ne s'affiche et la connexion se bloque simplement.
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Être, ne pas avoir l'air d'être
Ce qui est important, c'est le mode de connexion affiché sur le hub.
Les clients sans support IPv6 devront considérer les utilisateurs connectés via celui-ci comme clairement passifs, simplement parce que le hub ne les remplit pas. I4 ou I6 champ en conséquence.
FlylinkDC++ contre. IPv6
En réalité, la situation est à la fois plus simple et plus complexe.
AirDC++ contre. IPv6
Plus simple car IPv6 prime sur IPv4, et c’est compréhensible. C'est via lui (bien que le remplacement soit disponible à l'aide de l'option correspondante) que la connexion au hub sera établie, et le client actif la proposera au client passif pour la connexion.
C'est plus difficile, car s'il y a des utilisateurs prenant en charge IPv6 sur le hub, mais qu'ils sont connectés strictement via une adresse IPv4, alors...
... alors vous pouvez vous y connecter (au hasard) sans avoir IPv4 du tout.
Veuillez noter que le client distant s'est désigné comme un actif, mais est traité comme un passif. Pourquoi?
Jetez-le dans une balançoire
Essayons maintenant de connecter des clients avec des ensembles de protocoles IP différents, mais communs en termes d'IPv4, les uns aux autres.
Oui, c’est dommage que les utilisateurs passifs doivent fumer en marge. Mais on n’y peut rien, car leur adresse IP visible n’est pas particulièrement importante – c’est pourquoi ils constituent un passif.
Bah ! Le client actif envoie ?.. Il serait logique de s'attendre à une connexion "bloquée", mais non, cela s'avère dans les conditions A4.
Pourquoi donc? Nous contactons le développeur et obtenons la réponse :
ce n'est pas bon si l'autre utilisateur ne prend pas en charge IPv6
Et on ne peut pas discuter ! Mais cela nécessite une logique interne, indépendante du hub (voir code и ). Il est encore impossible d'aider les passifs, car
Mode actif =
Les tentatives de connexion entre clients avec des ensembles de prise en charge IP IPv6 communs ressemblent à ceci. Laissez-moi vous rappeler, réalisez PA Je n'ai pas réussi pour DC++.
Et encore une surprise. Il s’avère que le mode passif pour IPv6, démontré par DC++, est soit un faux délibéré, soit un bug.
Quelle est la prochaine?
Actuellement, il existe exactement deux manières de résoudre tous les problèmes possibles en connectant les utilisateurs dans différents modes et avec différents ensembles de prise en charge du protocole IP.
La première consiste à désactiver complètement IPv6 ou, à l'inverse, à créer un hub pour fonctionner uniquement via lui.
Le deuxième c'est ça , qui approche tout juste de la phase de test.
Eh bien, si vous êtes trop paresseux pour configurer le mode actif pour travailler dans DC, rappelez-vous :
Celui qui a, ce qui lui sera donné, et celui qui n'a pas, même ce qu'il pense avoir, lui sera ôté. Lx 8:18
Source: habr.com