Интересно е да наблюдаваме развитието на мрежата за споделяне на файлове, но още по-интересно е да участваме в нея.
Днес, инсталиране и стартиране на модерен център, новосъздаденият администратор получава достъп до почти всички разработки и опит, натрупан в тази област от неговите предшественици. Има система, готова за разширяване и персонализиране, включително с помощта на множество скриптове.
С хъбове иначе. Дизайнът на този протокол е предназначен да бъде разширяем. Искате ли нова функция? Е, предлагайте го, популяризирайте го, внедрявайте го, прилагайте го, използвайте го.
В резултат на това можете, разбира се, да получите готов хъб от кутията, но просто да го стартирате и да забравите за него няма да е добре. Разширяемостта в исторически контекст също предполага наличието на различен брой различни функции на клиентския и сървърния софтуер, в зависимост от версията. И това, което ще работи без проблеми за един потребител, може да е несъвместимо с клиента на друг и това трябва да се вземе предвид.
Това се случи с IPv6. Старецът NMDC не знае как да го направи по принцип, но самият ADC е готов за това. Въпреки това, не всичко е толкова просто.
Само малко теория
„Активният“ потребител може да приема входящи връзки. Всъщност искането за връзка, идващо от него, всъщност е покана.
"Пасивният" потребител обикновено може да използва само изходящи заявки. Чрез хъба той пита активният потребител изпраща покана - и връзката е установена.
И да, този механизъм не зависи от версията на използвания IP протокол.
Лебед, рак и щука
Нека поговорим за клиентския софтуер.
Поддръжка на IPv6 има експериментален характер. Няма отделни настройки за него и за мен беше още по-изненадващо да видя различни режими на работа за различните версии на IP, с пасив само за шестата, но това не е точно.
Не беше възможно да се получи активен режим по време на ръчна конфигурация, дори когато изрично се използва IP домейн с AAAA запис като WAN, но в автоматичен режим с използване на 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++ срещу. IPv6
В действителност ситуацията е по-проста и по-сложна едновременно.
AirDC++ срещу. IPv6
По-лесно, защото IPv6 има предимство пред IPv4 и това е разбираемо. Именно чрез него (въпреки че е налице предефиниране с помощта на съответната опция) ще се установи връзка с хъба, а активният му клиент ще предложи да се свърже с пасивния.
По-трудно е, защото ако в хъба има потребители с поддръжка на IPv6, но те са свързани стриктно чрез IPv4 адрес, тогава ...
... тогава можете да се свържете с тях (произволно), без изобщо да имате IPv4.
Моля, имайте предвид, че отдалеченият клиент се е определил като актив, но се третира като пасив. Защо?
Хвърлете го в люлка
Сега нека се опитаме да свържем клиенти с различни, но общи по отношение на IPv4 набори от поддръжка на IP протокол един към друг.
Да, жалко е, че пасивните потребители трябва да пушат отстрани. Но това не може да се помогне, тъй като техният видим IP адрес не е особено важен - затова те са пасиви.
Бах! Активният клиент изпраща ?.. Би било логично да очакваме „заседнала“ връзка, но не, оказва се при условията A4.
Защо така? Свързваме се с разработчика и получаваме отговора:
не е добре, ако другият потребител не поддържа IPv6
И не можете да спорите! Но това изисква вътрешна логика, независима от хъба (вижте кода и ). Все още е невъзможно да се помогне на пасивите, т.к
Активен режим =
Опитите за свързване между клиенти с общи набори за поддръжка на IPv6 IP изглеждат така. Нека ви напомня, постигнете PA За DC++ не успях.
И пак изненада. Оказва се, че пасивният режим за IPv6, който DC++ демонстрира, е или умишлен фалшификат, или бъг.
Каква е следващата?
В момента има точно два начина за решаване на всички възможни проблеми при свързване на потребители в различни режими и с различни набори поддръжка на IP протокол.
Първият е напълно да заглушите IPv6 или, обратно, да създадете хъб, който да работи само през него.
Второто е това , който тъкмо наближава етапа на тестване.
Е, ако сте твърде мързеливи, за да настроите активния режим за работа в DC, запомнете:
Който има, каквото ще му се даде, а който няма, ще му се отнеме и това, което мисли, че има. ДОБРЕ. 8:18
Източник: www.habr.com