Назіраць за развіццём файлаабменнай сеткі цікава, але яшчэ цікавей удзельнічаць у ім.
На сённяшні дзень, усталёўваючы і запускаючы сучасны хаб, новаспечаны адміністратар атрымлівае доступ практычна да ўсіх напрацовак і назапашанаму ў гэтай вобласці досведу яго папярэднікаў. Ён мае сістэму, гатовую да пашырэння і кастамізацыі ў тым ліку з дапамогай шматлікіх скрыптоў.
С хабамі інакш. Структура гэтага пратакола мяркуе пашыральнасць. Жадаеш новую фічу? Ну што ж - прапануй, прасоўвай, рэалізуй, укараняй, карыстайся.
Як следства, са скрынкі можна, вядома, атрымаць гатовы хаб, але проста запусціць і забыцца пра яго будзе нядобра. Пашыральнасць у гістарычным кантэксце мяркуе ў тым ліку і наяўнасць рознай колькасці розных функцый кліенцкага і сервернага софту ў залежнасці ад версіі. І тое, што будзе працаваць без праблем у аднаго карыстальніка, можа аказацца несумяшчальным з кліентам іншага, і гэта трэба ўлічваць.
Так здарылася і з IPv6. Дзядок NMDC не ўмее яго ў прынцыпе, а вось ADC сам па сабе да яго готаў. Аднак, не ўсё так проста.
Зусім няшмат тэорыі
"Актыўны" карыстач можа прымаць уваходныя злучэнні. Уласна, выходны ад яго запыт на злучэнне насамрэч з'яўляецца запрашэннем.
"Пасіўны" карыстач у агульным выпадку можа выкарыстоўваць толькі выходныя запыты. Праз хаба ён просіць актыўнага карыстальніка адправіць запрашэнне - і злучэнне атрымліваецца.
І так, гэты механізм не залежыць ад версіі выкарыстоўванага пратаколу IP.
Лебедзь, рак і шчупак
Пагаворым аб кліенцкім софце.
Падтрымка IPv6 у носіць эксперыментальны характар. Асобных налад для яго няма, і тым больш дзіўна для мяне было ўбачыць розныя рэжымы працы для розных версій IP, прычым пасіўны як раз для шостай, але гэта недакладна.
Атрымаць актыўны рэжым пры ручной наладзе не атрымалася нават пры відавочным выкарыстанні ў якасці WAN IP дамена з AAAA-запісам, а вось у аўтаматычным рэжыме з выкарыстаннем UPnP усё зарабіла як павінна.
таксама мае падтрымку IPv6-злучэнняў, і рэалізавана яна зусім асобна ад IPv4. Больш за тое, гэты кліент мадыфікуе тэгі карыстальнікаў такім чынам, каб адлюстроўваць рэжымы працы для абодвух IP пратаколаў адначасова. Самі хабы рабіць гэтага (пакуль) не ўмеюць, а шкада.
Адразу павінен абмовіцца: AirDC++ робіць так адзін і для сябе. У далейшым для зручнасці я буду выкарыстоўваць спалучэнні накшталт AP або AA як указанне на актыўны ці пасіўны рэжымы працы для IPv4 і IPv6 адпаведна, а не іх адлюстраванне ў тэгу рэальнага кліента на рэальным хабе. Гэта важна.
У нашым эксперыменце мы будзем выкарыстоўваць FlylinkDC++ у якасці кліента, зусім не знаёмага з IPv6. Варта таксама адзначыць, што падтрымка для яго на момант напісання артыкула не была рэалізаваная нідзе.
Пачатак
Перш за ўсё мы разгледзім загадзя немагчымыя злучэнні паміж карыстачамі розных версій пратаколу IP. Для цеста будзе выкарыстоўвацца з рэсурснымі A- і AAAA-запісамі для даменнага імя, які выступае ў якасці яго адраса.
Звярніце ўвагу, тут пры (фактычнай) спробе звароту да карыстача з IP-адрасам шостай версіі выводзіцца памылка.
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 IPsunknownУ перакладзе на чалавечую гэта гучыць як
P4: – Можна я да цябе прычаплюся?
A6: Чапляйся!
P4: - Жыццё боль 0_0
Кароткі слоўнічак, калі што, .
А калі наадварот, і злучэнне ініцыюе A4, то памылка не выводзіцца, і злучэнне проста "завісае".
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Быць, а не здавацца
Што важна, дык гэта які адлюстроўваецца на хабе рэжым злучэння.
Кліенты без падтрымкі IPv6 павінны будуць бачыць падлучаных праз яго карыстачоў як адназначна пасіўных проста таму, што для іх хаб не запаўняе I4 або I6 поле адпаведна.
FlylinkDC++ vs. IPv6
На справе ж сітуацыя прасцейшая і складанейшая адначасова.
AirDC++ vs. IPv6
Прасцей, таму што IPv6 мае прыярытэт над IPv4, і гэта зразумела. Менавіта праз яго (хоць з дапамогай адпаведнай опцыі даступна пераазначэнне) будзе ўсталявана злучэнне з хабам, і яго ж актыўны кліент будзе прапаноўваць для злучэння пасіўнаму.
Складаней, таму што калі на хабе прысутнічаюць карыстачы з падтрымкай IPv6, але падлучаныя яны строга праз IPv4-адрас, то…
… то з імі можна злучыцца (наўздагад) наогул не маючы IPv4.
Звярніце ўвагу, выдалены кліент пазначыў сябе як актыву, але апрацоўваецца як пасіў. Чаму?
Туды яго ў арэль
Цяпер паспрабуем злучаць сябар з сябрам кліенты з рознымі, але агульнымі ў частцы IPv4 наборамі падтрымкі пратаколу IP.
Так, шкада, што пасіўным карыстачам даводзіцца паліць у старонцы. Але дапамагчы гэтаму нельга, бо іх бачны IP-адрас не мае асаблівага значэння - на тое яны і пасівы.
Ба! Актыўны кліент адпраўляе ?.. Лагічна было б чакаць «завіслага» злучэння, але не, яно атрымліваецца на ўмовах A4.
Чаму так? Звяртаемся да распрацоўніка і атрымліваем адказ:
isn't good if the other user doesn't support IPv6
І бо не паспрачаешся! Але гэта патрабуе ўжо ўнутранай, незалежнай ад хаба логікі (гл. код и ). Пасіўам жа па-ранейшаму дапамагчы нельга, бо
Active mode =
Спробы ж злучэння паміж кліентамі з агульнымі ў частцы IPv6 наборамі падтрымкі пратаколу IP выглядаюць наступным чынам. Нагадаю, дабіцца PA для DC++ мне не ўдалося.
І зноў сюрпрыз. Атрымліваецца, пасіўны рэжым для IPv6, які дэманструе DC++, ёсць ці наўмысны фэйк, ці баг.
Што далей?
У наш час існуе роўна два спосабу рашэння ўсіх магчымых праблем злучэння карыстачоў у розных рэжымах і з рознымі наборамі падтрымкі пратаколу IP.
Першы - прыглушыць IPv6 зусім ці, наадварот, стварыць хаб для працы толькі праз яго.
Другі - вось гэта , якое толькі-толькі падыходзіць да стадыі тэсціравання.
Ну і, лянуючыся наладжваць актыўны рэжым для працы ў DC, падушыце:
Хто мае, таму дадзена будзе, а хто не мае, у таго адымецца і тое, што ён думае мець. Лк. 8:18
Крыніца: habr.com