Failo vahetusvõrgu arengut jälgida on huvitav, kuid veelgi huvitavam on selles osaleda.
Tänapäeval, paigaldades ja käivitades kaasaegse hubb'i, uustulnuk administraator omandab ligipääsu praktiliselt kõigile eelkäijate teadmistele ja kogemustele antud valdkonnas. Tal on süsteem, mis on valmis laienemiseks ja kohandamiseks, sealhulgas paljude skriptide abil.
C hubid on erinevad. Selle protokolli struktuur eeldab laiendatavust. Tahad uut funktsiooni? Noh, siis paku, edenda, implementeeri, kasuta.
Seetõttu on võimalus „karbist välja” saada küll valmis hub, kuid selle lihtsalt käivitamine ja unustamine ei ole õige. Laiendatavus ajaloolises kontekstis tähendab sealhulgas ka erinevate versioonide sõltuvalt erinevatest funktsioonidest kliendi- ja serveri tarkvarades. Ja see, mis töötab probleemideta ühel kasutajal, võib osutuda teiste kliendi jaoks ühilduvaks ja seda tuleb arvestada.
Nii on juhtunud ka IPv6-ga. Vanameister NMDC ei oska seda põhimõtteliselt, kuid ADC on ise selleks valmis. Siiski, asi ei ole nii lihtne.
Natuke teooriat
„Aktiivne“ kasutaja saab vastu võtta sisse tulevaid ühendusi. Tõepoolest, temalt pärinev ühenduse taotlus on tegelikult kutse.
„Passiivne“ kasutaja võib üldjuhul kasutada ainult väljaminevaid taotlusi. Habi kaudu saab ta küsimiseks aktiivselt kasutajalt kutse saata – ja ühendus luuakse.
Ja jah, see mehhanism ei sõltu kasutatavast IP-protokolli versioonist.
Saarmas, vähk ja haug
Räägime klienditarkvarast.
IPv6 toe on eksperimentaalsel tasandil. Spetseifilisi seadeid selle jaoks ei ole, ja seetõttu oli mul üllatus näha erinevaid töörežiime erinevate IP-versioonide jaoks, kusjuures passiivne režiim on just kuues, kuid see ei ole täpne.
Käsitsi seadistuse korral ei saanud aktiivset režiimi saavutada, isegi kui WAN IP-ks kasutati AAAA-kirjega domeeni, kuid automaatse režiimi kasutamisega UPnP kaudu töötas kõik nagu peab.
samuti toetab IPv6-ühendusi, ning see on rakendatud täiesti eraldi IPv4-st. Veelgi enam, see klient muudab kasutaja silte selliselt, et kuvada tegevusrežiime mõlema IP protokolli jaoks samaaegselt. Hubsid ei oska seda (hetkel) teha, mis on kahju.
Pean kohe mainima: AirDC++ teeb seda nii enda jaoks. Edaspidi kasutan mugavuse huvides kombinatsioone nagu AP või AA aktiivsete või passiivsete režiimide näitamiseks IPv4 ja IPv6 jaoks vastavalt, mitte nende kuvamiseks reaalses kliendis reaalses hubis. See on oluline.
Meie katses kasutame FlylinkDC++ kui klienti, mis ei tunne üldse IPv6. Tuleb märkida, et tugi ei olnud kirjutamise hetkel kusagil realiseeritud.
Algus
Esmalt vaatame läbi teadlikult võimatuid ühendusi erinevate IP protokolli versioonide kasutajate vahel. Katseks kasutatakse ressursside A- ja AAAA-kannete jaoks domeeninimi, mis toimib selle aadressina.
Pane tähele, et kui püüate tegelikult ühendust kasutajaga, kellel on IPv6-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 nagu
P4: – Kas ma võin sinuga liituda?
A6: – Liitu!
P4: – Elu on valu 0_0
Lühike sõnastik, kui on vaja, .
Aga kui vastupidine, et ühendus initsieerib A4, siis viga ei kuvata ja ühendus lihtsalt 'hangub'.
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Olla, mitte näida
Oluline on, et hubis kuvatakse ühenduse režiim.
IPv6 toetust mitte omavad kliendid näevad ühendatud kasutajaid sel viisil kui ühemõtteliselt passiivseid, sest hub ei täida nende jaoks I4 või I6 veel vastavat väljad.
FlylinkDC++ vs. IPv6
Tegelikult on olukord lihtsam ja samas keerulisem.
AirDC++ vs. IPv6
Lihtsam, sest IPv6-l on eelis IPv4 üle ja see on arusaadav. Just selle kaudu (kuigi vastava valiku abil on võimalik ülekirjutamine) luuakse ühendus hubiga ja aktiivne klient pakub passiivsele ühendamiseks.
Raskem, kuna kui hubis on ühed IPv6 toega kasutajad, aga nad on ühendatud ainult IPv4 aadressi kaudu, siis...
... on nendega võimalik ühendust saada (mõtteliselt) üldse ilma IPv4-ta.
Pange tähele, et kaugklient on ennast määratlenud kui aktiivset, kuid töödeldakse passiivsena. Miks?
Sinna see läheb
Nüüd proovime omavahel ühendada kliente, kellel on erinevad, kuid IPv4 osas ühised IP protokolli toega komplektid.
Jah, kahju, et passiivsetel kasutajatel tuleb kõrvale jääda. Aga sellele ei saa midagi ette võtta, kuna nende nähtav IP-aadress pole eriti oluline – need ongi passiivsed.
Aha! Aktiivne klient saadab ?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.
Miks nii? Küsime arendajalt ja saame vastuse:
ei ole hea, kui teine kasutaja ei toeta IPv6
Ja sellele ei saa vastu vaielda! Kuid see vajab juba sisemist, hubist sõltumatut loogikat (vt kood ja ). Passiivsetele ei saa endiselt abi pakkuda, sest
Aktiivne režiim =
Katsed ühendada kliente, kellel on IPv6 osas ühised IP protokolli toega komplektid, näevad välja järgmised. Meenutan, et saavutada PA DC++ jaoks ei õnnestunud mul.
Ja jälle üllatus. Tundub, et IPv6 passiivne režiim, nagu DC++ demonstreerib, on kas tahtlik valeinfo või viga.
Mis edasi?
Praegu on olemas täpselt kaks viisi, kuidas lahendada kõiki võimalikke probleeme kasutajate ühendamisel erinevates režiimides ja erinevate IP-protokolli toe komplektidega.
Esimene - lülitada IPv6 täielikult välja või, vastupidi, luua hub, mis töötab ainult selle kaudu.
Teine - see, , mis on just nüüd testimise faasi jõudnud.
Ja kui te just ei viitsi aktiivseid seadeid DC käitamiseks seadistama, pidage meeles:
Kellel on, sellele antakse; kellel aga ei ole, sellelt võetakse ära ka see, mis tal arvata on. Lk. 8:18
Allikas: habr.com
