Es ist interessant, die Entwicklung eines File-Sharing-Netzwerks zu beobachten, aber noch interessanter ist es, daran teilzunehmen.
Heutzutage erhält ein neu ernanter Administrator beim Einrichten und Starten eines modernen Hubs nahezu uneingeschränkten Zugriff auf das gesamte erarbeitete Wissen und die gesammelten Erfahrungen seiner Vorgänger in diesem Bereich. Er verfügt über ein System, das bereit für Erweiterungen und Anpassungen ist, auch mithilfe zahlreicher Skripte.
C Hubs anders. Die Struktur dieses Protokolls sieht Erweiterbarkeit vor. Willst du ein neues Feature? Na dann – schlage vor, fördere, setze um, implementiere, nutze es.
Folglich kann man "out of the box" zwar einen fertigen Hub bekommen, aber ihn einfach zu starten und dann zu vergessen, wäre nicht gut. Erweiterbarkeit im historischen Kontext bedeutet auch, dass eine unterschiedliche Anzahl verschiedener Funktionen in der Client- und Server-Software je nach Version vorhanden sein kann. Und was bei einem Benutzer ohne Probleme funktioniert, kann mit dem Client eines anderen inkompatibel sein, und das muss berücksichtigt werden.
So ist es auch mit IPv6. Der alte NMDC kann es einfach nicht, aber ADC ist grundsätzlich bereit dafür. Doch so einfach ist es nicht.
Ein wenig Theorie
Ein "aktiver" Benutzer kann eingehende Verbindungen annehmen. Tatsächlich ist die von ihm ausgehende Verbindungsanfrage eine Einladung.
Ein "passiver" Benutzer kann im allgemeinen nur ausgehende Anfragen nutzen. Über den Hub kann er 16 BYN (~475 RUB) für ein Subnetz /64. die Einladung eines aktiven Benutzers senden – und die Verbindung wird hergestellt.
Und ja, dieser Mechanismus ist unabhängig von der verwendeten IP-Protokollversion.
Der Schwan, der Krebs und der Hecht
Lass uns über die Client-Software sprechen.
Die Unterstützung von IPv6 in ist experimenteller Natur. Es gibt keine speziellen Einstellungen dafür, und es war umso erstaunlicher für mich, verschiedene Betriebsarten für verschiedene IP-Versionen zu sehen, wobei die passive genau für die sechste bestimmt ist, aber das ist ungenau.
Es war nicht möglich, den aktiven Modus bei manueller Konfiguration zu erhalten, selbst nicht bei expliziter Verwendung einer Domain mit AAAA-Eintrag als WAN-IP; aber im automatischen Modus unter Verwendung von UPnP funktionierte alles wie es sollte.
verfügt ebenfalls über die Unterstützung von IPv6-Verbindungen, die vollständig unabhängig von IPv4 umgesetzt ist. Darüber hinaus modifiziert dieser Client die Tags der Nutzer so, dass die Betriebsmodi beider IP-Protokolle gleichzeitig angezeigt werden. Die Hubs können dies (noch) nicht, was schade ist.
Ich möchte gleich klarstellen: AirDC++ macht das so nur für sich selbst. In der Folge werde ich Bezeichnungen wie AP oder AA als Hinweis auf die aktiven oder passiven Betriebsmodi für IPv4 und IPv6 verwenden, nicht deren Anzeige im Tag des echten Clients auf einem echten Hub. Das ist wichtig.
In unserem Experiment werden wir FlylinkDC++ als Client verwenden, der mit IPv6 ganz und gar nicht vertraut ist. Es sollte auch bemerkt werden, dass die Unterstützung für zum Zeitpunkt des Schreibens des Artikels nirgendwo implementiert war.
Einleitung
Zuerst betrachten wir mit Sicherheit unmögliche Verbindungen zwischen Nutzern unterschiedlicher IP-Protokollversionen. Für den Test wird ein mit A- und AAAA-Ressourceneinträgen für den Domainnamen, der als seine Adresse fungiert.
Bitte beachten Sie, dass beim (tatsächlichen) Versuch, auf einen Nutzer mit einer IP-Adresse der sechsten Version zuzugreifen, ein Fehler ausgegeben wird.
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 IPsunknownIn menschlicher Übersetzung klingt das wie
P4: – Darf ich mich anhängen?
A6: – Häng dich an!
P4: – Das Leben ist Schmerz 0_0
Ein kurzer Wortschatz, falls nötig, .
Und wenn umgekehrt, und die Verbindung initiiert A4, wird kein Fehler ausgegeben, und die Verbindung bleibt einfach "hängen".
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Sein, und nicht scheinen
Was wichtig ist, ist der angezeigte Verbindungsmodus auf dem Hub.
Clients ohne Unterstützung für IPv6 müssen die über ihn verbundenen Nutzer als eindeutig passiv sehen, einfach weil der Hub für sie das Feld nicht ausfüllt. I4 oder I6 entsprechend.
FlylinkDC++ vs. IPv6
In der Realität ist die Situation gleichzeitig einfacher und komplizierter.
AirDC++ vs. IPv6
Einfacher, weil IPv6 Vorrang vor IPv4 hat, und das ist klar. Genau über ihn (obwohl mit der entsprechenden Option eine Überschreibung möglich ist) wird die Verbindung zum Hub hergestellt, und sein aktiver Client wird für die Verbindung mit dem passiven anbieten.
Komplizierter, weil, wenn Benutzer mit IPv6-Unterstützung im Hub vorhanden sind, diese aber strikt über eine IPv4-Adresse verbunden sind, dann…
… mit ihnen kann man sich (willkürlich) verbinden, ohne überhaupt IPv4 zu haben.
Bitte beachten Sie, dass der entfernte Client sich als aktiv bezeichnet hat, aber als passiv behandelt wird. Warum?
Wohin auch immer!
Jetzt versuchen wir, Clients mit verschiedenen, aber teilweise gemeinsamen IPv4-Protokollunterstützungssets miteinander zu verbinden.
Ja, es ist schade, dass passive Benutzer am Rande stehen müssen. Aber man kann nichts dagegen tun, da ihre sichtbare IP-Adresse keine besondere Bedeutung hat – dafür sind sie schließlich passiv.
Wow! Der aktive Client sendet ?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.
Warum ist das so? Wir fragen den Entwickler und erhalten die Antwort:
ist nicht gut, wenn der andere Benutzer IPv6 nicht unterstützt
Und da kann man nicht widersprechen! Aber das erfordert bereits eine interne, vom Hub unabhängige Logik (siehe Code und ). Passiven kann man nach wie vor nicht helfen, weil
Aktivmodus =
Versuche, Verbindungen zwischen Clients mit gemeinsamen IPv6-Protokollunterstützungssets herzustellen, sehen folgendermaßen aus. Ich erinnere daran, dass ich PA für DC++ nicht erreichen konnte.
Und schon wieder eine Überraschung. Es sieht so aus, als wäre der passive Modus für IPv6, den DC++ demonstriert, entweder ein absichtlicher Fake oder ein Bug.
Was folgt jetzt?
Derzeit gibt es genau zwei Möglichkeiten, alle möglichen Verbindungsprobleme von Benutzern in verschiedenen Modi und mit unterschiedlichen IPv4-Protokollunterstützungssets zu lösen.
Erstens – IPv6 ganz zu dämpfen oder umgekehrt, einen Hub nur für dessen Nutzung zu erstellen.
Zweitens – das hier , das gerade erst in die Testphase eintritt.
Nun, während Sie faul sind, um den aktiven Modus für die Arbeit in DC zu konfigurieren, denken Sie daran:
Dem, der hat, wird gegeben werden; dem, der nicht hat, wird auch das genommen, was er meint zu haben. Lk. 8:18
Quelle: habr.com
