On mielenkiintoista seurata tiedostonjakoverkon kehitystä, mutta vielä mielenkiintoisempaa on osallistua siihen.
Tänään asennetaan ja lanseerataan moderni hubissa, äskettäin lyöty ylläpitäjä saa pääsyn lähes kaikkiin edeltäjiensä tällä alalla kertyneeseen kehitykseen ja kokemukseen. Siinä on järjestelmä, joka on valmis laajennettavaksi ja mukautettaviksi, myös lukuisten komentosarjojen avulla.
С keskittimet muuten. Tämän protokollan suunnittelun on tarkoitus olla laajennettavissa. Haluatko uuden ominaisuuden? No, tarjoa, mainosta, toteuta, toteuta, käytä.
Tämän seurauksena voit tietysti saada valmiin keskittimen laatikosta, mutta pelkkä sen käynnistäminen ja sen unohtaminen ei ole hyvä. Laajennettavuus historiallisessa kontekstissa tarkoittaa myös sitä, että asiakas- ja palvelinohjelmistossa on erilainen määrä erilaisia toimintoja versiosta riippuen. Ja mikä toimii ilman ongelmia yhdelle käyttäjälle, voi olla yhteensopimaton toisen asiakkaan kanssa, ja tämä on otettava huomioon.
Tämä tapahtui IPv6:n kanssa. Vanhus NMDC ei periaatteessa osaa tehdä sitä, mutta ADC itse on siihen valmis. Kaikki eivät kuitenkaan ole niin yksinkertaisia.
Pientä teoriaa vain
"Aktiivinen" käyttäjä voi hyväksyä saapuvat yhteydet. Itse asiassa siitä tuleva yhteyspyyntö on itse asiassa kutsu.
"Passiivinen" käyttäjä voi yleensä käyttää vain lähteviä pyyntöjä. Keskittimen kautta hän pyynnöt aktiivinen käyttäjä lähettää kutsun - ja yhteys muodostetaan.
Ja kyllä, tämä mekanismi ei riipu käytetyn IP-protokollan versiosta.
Joutsen, syöpä ja hauki
Puhutaanpa asiakasohjelmistosta.
IPv6 tuki on luonteeltaan kokeellinen. Sille ei ole erillisiä asetuksia, ja sitäkin ihmeellisempää oli nähdä eri toimintatilat eri IP-versioille, passiivinen vain kuudennessa, mutta tämä ei ole tarkkaa.
Manuaalisen konfiguroinnin aikana ei ollut mahdollista saada aktiivista tilaa edes käytettäessä WAN-verkkona AAAA-tietueella varustettua IP-aluetta, mutta automaattisessa tilassa UPnP:tä käyttäen kaikki toimi odotetusti.
on myös tuki IPv6-yhteyksille, ja se on toteutettu täysin erillään IPv4:stä. Lisäksi tämä asiakas muokkaa käyttäjätunnisteita siten, että se näyttää molempien IP-protokollien toimintatilat samanaikaisesti. Keskittimet itse eivät osaa tehdä tätä (vielä), mikä on sääli.
Minun on tehtävä heti varaus: AirDC++ tekee tämän yksin ja itselleen. Tulevaisuudessa käytän mukavuuden vuoksi yhdistelmiä, kuten AP tai AA osoituksena IPv4:n ja IPv6:n aktiivisista tai passiivisista toimintatiloista sen sijaan, että ne näyttäisivät todellisessa asiakastunnisteessa todellisessa keskittimessä. On tärkeää.
Kokeilussamme käytämme FlylinkDC++ asiakkaana, joka ei ole ollenkaan perehtynyt IPv6:een. On myös huomattava, että tuki hänelle tätä artikkelia kirjoittamishetkellä ei toteutettu missään.
alku
Ensinnäkin tarkastelemme ilmeisen mahdottomia yhteyksiä IP-protokollan eri versioiden käyttäjien välillä. Käytetään testissä resurssin A- ja AAAA-tietueet verkkotunnukselle, jotka toimivat sen osoitteena.
Huomaa, että kun yrität (itse asiassa) ottaa yhteyttä käyttäjään, jolla on version XNUMX IP-osoite, näyttöön tulee virheilmoitus.
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 IPsunknownIhmisen käännöksessä se kuulostaa
P4: – Voinko tarttua sinuun?
A6: – Pidä kiinni!
P4: – Elämä on kipua 0_0
Tarvittaessa lyhyt sanakirja .
Ja jos asia on päinvastoin, ja yhteys alkaa A4, virhettä ei näytetä ja yhteys yksinkertaisesti katkeaa.
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Ole, ei näytä olevan
Tärkeää on keskittimessä näkyvä yhteystila.
Asiakkaiden, joilla ei ole IPv6-tukea, on nähtävä sen kautta yhdistetyt käyttäjät selvästi passiivisina, yksinkertaisesti koska keskitin ei täytä niitä I4 tai I6 kenttään vastaavasti.
FlylinkDC++ vs. IPv6
Todellisuudessa tilanne on yhtä aikaa yksinkertaisempi ja monimutkaisempi.
AirDC++ vs. IPv6
Helpompaa, koska IPv6 on etusijalla IPv4:ään nähden, ja se on ymmärrettävää. Sen kautta (vaikka ohitus on käytettävissä vastaavalla vaihtoehdolla) muodostetaan yhteys keskittimeen, ja aktiivinen asiakas tarjoaa sen passiiviselle asiakkaalle yhteyttä varten.
Se on vaikeampaa, koska jos keskittimessä on käyttäjiä, joilla on IPv6-tuki, mutta he ovat yhteydessä tiukasti IPv4-osoitteen kautta, niin...
... sitten voit muodostaa yhteyden niihin (satunnaisesti) ilman IPv4:ää.
Huomaa, että etäasiakas on määrittänyt itsensä omaisuuseräksi, mutta sitä käsitellään velana. Miksi?
Heitä hänet keinuun
Yritetään nyt yhdistää asiakkaita, joilla on erilaisia, mutta IPv4:n kannalta yleisiä IP-protokollatukijoukkoja.
Kyllä, on sääli, että passiiviset käyttäjät joutuvat tupakoimaan sivussa. Mutta tätä ei voi auttaa, koska heidän näkyvä IP-osoite ei ole erityisen tärkeä - siksi he ovat velkoja.
Bah! Aktiivinen asiakas lähettää ?.. Olisi loogista odottaa "jumiutunutta" yhteyttä, mutta ei, se selviää olosuhteissa A4.
Miksi niin? Otamme yhteyttä kehittäjään ja saamme vastauksen:
ei ole hyvä, jos toinen käyttäjä ei tue IPv6:ta
Ja et voi väitellä! Mutta tämä vaatii sisäistä logiikkaa, joka on riippumaton keskittimestä (katso koodi и ). On edelleen mahdotonta auttaa passiivisia, koska
Aktiivinen tila =
Yritykset muodostaa yhteys asiakkaiden välillä yleisillä IPv6-IP-tukijoukoilla näyttävät tältä. Sallikaa minun muistuttaa, saavuttaa PA En onnistunut DC++:ssa.
Ja taas yllätys. Osoittautuu, että IPv6:n passiivinen tila, jonka DC++ osoittaa, on joko tahallinen väärennös tai virhe.
Mitä seuraavaksi?
Tällä hetkellä on olemassa täsmälleen kaksi tapaa ratkaista kaikki mahdolliset ongelmat käyttäjien yhdistämisessä eri tiloissa ja erilaisilla IP-protokollatuilla.
Ensimmäinen on mykistää IPv6 kokonaan tai päinvastoin luoda keskitin, joka toimii vain sen läpi.
Toinen on tämä , joka on juuri lähestymässä testausvaihetta.
No, jos olet liian laiska määrittämään aktiivisen tilan DC-työskentelyä varten, muista:
Jolla on, sille annetaan, ja jolla ei ole, siltä otetaan pois sekin, mitä hän luulee omistavansa. OK. 8:18
Lähde: will.com