Наблюдать за развитием файлообменной сети интересно, но ещё интереснее участвовать в нём.
На сегодняшний день, устанавливая и запуская современный хаб, новоиспечённый администратор получает доступ практически ко всем наработкам и накопленному в этой области опыту его предшественников. Он имеет систему, готовую к расширению и кастомизации в том числе с помощью многочисленных скриптов.
С хабами иначе. Структура этого протокола предполагает расширяемость. Хочешь новую фичу? Ну что ж – предлагай, продвигай, реализуй, внедряй, пользуйся.
Как следствие, «из коробки» можно, конечно, получить готовый хаб, но просто запустить и забыть о нём будет нехорошо. Расширяемость в историческом контексте предполагает в том числе и наличие разного количества разных функций клиентского и серверного софта в зависимости от версии. И то, что будет работать без проблем у одного пользователя, может оказаться несовместимым с клиентом другого, и это нужно учитывать.
Так случилось и с 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