Det er interessant å følge med på utviklingen av fildelingsnettverket, men enda mer interessant å delta i det.
I dag, ved å installere og starte moderne hub, får den nyutnevnte administratoren tilgang til nesten all erfaring og opplæring som tidligere har blitt opparbeidet innen dette området. Han har et system som er klart for utvidelser og tilpasninger, blant annet ved hjelp av mange skript.
C huber på en annen måte. Strukturen i denne protokollen forutsetter utvidbarhet. Ønsker du en ny funksjon? Vel, kom med forslag, fremdriv, implementer, innfør og bruk den.
Som et resultat kan du selvsagt få en ferdig hub "out of the box", men å bare starte den og glemme den vil ikke være tilrådelig. Utvidbarhet i en historisk kontekst involverer også tilstedeværelsen av et forskjellig antall funksjoner for klient- og serverprogramvare avhengig av versjonen. Og det som fungerer uten problemer for én bruker, kan være inkompatibelt med klienten til en annen, og dette må tas i betraktning.
Slik gikk det også med IPv6. Den gamle NMDC kan egentlig ikke håndtere det, men ADC er klart for det på egen hånd. Men alt er ikke så enkelt.
Litt teori
En "aktiv" bruker kan motta innkommende forbindelser. Egentlig er forespørselen om forbindelsen fra ham egentlig en invitasjon..
En "passiv" bruker kan generelt kun bruke utgående forespørsel. Gjennom huben ber den aktive brukeren om å sende en invitasjon – og forbindelsen oppnås.

Og ja, denne mekanismen er uavhengig av versjonen av IP-protokollen som brukes.
Svanen, krepsen og fisken
La oss snakke om klientprogramvaren.
Støtte for IPv6 i er eksperimentell. Det finnes ingen spesifikke innstillinger for det, og det overrasket meg å se forskjellige driftsmodi for forskjellige versjoner av IP, hvor passiv faktisk er for den sjette, men dette er usikkert.
Det ble ikke mulig å oppnå aktiv modus ved manuell innstilling selv med eksplisitt bruk av et domene med AAAA-opptaksadresse som WAN IP, men automatisk modus med å bruke UPnP fungerte som det skulle.
har også støtte for IPv6-tilkoblinger, og den er implementert helt separat fra IPv4. Dessuten modifiserer denne klienten bruker-tagene slik at driftsmodusene for begge IP-protokoller vises samtidig. Hubene kan (foreløpig) ikke gjøre dette, noe som er synd.
Jeg må umiddelbart påpeke at AirDC++ gjør dette både for seg selv. I det følgende vil jeg bruke kombinasjoner som AP eller AA for å indikere aktiv eller passiv driftsmodus for henholdsvis IPv4 og IPv6, og ikke deres visning i taggen til den virkelige klienten på den virkelige huben. Dette er viktig.
I vårt eksperiment vil vi bruke FlylinkDC++ som klient, som på ingen måte er kjent med IPv6. Det bør også bemerkes at støtten for for denne ikke var implementert noe sted på tidspunktet for artikkelens skriving.
Begynnelse
Først vil vi se på åpenbart umulige forbindelser mellom brukere med forskjellige versjoner av IP-protokollen. For testen vil det bli brukt med A- og AAAA-poster for domenenavnet som fungerer som adressen.

Vær oppmerksom på at det ved (faktisk) forsøk på å nå en bruker med en IP-adresse fra versjon seks vises en feil.
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 IPsunknownOversatt til menneskelig språk, høres dette ut som
P4: – Kan jeg knyte meg til deg?
A6: – Knytt deg til!
P4: – Livet er smerte 0_0
En kort ordbok, hvis nødvendig, .
Og hvis det motsatte skjer, og tilkoblingen initierer A4, så vises ingen feil, og tilkoblingen bare «henger».
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Å være, og ikke bare å se ut som
Det viktige er tilkoblingsmodusen som vises på huben.
Klienter uten støtte for IPv6 vil se brukere tilkoblet gjennom den som entydig passive bare fordi huben ikke fyller ut I4 eller I6 feltet tilsvarende.

FlylinkDC++ vs. IPv6
I virkeligheten er situasjonen både enklere og mer komplisert.

AirDC++ vs. IPv6
Enklere, fordi IPv6 har prioritet over IPv4, og det er forståelig. Det er gjennom dette (selv om det er mulig å overstyre ved hjelp av passende alternativ) at tilkoblingen til huben vil bli etablert, og den aktive klienten vil tilby tilkobling til den passive.
Mer komplisert, fordi hvis det er brukere med støtte for IPv6 på huben, men de er tilkoblet strengt via IPv4-adresse, så...

… så kan de kobles sammen (tilfeldig) uten å ha IPv4.
Vær oppmerksom på at den eksterne klienten har identifisert seg som aktiv, men blir behandlet som passiv. Hvorfor?
Dit skal han i husken
Nå skal vi prøve å koble klienter sammen med forskjellige, men delvis felles IPv4-støtteprotokoller.

Ja, det er synd at passive brukere må stå på sidelinjen. Men det kan ikke gjøres noe med, siden deres synlige IP-adresse ikke har noen særlig betydning – det er derfor de er passive.

Åh! Den aktive klienten sender ?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.
Hvorfor er det slik? Vi kontakter utvikleren og får svar:
isn’t good if the other user doesn’t support IPv6
Og man kan ikke krangle med det! Men dette krever allerede intern, uavhengig logikk fra huben (se koden og ). Passive kan fortsatt ikke hjelpes, fordi
Aktiv modus =
Forsøk på å koble sammen klienter med felles IPv6-støtteprotokoller ser slik ut. Jeg minner om at det er vanskelig å oppnå PA for DC++ klarte jeg ikke.

Og igjen et overraskelse. Det viser seg at den passive modusen for IPv6, som DC++ viser, er enten en bevisst falskhet eller en bug.
Hva skjer videre?
For tiden finnes det nøyaktig to måter å løse alle mulige tilkoblingsproblemer for brukere i forskjellige moduser og med forskjellige IP-støtteprotokoller.
Den første er å skru ned IPv6 helt eller, motsatt, å lage en hub for bare å jobbe gjennom det.
Den andre er dette , som akkurat har kommet til teststadiet.
Og, når man unngår å sette opp aktiv modus for å fungere i DC, husk:
Den som har, skal få, og den som ikke har, skal miste selv det han tror han har. Lk. 8:18
Kilde: habr.com
