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