At følge udviklingen af fildelingsnetværket er interessant, men endnu mere spændende er det at deltage i det.
I dag, når du installerer og starter et moderne hub, får den nyudnævnte administrator adgang til næsten alle de erfaringer og opnåelser, som hans forgængere har gjort i dette område. Han har et system, der er klar til udvidelse og tilpasning, blandt andet ved hjælp af adskillige scripts.
Med hubs på en anden måde. Strukturen af denne protokol muliggør udvidelighed. Ønsker du en ny funktion? Jamen så foreslå, promover, implementer, indfør, og brug den.
Som følge heraf kan man "out of the box" selvfølgelig få en færdig hub, men blot at starte den og glemme den ville være uhensigtsmæssigt. Udvidelighed i historisk kontekst indebærer også, at der findes forskellige funktioner i klient- og serverprogramvaren afhængigt af versionen. Og det, der fungerer uden problemer for en bruger, kan vise sig at være inkompatibelt med en anden brugers klient, og det er noget, man skal tage højde for.
Det skete også med IPv6. Den gamle NMDC kan i princippet ikke håndtere det, men ADC er i stand til det. Men det er ikke så enkelt.
Bare lidt teori
"Aktiv" bruger kan acceptere indgående forbindelser. Faktisk er anmodningen fra ham om at oprette forbindelse reelt en invitation.
"Passiv" bruger kan som hovedregel kun bruge udgående anmodninger. Gennem hubben anmoder den aktive bruger om at sende en invitation – og forbindelsen etableres.
Og ja, denne mekanisme er uafhængig af hvilken version af IP-protokollen der anvendes.
Svanen, Krebsen og Ålen
Lad os tale om klientsoftware.
Understøttelse af IPv6 i er eksperimentel. Der er ingen separate indstillinger for det, og det var derfor overraskende for mig at se forskellige driftsformer for forskellige versioner af IP, hvor passive netop var for den sjette, men det er ikke præcist.
Det lykkedes ikke at få aktiv tilstand ved manuel opsætning, selv ikke med en åbenlys brug af et domæne med AAAA-post som WAN IP, men i automatisk tilstand med brug af UPnP fungerede alt som det skulle.
har også støtte for IPv6-forbindelser, og det er implementeret helt separat fra IPv4. Desuden modificerer denne klient bruger-tags således, at den viser driftsmåder for begge IP-protokoller samtidig. Selve hubberne kan ikke gøre dette (endnu), hvilket er en skam.
Jeg må straks sige: AirDC++ gør det på denne måde for sig selv. Fremover vil jeg bruge kombinationer som AP eller AA som angivelse af aktive eller passive driftsmåder for hhv. IPv4 og IPv6, snarere end deres visning i tagget for den virkelige klient på den virkelige hub. Dette er vigtigt.
I vores eksperiment vil vi bruge FlylinkDC++ som klient, der slet ikke kender til IPv6. Det skal også bemærkes, at støtte for på det tidspunkt, hvor denne artikel blev skrevet, ikke var implementeret nogen steder.
Start
Først skal vi se på åbenlyst umulige forbindelser mellem brugere af forskellige versioner af IP-protokollen. Til testen vil der blive brugt med ressourcemæssige A- og AAAA-poster for domænenavnet, der fungerer som dens adresse.
Bemærk, at her ved (faktisk) forsøg på at kontakte en bruger med en IP-adresse af sjette version 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 IPsunknownOversat til menneskelig tale lyder det som
P4: – Må jeg hægte mig på dig?
A6: – Hægt dig på!
P4: – Livet er en smerte 0_0
En kort ordbog, hvis det skulle være relevant, .
Og hvis det omvendte er tilfældet, og forbindelsen initieres A4, så vises der ikke nogen fejl, og forbindelsen fryser blot.
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713At være, ikke at fremstå
Det vigtige er den vises forbindelse til hubben.
Klienter uden støtte til IPv6 skal se brugere, der er tilsluttet gennem det, som entydigt passive, blot fordi hubben ikke udfylder I4 eller I6 feltet i overensstemmelse hermed.
FlylinkDC++ vs. IPv6
I virkeligheden er situationen både enklere og mere kompleks.
AirDC++ vs. IPv6
Enklere, fordi IPv6 har forrang over IPv4, og det er tydeligt. Det er netop gennem det (selvom tilsvarende indstilling muliggør overstyring) at forbindelsen vil blive etableret med hubben, og dens aktive klient vil tilbyde tilslutning til den passive.
Mere komplekst, fordi hvis der er brugere med støtte til IPv6 på hubben, men de kun er tilsluttet gennem en IPv4-adresse, så...
… så kan du forbinde dig med dem (mere eller mindre) uden overhovedet at have IPv4.
Bemærk, at den fjerntliggende klient har defineret sig som aktiv, men behandles som passiv. Hvorfor?
Lad ham komme i gyngen.
Lad os nu prøve at forbinde klienter med forskellige, men vildt fælles IPv4-protokolunderstøttende sæt.
Ja, det er ærgerligt, at passive brugere måtte sidde på sidelinjen. Men man kan ikke hjælpe dem, da deres synlige IP-adresse ikke har nogen særlig betydning – det er netop derfor, de er passive.
Nå! Den aktive klient sender. ?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.
Hvorfor er det sådan? Vi henvender os til udvikleren og får svaret:
isn’t good if the other user doesn’t support IPv6
Og der kan man ikke diskutere! Men det kræver allerede en intern, hub-uafhængig logik (se kode og ). Passive kan stadig ikke hjælpes, fordi
Aktiv tilstand =
Forsøg på at forbinde klienter med fælles IPv6-protokolunderstøttende sæt ser således ud. Jeg minder om, at det er nødvendigt PA for DC++ har jeg ikke kunnet opnå.
Og endnu en overraskelse. Det viser sig, at den passive tilstand for IPv6, som DC++ demonstrerer, enten er en bevidst falskhed eller en fejl.
Hvad nu?
I øjeblikket er der præcist to måder at løse alle potentielle forbindelsesproblemer mellem brugere i forskellige tilstande og med forskellige protokolunderstøttende sæt.
Den første – helt deaktivere IPv6 eller omvendt, skabe en hub kun til brug af det.
Den anden – dette , som netop er ved at nå teststadiet.
Og mens du dovner med at konfigurere aktiv tilstand til at arbejde i DC, husk:
Den der har, til ham skal der gives, og den der ikke har, vil miste selv det, han tror, han har. Lk. 8:18
Kilde: habr.com
