Det er interessant å se utviklingen av fildelingsnettverket, men det er enda mer interessant å delta i det.
I dag installerer og lanserer en moderne navet, får den nyopprettede administratoren tilgang til nesten all utvikling og erfaring samlet i dette området av forgjengerne. Den har et system som er klart for utvidelse og tilpasning, inkludert ved hjelp av en rekke skript.
С nav ellers. Utformingen av denne protokollen er ment å være utvidbar. Vil du ha en ny funksjon? Vel, tilby det, promoter det, implementer det, implementer det, bruk det.
Som et resultat kan du selvfølgelig få en ferdig hub ut av esken, men bare å starte den og glemme den vil ikke være bra. Utvidbarhet i en historisk kontekst innebærer også tilstedeværelsen av et forskjellig antall forskjellige funksjoner til klient- og serverprogramvare, avhengig av versjonen. Og det som vil fungere uten problemer for en bruker kan være uforenlig med klienten til en annen, og dette må tas i betraktning.
Dette skjedde med IPv6. Gubben NMDC vet i prinsippet ikke hvordan det skal gjøres, men ADC selv er klar for det. Imidlertid er ikke alt så enkelt.
Bare en liten teori
Den "aktive" brukeren kan godta innkommende tilkoblinger. Faktisk er tilkoblingsforespørselen som kommer fra den faktisk invitasjon.
En "passiv" bruker kan vanligvis bare bruke utgående forespørsler. Gjennom navet han forespørsler den aktive brukeren sender en invitasjon - og forbindelsen er etablert.
Og ja, denne mekanismen er ikke avhengig av versjonen av IP-protokollen som brukes.
Svane, sjøkreps og gjedde
La oss snakke om klientprogramvare.
IPv6-støtte er eksperimentell i naturen. Det er ingen separate innstillinger for det, og det var desto mer overraskende for meg å se forskjellige driftsmoduser for forskjellige versjoner av IP, med passiv bare for den sjette, men dette er ikke nøyaktig.
Det var ikke mulig å få den aktive modusen under manuell konfigurasjon selv når man eksplisitt brukte et IP-domene med en AAAA-post som WAN, men i automatisk modus ved bruk av UPnP fungerte alt som forventet.
har også støtte for IPv6-tilkoblinger, og den implementeres helt separat fra IPv4. Dessuten modifiserer denne klienten brukerkoder på en slik måte at de viser driftsmoduser for begge IP-protokollene samtidig. Navene selv vet ikke hvordan de skal gjøre dette (ennå), noe som er synd.
Jeg må umiddelbart gjøre en reservasjon: AirDC++ gjør dette alene og for seg selv. I fremtiden vil jeg for enkelhets skyld bruke kombinasjoner som AP eller AA som en indikasjon på aktive eller passive driftsmoduser for henholdsvis IPv4 og IPv6, i stedet for at de vises i den virkelige klientkoden på den virkelige huben. Det er viktig.
I vårt forsøk skal vi bruke FlylinkDC++ som en klient som ikke er kjent med IPv6 i det hele tatt. Det bør også bemerkes at støtte for ham i skrivende stund ble denne artikkelen ikke implementert noe sted.
begynner
Først og fremst skal vi se på åpenbart umulige forbindelser mellom brukere av forskjellige versjoner av IP-protokollen. Skal brukes til testen med ressurs A- og AAAA-poster for domenenavnet som dets adresse.
Vær oppmerksom på at når du (faktisk) prøver å kontakte en bruker med en versjon XNUMX IP-adresse, vises en feilmelding.
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 IPsunknownI menneskelig oversettelse høres det ut som
P4: – Kan jeg klamre meg til deg?
A6: – Hold deg fast!
P4: – Livet er smerte 0_0
En kort ordbok, om nødvendig, .
Og hvis det er omvendt, og forbindelsen starter A4, så vises ingen feil og tilkoblingen henger ganske enkelt.
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Være, ikke synes å være
Det som er viktig er tilkoblingsmodusen som vises på huben.
Klienter uten IPv6-støtte vil måtte se brukere som er koblet gjennom den som tydelig passive, rett og slett fordi huben ikke fylles ut for dem I4 eller I6 felt tilsvarende.
FlylinkDC++ vs. IPv6
I virkeligheten er situasjonen enklere og mer kompleks på samme tid.
AirDC++ vs. IPv6
Enklere fordi IPv6 har forrang over IPv4, og det er forståelig. Det er gjennom den (selv om overstyring er tilgjengelig ved å bruke det tilsvarende alternativet) at forbindelsen til huben vil bli etablert, og den aktive klienten vil tilby den til den passive klienten for tilkobling.
Det er vanskeligere, for hvis det er brukere med IPv6-støtte på huben, men de er strengt koblet via en IPv4-adresse, så...
... så kan du koble til dem (tilfeldig) uten å ha IPv4 i det hele tatt.
Vær oppmerksom på at den eksterne klienten har utpekt seg selv som en eiendel, men behandles som en forpliktelse. Hvorfor?
Kast ham i en sving
La oss nå prøve å koble klienter med forskjellige, men vanlige når det gjelder IPv4, sett med IP-protokollstøtte til hverandre.
Ja, det er synd at passive brukere må røyke på sidelinjen. Men dette kan ikke hjelpes, siden deres synlige IP-adresse ikke er spesielt viktig - det er derfor de er forpliktelser.
Bah! Den aktive klienten sender ?.. Det ville være logisk å forvente en "fast" forbindelse, men nei, det viser seg under forholdene A4.
Hvorfor det? Vi kontakter utvikleren og får svar:
er ikke bra hvis den andre brukeren ikke støtter IPv6
Og du kan ikke krangle! Men dette krever intern logikk, uavhengig av huben (se kode и ). Det er fortsatt umulig å hjelpe passive, fordi
Aktiv modus =
Forsøk på å koble til mellom klienter med vanlige IPv6 IP-støttesett ser slik ut. La meg minne deg på, oppnå PA Jeg lyktes ikke for DC++.
Og igjen en overraskelse. Det viser seg at den passive modusen for IPv6, som DC++ demonstrerer, enten er en bevisst falsk eller en feil.
Hva blir det neste?
For øyeblikket er det nøyaktig to måter å løse alle mulige problemer med å koble brukere i forskjellige moduser og med forskjellige sett med IP-protokollstøtte.
Den første er å dempe IPv6 helt eller omvendt, lage en hub som bare fungerer gjennom den.
Den andre er denne , som akkurat nærmer seg teststadiet.
Vel, hvis du er for lat til å sette opp den aktive modusen for å jobbe i DC, husk:
Den som har, hva skal gis ham, og den som ikke har, selv det han tror han har, skal bli tatt fra ham. OK. 8:18
Kilde: www.habr.com