Observer l'évolution du réseau de partage de fichiers est intéressant, mais y participer est encore plus fascinant.
Aujourd'hui, lors de l'installation et du lancement d'un hub, l'administrateur novice a accès à presque tous les développements et à l'expérience accumulée dans ce domaine par ses prédécesseurs. Il dispose d'un système prêt à être étendu et personnalisé, y compris grâce à de nombreux scripts.
Avec hubs différemment. La structure de ce protocole permet l'extensibilité. Tu veux une nouvelle fonctionnalité ? Eh bien, propose, promeus, réalise, implémente, utilise.
Ainsi, « en boîte », on peut bien sûr obtenir un hub prêt à l'emploi, mais le lancer et l'oublier ne sera pas judicieux. L'extensibilité dans un contexte historique suppose également la présence d'un nombre différent de fonctions dans le logiciel client et serveur selon la version. Et ce qui fonctionnera sans problème pour un utilisateur, peut s'avérer incompatible avec le client d'un autre, et il convient de le prendre en compte.
Cela s'est également produit avec IPv6. Le vieux NMDC ne le prend pas en charge, tandis que l'ADC est théoriquement prêt pour cela. Cependant, tout n'est pas si simple.
Un peu de théorie
Un utilisateur « actif » peut accepter des connexions entrantes. En fait, une demande de connexion sortante de sa part est en réalité un invitation.
Un utilisateur « passif » ne peut généralement utiliser que des demandes sortantes. Par l'intermédiaire d'un hub, il demande à l'utilisateur actif d'envoyer une invitation – et la connexion est établie.
Et oui, ce mécanisme ne dépend pas de la version du protocole IP utilisée.
Le Cygne, le Crabe et la Perche
Parlons des logiciels clients.
Le support d'IPv6 dans est expérimental. Il n'y a pas de paramètres spécifiques à cet égard, et il était d'autant plus surprenant pour moi de voir différents modes de fonctionnement pour différentes versions d'IP, le mode passif étant justement pour la sixième, mais ce n'est pas précis.
Je n'ai pas réussi à obtenir le mode actif avec une configuration manuelle même en utilisant explicitement un domaine avec un enregistrement AAAA comme IP WAN, tandis que le mode automatique avec l'utilisation de UPnP a parfaitement fonctionné.
il supporte également les connexions IPv6, qui sont mises en œuvre complètement séparément d'IPv4. De plus, ce client modifie les balises des utilisateurs afin d'afficher les modes de fonctionnement pour les deux protocoles IP simultanément. Les hubs eux-mêmes ne sont pas encore capables de le faire (pour l'instant), ce qui est dommage.
Je dois d'abord préciser : AirDC++ fait cela pour lui-même. À l'avenir, pour plus de commodité, j'utiliserai des combinaisons comme AP ou AA pour indiquer les modes actifs ou passifs pour IPv4 et IPv6 respectivement, et non leur affichage dans la balise du véritable client sur un hub réel. C'est important.
Dans notre expérience, nous allons utiliser FlylinkDC++ comme client, qui ne connaît pas du tout IPv6. Il convient également de noter que le support pour lui n'avait pas encore été mis en œuvre à l'époque de la rédaction de cet article.
Début
Tout d'abord, nous examinerons les connexions manifestement impossibles entre des utilisateurs de différentes versions du protocole IP. Pour le test, nous utiliserons avec des enregistrements A et AAAA pour le nom de domaine qui agit comme son adresse.
Notez qu'ici, lors de la tentative (réelle) de connexion à un utilisateur avec une adresse IP de la sixième version, une erreur est affichée.
Hub: [Sortant][IPv4:412] DRCM AACX AACU ADCS/0.10 337151563
Hub: [Entrant][IPv4:412] DCTM AACU AACX ADCS/0.10 1988 337151563
Hub: [Sortant][IPv4:412] DSTA AACX AACU 240 IPs inconnuesEn langage humain, cela se traduit par
P4: – Puis-je me connecter à toi ?
A6: – Accroche-toi !
P4: – La vie, c'est souffrir 0_0
Un petit glossaire, au cas où, .
Et si, au contraire, la connexion est initiée A4, alors aucune erreur n'est affichée et la connexion simplement "se fige".
Hub: [Sortant][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Être, et non sembler
Ce qui est important, c'est le mode de connexion affiché sur le hub.
Les clients sans support pour IPv6 doivent voir les utilisateurs connectés à travers lui comme clairement passifs simplement parce que pour eux le hub ne remplit pas I4 ou I6 le champ correspondant.
FlylinkDC++ vs. IPv6
En réalité, la situation est à la fois plus simple et plus compliquée.
AirDC++ vs. IPv6
Plus simple, car IPv6 a la priorité sur IPv4, et c'est compréhensible. C'est par lui (bien que la redéfinition soit possible avec l'option correspondante) que la connexion avec le hub sera établie, et c'est également le client actif qui proposera la connexion au client passif.
Plus compliqué, car si le hub a des utilisateurs avec support IPv6, mais qu'ils sont strictement connectés via une adresse IPv4, alors...
… on peut se connecter avec eux (au hasard) sans avoir IPv4.
Attention, le client distant s'est identifié comme actif, mais il est traité comme passif. Pourquoi ?
Mince alors !
Essayons maintenant de connecter entre eux des clients avec des ensembles de protocoles IP variés, mais communs en partie à IPv4.
Oui, c'est dommage que les utilisateurs passifs doivent attendre sur le bord. Mais on ne peut rien y faire, car leur adresse IP visible n'a pas d'importance - c'est ce qui les rend passifs.
Ah ! Un client actif envoie ?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.
Pourquoi cela ? Nous contactons le développeur et obtenons la réponse :
n'est pas bon si l'autre utilisateur ne prend pas en charge IPv6.
Et on ne peut pas vraiment argumenter ! Mais cela nécessite déjà une logique interne, indépendante du hub (voir le code et ). Cependant, on ne peut toujours pas aider les passifs, car
Mode actif =
Les tentatives de connexion entre des clients avec des ensembles de support de protocole IP communs en IPv6 apparaissent comme suit. Rappelons que pour obtenir PA pour DC++, je n'ai pas réussi.
Et encore une surprise. Ainsi, le mode passif pour IPv6, comme le montre DC++, est soit un faux volontaire, soit un bug.
Et après ?
Il existe actuellement exactement deux façons de résoudre tous les problèmes possibles de connexion des utilisateurs dans différents modes et avec différentes ensembles de support de protocole IP.
La première consiste à désactiver complètement IPv6 ou, au contraire, à créer un hub qui ne fonctionne qu'à travers lui.
La seconde est celle-ci , qui vient juste de commencer la phase de test.
Et enfin, en vous contentant de configurer le mode actif pour fonctionner dans DC, n'oubliez pas :
À celui qui a, il sera donné, mais à celui qui n'a pas, même ce qu'il pense avoir lui sera enlevé. Lc. 8:18
Source : habr.com
