Je zajímavé sledovat vývoj sítě pro sdílení souborů, ale ještě zajímavější je se na něm podílet.
Dnes se instaluje a spouští moderní NMDC hub, nově ražený správce získá přístup k téměř všem vývojům a zkušenostem nashromážděným v této oblasti jeho předchůdců. Má systém připravený na rozšíření a přizpůsobení, a to i pomocí četných skriptů.
С Pobočník jinak náboje. Návrh tohoto protokolu má být rozšiřitelný. Chcete novou funkci? No, nabízet to, propagovat to, implementovat to, implementovat to, používat to.
Ve výsledku můžete samozřejmě hotový rozbočovač dostat z krabice, ale jednoduše jej spustit a zapomenout na něj nebude dobré. Rozšiřitelnost v historickém kontextu také znamená přítomnost různého počtu různých funkcí klientského a serverového softwaru v závislosti na verzi. A co bude jednomu uživateli bez problémů fungovat, může být nekompatibilní s klientem druhého a s tím je třeba počítat.
To se stalo s IPv6. Dědek NMDC to z principu neumí, ale samotné ADC je na to připravené. Nicméně, ne všechno tak jednoduché.
Docela trochu teorie
"Aktivní" uživatel může přijímat příchozí připojení. Ve skutečnosti požadavek na připojení, který z něj přichází, ve skutečnosti je pozvání.
"Pasivní" uživatel může obecně používat pouze odchozí požadavky. Přes rozbočovač on ptá se aktivní uživatel odešle pozvánku - a spojení je navázáno.
A ano, tento mechanismus nezávisí na verzi použitého IP protokolu.
Labuť, rakovina a šťuka
Pojďme se bavit o klientském softwaru.
podpora IPv6 DC + + má experimentální povahu. Neexistují pro to žádné samostatné nastavení a o to více mě překvapilo, že jsem viděl různé provozní režimy pro různé verze IP, s pasivním jen pro šestou, ale to není přesné.
Aktivní režim se při ruční konfiguraci nepodařilo dostat ani při explicitním použití IP domény s AAAA záznamem jako WAN, ale v automatickém režimu pomocí UPnP vše fungovalo podle očekávání.
AirDC++ má také podporu pro připojení IPv6 a je implementován zcela odděleně od IPv4. Tento klient navíc upravuje uživatelské tagy tak, aby zobrazoval provozní režimy pro oba IP protokoly současně. Samotné huby to (zatím) neumí, což je škoda.
Musím okamžitě provést rezervaci: AirDC++ to dělá sám a pro sebe. V budoucnu budu pro pohodlí používat kombinace jako AP nebo AA jako indikace aktivních nebo pasivních režimů provozu pro IPv4 a IPv6, v daném pořadí, spíše než jejich zobrazení ve skutečném klientském tagu na skutečném hubu. To je důležité.
V našem experimentu použijeme FlylinkDC++ jako klient vůbec nezná IPv6. Je třeba také poznamenat, že podpora Natt pro něj v době psaní tohoto článku nebyl nikde implementován.
začátek
Nejprve se podíváme na zjevně nemožná spojení mezi uživateli různých verzí IP protokolu. Bude použit pro zkoušku Hub připravený na IPv6 se zdrojovými A- a AAAA-záznamy pro název domény fungující jako jeho adresa.
Vezměte prosím na vědomí, že když se (ve skutečnosti) pokusíte kontaktovat uživatele s IP adresou verze XNUMX, zobrazí se chyba.
Klienti bez podpory IPv6 budou muset vidět uživatele připojené přes něj jako jasně pasivní, jednoduše proto, že se pro ně rozbočovač nenaplní. I4 nebo I6 pole podle toho.
FlylinkDC++ vs. IPv6
Ve skutečnosti je situace jednodušší a zároveň složitější.
AirDC++ vs. IPv6
Jednodušší, protože IPv6 má přednost před IPv4, a to je pochopitelné. Právě přes něj (ačkoli je k dispozici přepsání pomocí příslušné volby) dojde k navázání spojení s hubem a aktivní klient jej nabídne pasivnímu klientovi k připojení.
Je to složitější, protože pokud jsou na hubu uživatelé s podporou IPv6, ale jsou připojeni striktně přes IPv4 adresu, tak...
... pak se k nim můžete připojit (náhodně), aniž byste měli IPv4.
Vezměte prosím na vědomí, že vzdálený klient se označil jako aktivum, ale je s ním zacházeno jako se závazkem. Proč?
Hoď ho na houpačce
Nyní zkusme vzájemně propojit klienty s různými, ale z hlediska IPv4 běžnými sadami podpory IP protokolů.
Ano, je škoda, že pasivní uživatelé musí kouřit na okraji. Tomu však nelze pomoci, protože jejich viditelná IP adresa není nijak zvlášť důležitá – proto jsou závazky.
Bah! Aktivní klient odešle pasivní příkaz?.. Bylo by logické očekávat „zaseknuté“ spojení, ale ne, za podmínek to dopadá A4.
proč tomu tak je? Kontaktujeme vývojáře a dostaneme odpověď:
CTM není dobré, pokud druhý uživatel nepodporuje IPv6
A nemůžete se hádat! To však vyžaduje vnitřní logiku nezávislou na rozbočovači (viz kód zde и zde). Pasivům stále nelze pomoci, protože
Pokusy o připojení mezi klienty s běžnými sadami podpory IPv6 IP vypadají takto. Dovolte mi připomenout, dosáhnout PA U DC++ jsem neuspěl.
A opět překvapení. Ukazuje se, že pasivní režim pro IPv6, který DC++ demonstruje, je buď záměrný falešný, nebo chyba.
Co bude 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í je IPv6 úplně ztlumit nebo naopak vytvořit hub, který bude fungovat pouze přes něj.
Druhý je tento prodloužení, která se teprve blíží do fáze testování.
Pokud jste příliš líní nastavit aktivní režim pro práci v DC, nezapomeňte:
Kdo má, tomu bude dáno, a kdo nemá, bude mu odebráno i to, co si myslí, že má. OK. 8:18