Failovahetusvõrgustiku arengut jälgida on huvitav, kuid veelgi huvitavam on selles osaleda.
Tänapäeval, paigaldades ja käivitades kaasaegse habi, saab uus administraator juurdepääsu praktiliselt kõigile eelkäijate kogemustele ja teadmistele selles valdkonnas. Tal on süsteem, mis on valmis laienemiseks ja kohandamiseks, sealhulgas paljude skriptide abil.
A habidega erinevalt. Selle protokolli struktuur eeldab laiendatavust. Kas soovid uut funktsiooni? Noh, siis paku välja, edenda, rakenda, kasuta.
Tulemuseks on see, et "karbist välja" saab loomulikult valmis habi, kuid selle lihtsalt käivitamine ja unustamine ei ole õige. Laiendatavus ajaloos eeldab ka erinevate kliendi- ja serveritarkvara funktsioonide arvu variatsioone sõltuvalt versioonist. Ja see, mis töötab probleemideta ühel kasutajal, võib olla teise kliendi jaoks ühilduvuse probleem ja seda tuleb arvesse võtta.
Nii juhtus ka IPv6-ga. Vanamees NMDC ei oska seda üldse, kuid ADC on iseenesest selle jaoks valmis. Kuid mitte kõik pole nii lihtne.
Natukene teooriat
"Aktiivne" kasutaja võib vastu võtta sissetulevaid ühendusi. Tegelikult on tema poolt algatatud ühenduse taotlus tegelikult kutse.
"Passiivne" kasutaja saab üldiselt kasutada ainult väljuvaid taotlusi. Habi kaudu palub aktiivsel kasutajal saata kutse – ja ühendus luuakse.
Ja jah, see mehhanism ei sõltu kasutatavast IP-protokollist.
Jaged, vähk ja mõõkhani
Räägime klienditarkvarast.
IPv6 tugi on katsetamisetapis. Eraldi seadeid selle jaoks ei ole ja seetõttu oli minu jaoks üllatav näha erinevaid töörežiime erinevate IP-versioonide jaoks, kusjuures passiivne on just kuue jaoks, kuid see ei ole täpne.
Käsitsi seadistamisega aktiivset režiimi saavutada ei õnnestunud isegi siis, kui kasutasin WAN IP-d, millel on AAAA-kirje, kuid automaatse režiimiga UPnP kasutamisega töötas kõik nagu peab.
samuti sisaldab IPv6-ühenduste tuge, ja see on rakendatud täiesti eraldi IPv4-st. Veelgi enam, see klient muudab kasutaja sildid viisil, et kuvada töörežiimid mõlema IP-protokolli jaoks samal ajal. Hubs ise ei oska seda (praegu) teha, kahju.
Tuleb kohe mainida: AirDC++ teeb seda iseendale. Edasi liikudes kasutan mugavuse huvides selliseid variante nagu AP või AA nagu näidatakse aktiivsete või passiivsete töörežiimide jaoks IPv4 ja IPv6 vastavalt, mitte nende kuvamine reaalse kliendi sildil reaalses hubs. See on oluline.
Meie eksperimendis kasutame FlylinkDC++ kliendina, kes ei tunne IPv6-st üldse. Tuleb samuti märkida, et tugi ei olnud kirjutamise ajal kuskil rakendatud.
Algus
Esiteks vaatame väärituks peetud ühendusi erinevate IP-protokolli versioonide vahel. Testiks kasutatakse A- ja AAAA-resursside rekorditega domeeninime jaoks, mis toimib selle aadressina.
Pange tähele, et siin (reaalses) katse tegemisel kasutaja poole pöörduda, kellel on kuuenda versiooni IP-aadress, kuvatakse viga.
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 IPsunknownInimkeelde tõlgituna kõlab see nii
P4: – Kas ma tohin sinuga ühineda?
A6: – Ühine, jah!
P4: – Elu on valu 0_0
Lühike sõnastik, juhul kui see on vajalik, .
Ja kui vastupidi, kui ühenduse initsieerib A4, siis viga ei kuvata ja ühendus lihtsalt "hangub".
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Ole olema, mitte tundma
Oluline on, et hubis kuvatakse ühenduse režiim.
IPv6 tuge mitte toetavad kliendid peavad nägema, et selle kaudu ühendatud kasutajad on üheselt passiivsed, kuna hub ei täida neile vastavalt I4 või I6 välja.
FlylinkDC++ vs. IPv6
Tegelikult on olukord lihtsam ja keerulisem samaaegselt.
AirDC++ vs. IPv6
Lihtsam, kuna IPv6-l on eelis IPv4 ees, ja see on arusaadav. Just selle kaudu (kuigi vastava valiku abil on saadaval ülekirjutamine) luuakse ühendus hubiga ja aktiivne klient pakub passivele ühendamiseks.
Keerulisem, kuna kui hubis on IPv6 tugevaid kasutajaid, kuid nad on ühendatud rangelt IPv4-aadressi kaudu, siis...
… võib neid ühendusele saada (juhuslikult) ilma IPv4-ta.
Pange tähele, et kaugklient on end defineerinud aktiivsena, kuid töödeldakse passiivsena. Miks?
Kas sinna see läheb.
Proovime nüüd ühendada kliente, kellel on erinevad, kuid osaliselt IPv4-protokolli toetused.
Jah, kahju, et passiivsetel kasutajatel tuleb nurka jääda. Kuid neid ei saa aidata, kuna nende nähtav IP-aadress ei tähenda palju – sellised nad ongi passiivsed.
Oi! Aktiivne klient saadab ?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.
Miks nii? Küsime arendajalt ja saame vastuse:
pole hea, kui teine kasutaja ei toeta IPv6.
Ja selle üle ei saa vaielda! Kuid see nõuab juba sisemist, hubist sõltumatut loogikat (vt koodi ja ). Passiivsetele ei saa siiski endiselt abi anda, kuna
Aktiivne režiim =
Katsed ühendada kliente, kellel on osaliselt IPv6-protokolli toetused, näevad välja järgmised. Tuletan meelde, et saavutada PA DC++ jaoks ei saanud ma.
Ja jälle üllatus. Selgub, et passiivne režiim IPv6 jaoks, mida DC++ demonstreerib, on kas tahtlik vale või viga.
Mis edasi?
Praegu on täpselt kaks viisi, kuidas lahendada kõiki võimalikkeühendusprobleeme erinevates režiimides ja erinevate protokolli toetustega.
Esimene on IPv6 täielik tõkestamine või vastupidi, luua hub, mis töötab ainult selle kaudu.
Teine on see , mis on just nüüd testimise faasi lähedal.
Ja kui aktivrežiimi seadistamine DC-sse tundub vaevana, pidage meeles:
Kellel on, sellele antakse, ja kellel ei ole, sealt võetakse ära ka see, mis tal tundub olevat. Lk. 8:18
Allikas: habr.com
