Det är intressant att se utvecklingen av fildelningsnätverket, men det är ännu mer intressant att delta i det.
Idag installerar och lanserar en modern nav, får den nyligen präglade administratören tillgång till nästan all utveckling och erfarenhet som samlats på detta område av sina föregångare. Den har ett system redo för expansion och anpassning, inklusive med hjälp av många skript.
С nav annars. Utformningen av detta protokoll är avsedd att vara utbyggbart. Vill du ha en ny funktion? Tja, erbjuda det, främja det, implementera det, implementera det, använd det.
Som ett resultat kan du naturligtvis få ett färdigt nav ur lådan, men att bara lansera det och glömma det blir inte bra. Utökningsbarhet i ett historiskt sammanhang innebär också närvaron av ett olika antal olika funktioner hos klient- och serverprogramvara, beroende på version. Och det som fungerar utan problem för en användare kan vara inkompatibelt med en annans klient, och detta måste beaktas.
Detta hände med IPv6. Gubben NMDC vet i princip inte hur man gör, men ADC själv är redo för det. Dock inte allt så enkelt.
Bara en liten teori
Den "aktiva" användaren kan acceptera inkommande anslutningar. Egentligen är anslutningsbegäran som kommer från den faktiskt inbjudan.
En "passiv" användare kan i allmänhet bara använda utgående förfrågningar. Genom navet han frågar den aktiva användaren skickar en inbjudan - och anslutningen upprättas.
Och ja, denna mekanism beror inte på vilken version av IP-protokollet som används.
Svan, kräfta och gädda
Låt oss prata om klientprogramvara.
IPv6-stöd är experimentell till sin natur. Det finns inga separata inställningar för det, och det var desto mer överraskande för mig att se olika driftslägen för olika versioner av IP, med passiv bara för den sjätte, men detta är inte korrekt.
Det var inte möjligt att få det aktiva läget under manuell konfiguration även när man explicit använde en IP-domän med en AAAA-post som WAN, men i automatiskt läge med UPnP fungerade allt som förväntat.
har även stöd för IPv6-anslutningar, och det implementeras helt separat från IPv4. Dessutom modifierar denna klient användartaggar på ett sådant sätt att de visar driftlägen för båda IP-protokollen samtidigt. Naven själva vet inte hur man gör detta (ännu), vilket är synd.
Jag måste omedelbart göra en reservation: AirDC++ gör detta ensam och för sig själv. I framtiden kommer jag för bekvämlighets skull att använda kombinationer som AP eller AA som en indikation på aktiva eller passiva driftlägen för IPv4 respektive IPv6, snarare än att de visas i den verkliga klienttaggen på den verkliga hubben. Det är viktigt.
I vårt experiment kommer vi att använda FlylinkDC++ som en klient som inte alls är bekant med IPv6. Det bör också noteras att stöd för honom vid tidpunkten för skrivandet var denna artikel inte implementerad någonstans.
börjar
Först och främst kommer vi att titta på uppenbart omöjliga kopplingar mellan användare av olika versioner av IP-protokollet. Kommer att användas för testet med resurs A- och AAAA-poster för domännamnet som dess adress.
Observera att när du (faktiskt) försöker kontakta en användare med en version XNUMX IP-adress visas ett felmeddelande.
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 mänsklig översättning låter det som
P4: – Kan jag hålla fast vid dig?
A6: – Håll dig fast!
P4: – Livet är smärta 0_0
En kort ordbok, om det behövs, .
Och om det är tvärtom och anslutningen initieras A4, då visas inget fel och anslutningen hänger sig helt enkelt.
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Var, verkar inte vara
Det viktiga är anslutningsläget som visas på hubben.
Klienter utan IPv6-stöd måste se användare som är anslutna via det som tydligt passiva, helt enkelt för att navet inte fylls för dem I4 eller I6 fältet i enlighet med detta.
FlylinkDC++ vs. IPv6
I verkligheten är situationen enklare och mer komplex på samma gång.
AirDC++ vs. IPv6
Enklare eftersom IPv6 har företräde framför IPv4, och det är förståeligt. Det är genom den (även om överstyrning är tillgänglig med motsvarande alternativ) som anslutningen till hubben kommer att upprättas, och den aktiva klienten kommer att erbjuda den till den passiva klienten för anslutning.
Det är svårare, för om det finns användare med IPv6-stöd på hubben, men de är strikt anslutna via en IPv4-adress, då...
... då kan du ansluta till dem (slumpmässigt) utan att ha IPv4 alls.
Observera att fjärrklienten har utsett sig själv som en tillgång, men behandlas som en skuld. Varför?
Kasta honom i en gunga
Låt oss nu försöka ansluta klienter med olika, men vanliga när det gäller IPv4, uppsättningar av IP-protokollstöd till varandra.
Ja, det är synd att passiva användare måste röka vid sidan av. Men detta kan inte hjälpas, eftersom deras synliga IP-adress inte är särskilt viktig - det är därför de är skulder.
Bah! Den aktiva klienten skickar ?.. Det vore logiskt att förvänta sig en "fast" anslutning, men nej, det visar sig under omständigheterna A4.
Varför är det så? Vi kontaktar utvecklaren och får svaret:
är inte bra om den andra användaren inte stöder IPv6
Och du kan inte argumentera! Men detta kräver intern logik, oberoende av navet (se kod и ). Det är fortfarande omöjligt att hjälpa passiva, eftersom
Aktivt läge =
Försök att ansluta mellan klienter med vanliga IPv6 IP-stöduppsättningar ser ut så här. Låt mig påminna dig, uppnå PA Jag lyckades inte för DC++.
Och återigen en överraskning. Det visar sig att det passiva läget för IPv6, som DC++ demonstrerar, antingen är en avsiktlig fejk eller en bugg.
Vad händer nu?
För närvarande finns det exakt två sätt att lösa alla möjliga problem med att ansluta användare i olika lägen och med olika uppsättningar av IP-protokollstöd.
Den första är att stänga av IPv6 helt och hållet eller, omvänt, skapa en hubb som bara fungerar genom den.
Den andra är denna , som just närmar sig teststadiet.
Tja, om du är för lat för att ställa in det aktiva läget för att arbeta i DC, kom ihåg:
Den som har, vad kommer att ges till honom, och den som inte har, även vad han tror att han har kommer att tas ifrån honom. OK. 8:18
Källa: will.com