Brug af IPv6 med Advanced Direct Connect

Det er interessant at se udviklingen af ​​fildelingsnetværket, men det er endnu mere interessant at deltage i det.

I dag installerer og lancerer en moderne NMDC hub, får den nyslåede administrator adgang til næsten alle de udviklinger og erfaringer, der er akkumuleret i dette område af hans forgængere. Det har et system klar til udvidelse og tilpasning, herunder ved hjælp af adskillige scripts.

С ADC nav ellers. Designet af denne protokol er beregnet til at kunne udvides. Vil du have en ny funktion? Nå, tilbud det, promover det, implementer det, implementer det, brug det.

Oversæt til engelsk

Som et resultat kan du selvfølgelig få en færdiglavet hub ud af kassen, men blot at lancere den og glemme alt om den vil ikke være godt. Udvidelsesmuligheder i en historisk kontekst indebærer også tilstedeværelsen af ​​et forskelligt antal forskellige funktioner i klient- og serversoftware, afhængigt af versionen. Og hvad der vil fungere uden problemer for en bruger, kan være uforeneligt med en andens klient, og dette skal tages i betragtning.

Dette skete med IPv6. Den gamle mand NMDC ved i princippet ikke, hvordan man gør det, men ADC selv er klar til det. Dog ikke alt så enkelt.

Bare en lille teori

Den "aktive" bruger kan acceptere indgående forbindelser. Faktisk er forbindelsesanmodningen, der kommer fra den, faktisk invitation.

En "passiv" bruger kan generelt kun bruge udgående anmodninger. Gennem navet han spørger den aktive bruger sender en invitation - og forbindelsen er etableret.

Brug af IPv6 med Advanced Direct Connect

Og ja, denne mekanisme afhænger ikke af den anvendte version af IP-protokollen.

Svane, krebs og gedder

Lad os tale om klientsoftware.

IPv6-understøttelse DC ++ er af eksperimentel karakter. Der er ingen separate indstillinger for det, og det var så meget desto mere overraskende for mig at se forskellige driftstilstande for forskellige versioner af IP, med passiv kun for den sjette, men dette er ikke nøjagtigt.

Det var ikke muligt at få den aktive tilstand under manuel konfiguration, selv når man eksplicit brugte et IP-domæne med en AAAA-record som WAN, men i automatisk tilstand ved brug af UPnP fungerede alt som forventet.

AirDC ++ har også understøttelse af IPv6-forbindelser, og det er implementeret helt adskilt fra IPv4. Desuden modificerer denne klient brugertags på en sådan måde, at de viser driftstilstande for begge IP-protokoller samtidigt. Navne ved ikke selv hvordan man gør dette (endnu), hvilket er ærgerligt.

Jeg skal straks tage forbehold: AirDC++ gør dette alene og for sig selv. I fremtiden vil jeg for nemheds skyld bruge kombinationer som AP eller AA som en indikation af aktive eller passive driftstilstande for henholdsvis IPv4 og IPv6, snarere end deres visning i det rigtige klienttag på den rigtige hub. Det er vigtigt.

I vores eksperiment vil vi bruge FlylinkDC++ som klient slet ikke bekendt med IPv6. Det skal også bemærkes, at støtte NATT for ham på tidspunktet for skrivningen var denne artikel ikke implementeret nogen steder.

begynder

Først og fremmest vil vi se på åbenlyst umulige forbindelser mellem brugere af forskellige versioner af IP-protokollen. Vil blive brugt til testen IPv6 klar hub med ressource A- og AAAA-records for domænenavnet, der fungerer som dets adresse.

Brug af IPv6 med Advanced Direct Connect

Bemærk venligst, at når du (faktisk) forsøger at kontakte en bruger med en version XNUMX IP-adresse, vises en fejl.

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 IPsunknown

I menneskelig oversættelse lyder det som

P4: – Må jeg klamre mig til dig?
A6: – Hold fast!
P4: – Livet er smerte 0_0

En kort ordbog, evt. her.

Og hvis det er omvendt, og forbindelsen starter A4, så vises ingen fejl, og forbindelsen hænger simpelthen.

Hub:	[Outgoing][IPv4:412]	 	DCTM AACX AACU ADCS/0.10 1993 3871342713

Vær, synes ikke at være

Det vigtige er forbindelsestilstanden, der vises på hubben.

Klienter uden IPv6-understøttelse bliver nødt til at se brugere, der er tilsluttet gennem det, som klart passive, simpelthen fordi hubben ikke fylder for dem I4 eller I6 felt i overensstemmelse hermed.

Brug af IPv6 med Advanced Direct Connect
FlylinkDC++ vs. IPv6

I virkeligheden er situationen enklere og mere kompleks på samme tid.

Brug af IPv6 med Advanced Direct Connect
AirDC++ vs. IPv6

Nemmere, fordi IPv6 har forrang over IPv4, og det er forståeligt. Det er gennem det (selvom tilsidesættelse er tilgængeligt ved hjælp af den tilsvarende mulighed), at forbindelsen til hub'en etableres, og den aktive klient vil tilbyde den til den passive klient til forbindelse.

Det er sværere, for hvis der er brugere med IPv6-understøttelse på hubben, men de er forbundet strengt via en IPv4-adresse, så...

Brug af IPv6 med Advanced Direct Connect

... så kan du oprette forbindelse til dem (tilfældigt) uden at have IPv4 overhovedet.

Bemærk venligst, at fjernklienten har udpeget sig selv som et aktiv, men behandles som en forpligtelse. Hvorfor?

Smid ham i en gynge

Lad os nu prøve at forbinde klienter med forskellige, men fælles med hensyn til IPv4, sæt IP-protokolunderstøttelse til hinanden.

Brug af IPv6 med Advanced Direct Connect

Ja, det er ærgerligt, at passive brugere skal ryge på sidelinjen. Men dette kan ikke hjælpes, da deres synlige IP-adresse ikke er særlig vigtig - det er derfor, de er forpligtelser.

Brug af IPv6 med Advanced Direct Connect

Bah! Den aktive klient sender passiv kommando?.. Det ville være logisk at forvente en "fast" forbindelse, men nej, det viser sig under betingelserne A4.

Hvorfor det? Vi kontakter udvikleren og får svaret:

CTM er ikke godt, hvis den anden bruger ikke understøtter IPv6

Og du kan ikke argumentere! Men dette kræver intern logik, uafhængig af hub'en (se kode her и her). Det er stadig umuligt at hjælpe passive, pga

Aktiv tilstand = TCPx+IPx

Forsøg på at oprette forbindelse mellem klienter med almindelige IPv6 IP-supportsæt ser sådan ud. Lad mig minde dig om, opnå PA Det lykkedes ikke for DC++.

Brug af IPv6 med Advanced Direct Connect

Og igen en overraskelse. Det viser sig, at den passive tilstand for IPv6, som DC++ demonstrerer, enten er en bevidst falsk eller en fejl.

Hvad er det næste?

I øjeblikket er der præcis to måder at løse alle mulige problemer med at forbinde brugere i forskellige tilstande og med forskellige sæt IP-protokolunderstøttelse.

Den første er at slå IPv6 helt fra eller omvendt oprette en hub til kun at arbejde igennem den.

Den anden er denne udvidelse, som netop nærmer sig teststadiet.

Nå, hvis du er for doven til at konfigurere den aktive tilstand til at arbejde i DC, husk:

Den, der har, hvad der skal gives ham, og den, der ikke har, selv hvad han tror, ​​han har, vil blive taget fra ham. OKAY. 8:18

Kilde: www.habr.com

Tilføj en kommentar