Sledovat vývoj souborového sdílení je zajímavé, ale ještě zajímavější je se na něm podílet.
V současnosti, když nastavujete a spouštíte moderní hub, nový administrátor získává přístup prakticky ke všem zkušenostem a znalostem jeho předchůdců. Disponuje systémem, který je připraven k rozšíření a přizpůsobení, také s pomocí mnoha skriptů.
S huby jinak. Struktura tohoto protokolu předpokládá rozšiřitelnost. Chcete novou funkci? Pak navrhněte, propagujte, realizujte, implementujte, využívejte.
V důsledku toho můžete "z krabice" samozřejmě získat hotový hub, ale jednoduše ho spustit a zapomenout na něj by nebylo dobré. Rozšiřitelnost v historickém kontextu také zahrnuje různé funkce klientského a serverového softwaru v závislosti na verzi. A to, co funguje bez problémů jednomu uživateli, může být nekompatibilní s klientem jiného, což je třeba zohlednit.
Tak se stalo i s IPv6. Starý NMDC jej v podstatě nepodporuje, ale ADC je na něj sám o sobě připraven. Avšak, není to tak jednoduché.
Trocha teorie
"Aktivní" uživatel může přijímat příchozí spojení. Vlastně, od něj vycházející požadavek na spojení je ve skutečnosti pozvánkou.
"Pasivní" uživatel obvykle může používat pouze odchozí požadavky. Prostřednictvím hubu on žádá aktivního uživatele, aby mu poslal pozvánku – a spojení je poté navázáno.
A ano, tento mechanismus nezávisí na verzi používaného protokolu IP.
Labutě, rak a štika
Pojďme mluvit o klientském softwaru.
Podpora IPv6 v má experimentální charakter. Pro něj neexistují žádná specifická nastavení, a tím více mě překvapilo vidět různé režimy práce pro různé verze IP, přičemž pasivní je právě pro šestou, ale to není přesné.
Získat aktivní režim při ručním nastavení se nepodařilo ani při jasném použití domény s AAAA záznamem jako WAN IP, ale v automatickém režimu s použitím UPnP to fungovalo, jak mělo.
také podporuje IPv6 připojení, a to zcela odděleně od IPv4. Navíc tento klient modifikuje tagy uživatelů tak, aby zobrazoval režimy fungování pro oba IP protokoly současně. Samotné huby to (zatím) neumí, což je škoda.
Okamžitě musím zdůraznit: AirDC++ to dělá pouze pro sebe. V dalším pro pohodlí budu používat kombinace jako AP nebo AA jako označení pro aktivní nebo pasivní režimy fungování pro IPv4 a IPv6, nikoli jejich zobrazení v tagu skutečného klienta na skutečném hubu. To je důležité.
V našem experimentu budeme používat FlylinkDC++ jako klienta, který vůbec není obeznámen s IPv6. Je také důležité zmínit, že podpora pro něj v době psaní článku nebyla nikde realizována.
Začátek
Nejdříve se podíváme na zjevně nemožná připojení mezi uživateli různých verzí IP protokolu. Pro test se bude používat s A- a AAAA-záznamy pro doménové jméno, fungující jako jeho adresa.
Všimněte si, zde při (skutečném) pokusu o oslovení uživatele s IP adresou šesté verze se objevuje chyba.
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 IPsunknownV překladu do lidského jazyka to zní jako
P4: – Mohu se k tobě připojit?
A6: – Připoj se!
P4: – Život je bolest 0_0
Krátký slovníček, pokud něco chybí, .
A pokud naopak, a připojení iniciuje A4, chyba se nevytváří a připojení prostě „visí“.
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Být, ne zdát se
Co je důležité, je režim připojení zobrazený na hubu.
Klienti bez podpory IPv6 by měli vidět připojené uživatele přes něj jako jednoznačně pasivní, jednoduše proto, že pro ně hub nevyplňuje I4 nebo I6 pole odpovídajícím způsobem.
FlylinkDC++ vs. IPv6
Ve skutečnosti je situace jednodušší a složitější zároveň.
AirDC++ vs. IPv6
Jednodušší, protože IPv6 má prioritu před IPv4, a to je jasné. Právě přes něj (ačkoli je k dispozici předefinování pomocí příslušné možnosti) bude navázáno připojení k hubu a jeho aktivní klient nabídne pasivnímu připojení.
Složitější, protože pokud jsou na hubu uživatelé s podporou IPv6, ale připojeni jsou výhradně přes IPv4 adresu, pak…
… lze se s nimi spojit (náhodně) vůbec bez IPv4.
Všimněte si, že vzdálený klient se označil jako aktivní, ale zpracovává se jako pasivní. Proč?
Do něj ho na houpačku
Nyní se pokusíme spojit klienty s různými, ale společnými sadami podpory protokolu IP pro IPv4.
Ano, je škoda, že pasivní uživatelé musí kouřit na straně. Ale s tím se nedá nic dělat, protože jejich viditelná IP adresa nemá zvláštní význam – proto jsou tolik pasivní.
No tak! Aktivní klient posílá ?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.
Proč tomu tak je? Obracíme se na vývojáře a dostáváme odpověď:
není dobré, pokud druhý uživatel nepodporuje IPv6
A to se nedá popřít! Ale to už vyžaduje vnitřní logiku, nezávislou na hubu (viz kód a ). Pasivům stále není možné pomoci, protože
Aktivní režim =
Pokusy o spojení mezi klienty se společnými sadami podpory protokolu IP pro IPv6 vypadají následujícím způsobem. Připomínám, že dosáhnout PA pro DC++ se mi nepodařilo.
A zase překvapení. Ukazuje se, že pasivní režim pro IPv6, který DC++ demonstruje, je buď záměrný podvod, nebo chyba.
Co dál?
V současné době existují přesně dva způsoby, jak vyřešit všechny možné problémy s připojením uživatelů v různých režimech a s různými sadami podpory protokolu IP.
První – potlačit IPv6 úplně nebo naopak vytvořit hub, který bude fungovat pouze skrze něj.
Druhý – toto , které se právě dostává do fáze testování.
A při lenosti nastavovat aktivní režim pro práci v DC nezapomeňte:
Kdo má, tomu bude dáno, a kdo nemá, tomu bude vzato i to, co si myslí, že má. Lk. 8:18
Zdroj: habr.com
