Протокол IPv6 в протоколе NMDC, Спецификация и тестирование IPv6 в NMDC

Да, как бы неочень получается, продолжим ту тему здесь? Т.к. та тема не в том разделе и я предлагаю серьезно обсужадть не только спецификацию, но и тестировать..?
Моё предложение не слать 2 команды, т.к. хабы и так генерят много трафика, а хорошенько подумать и использовать сложившуюся ситуацию себе наруку. Потому как расплата за ошибки, допущенные сейчас, в будущем может быть очень большая.
Т.к. только хаб знает какие к нему присоединены клиенты, я предлагаю все команды, в которых передается ipv6 адрес, дублировать (так сказать, раз уж так получилось, подкорректируем протокол).
В общем здесь я опишу как я вижу решение проблемы, а дальше жду ваших комментариев.

Цель:

1. Поддержка в протоколе NMDC IPv4 и IPv6 адресов одновременно.
2. Уменьшение трафика за счет правильной структуры новых команд, передачи адресов и портов отдельно и один раз, уменьшения длины ключей команд.
3. Упрощение обработки, за счет правильной структуры новых команд.
4. Требование минимального вмешательства в NMDC. Заменяются только те команды, без модификации которых не возможно функционирование ipv6. Остальные команды не затрагиваются.
5. Сохраняются разделитель NMDC: команд "|". Блоков "$".

Основные положения:

1. Расширение разработано в первую очередь для того, чтобы использовать сложившуюся ситуацию себе на руку и не только внедрить IPv6 в NMDC, но и уменьшить проблемы трафика и сложности обработки стандартных команд NMDC. Поэтому были разработаны новые команды, гораздо короче и проще старых.
2. Для новых клиентов старые команды заменяются на новые:
   $UserIP -> $UIP (передает ip адреса и порты всех пользователей всем пользователям)
   $RevConnectToMe -> $RCM. вообще если в $UIP отсылаются адреса и порты всех пользователей всем пользователям - активы и пассивы могут устанавливать соединения с активами сразу напрямую, и $RCM можно не использовать. Но если администратор не передает tcp порты в команде $UIP, т.е. хочет управлять пользователями и одним разрешать качать, другим запрещать, то используется эта команда. Например в ADC её оставили, решили что администратор хаба должен решать кому можно качать. Но если её убрать - то при установлении соединения клиент не информирует хаб и тем самым нагрузка на хаб снижается.
   $ConnectToMe -> $CTM (актив паросит пассива присоединиться к нему, т.е. инициализировать соединение)
   $Search -> $SCH.
3. Поддержка данного расширения протокола NMDC отпределяется по GIFTEXT в команде Suports.
4. В случае присоединения клиента с поддержкой данного расширения к хабу без поддержки данного расширения, клиент работает с ним старыми командами, без использования IPv6.
5. В случае присоединения к хабу с поддержкой данного расширения, новые клиенты отправляют на хаб сразу две команды - старого и нового типа. Старые клиенты - только старого соответственно.
6. Хаб принимает команды старого и нового типа и рассылает команды старого типа клиентам без поддержки GIFTEXT, и новые клиентам с поддержкой GIFTEXT.
7. В командах старого типа используется только IPv4. Таким образом старые клиенты не почуствуют какие либо неудобства.
8. Для избежания доса, хаб перед отправкой (или при получении) заменяет в $UIP UDP порт неподтвержденного IP адреса на символ нижний прочерк: "_". Таким образом клиенты знают какой ip является подтвержденным и обязаны слать ответ только на него. (Есть еще вариант, для подтверждения второго IP адреса, с установкой по второму IP отдельного соединения с хабом. Вроде как этот вариант уже реализовали в птохе.)
9. TCP порты обоих IP адресов передаются без изменения, таким образом клиенты сами могут выбирать протокол IPv4 или IPv6, по которому они будут организовывать файлообмен.(Т.е. ограничивается протоколом ipv6/ipv4 только поиск, скачивание - нет. И то если второй ip адрес не подтверждается установкой второго соединения с хабом)

$RevConnectToMe - команда, которую пассивный пользователь отправляет чтобы попросить другого пользователя попросить его инициировать с ним соединение, заменяются одной $RCM. Не используется клиентами на хабах, где администратор пропускает TCP порты в команде UIP. и (описние $RevConnectToMe)
Обычная:
nmdc expansion by gif-t:

Уточнения:

1. Как видете, команда предельно проста и коротка.
2. СПОРНО Команды $RCM и $RevConnectToMe отправляются клиентом хабу вместе. Далее хаб сам выбирает каким клиентам какую рассылать. Модифицировать команду на стороне хаба не нужно. В плане трафика - это входящий для хаба трафик, который не представляет проблем. Или можно передавать только новую, а старую хаб будет генерировать сам...
3. IP адреса передаются хабом при присоединении пользователя командой $UIP. Клиент сам решает по какому протоколу устаналвиать соединение. Или перебирает сначала ipv4, потом ipv6.
4. Пометка - надо обязательно учесть недавние дополнения.

$ConnectToMe - команда, которую активный пользователь отправляет чтобы попросить другого пользователя инициировать с ним соединение, заменяются одной $CTM (описние $ConnectToMe)
Обычная:
nmdc expansion by gif-t:

Уточнения:

1. Как видете, команда предельно проста и коротка. Гораздо короче $ConnectToMe.
2. СПОРНО Команды $CTM и $ConnectToMe отправляются клиентом хабу вместе. Далее хаб сам выбирает каким клиентам какую рассылать. Модифицировать команду на стороне хаба не нужно. В плане трафика - это входящий для хаба трафик, который не представляет проблем.
3. IP адреса передаются хабом при присоединении пользователя командой $UIP. Клиент сам решает по какому протоколу устаналвиать соединение. Или перебирает сначала ipv4, потом ipv6.
4. В $CTM клиент заполняет только те порты, ip адреса соответствующие которым у него есть.
5. Пометка - надо обязательно учесть недавние дополнения.

Активный клиент (способный принимать входящие соединения) посылает данную команду на хаб для того, чтобы попросить пользователя [Ник_получателя] инициализировать соединение с ним (IP адрес и иногда порт тому клиенту уже извествен благодаря $UIP).

$Search и $MultiSearch (описние $Search) (описние $MultiSearch)

Обычная:
Нет деления структуры на активный и пассивный поиски
nmdc expansion by gif-t:
Уточнения:

1. Если строка поиска - текстовый, а не TTH запрос, и содержет несколько слов, разделенных пробелами, на месте пробела ставится знак пробела, а не "$", как это было непонятно зачем сделано в старой команде $Search.
2. IP адреса и UDP порты передаются хабом при присоединении пользователя командой $UIP, описанной ниже.
3. На линкованых хабах команда работает как $MultiSearch???
4. СПОРНО Команды $SCH и $Search отправляются клиентом хабу вместе. Далее хаб сам выбиарет каким клиентам какую рассылать. Модифицировать команду на стороне хаба не нужно. В плане трафика - это входящий для хаба трафик, который не представляет проблем.

$SR - ответ на поисковый запрос (описние $SR)
Нужно проверить, но я думаю эта фукция будет работать с ipv6 без модификации.

$MultiSearch (описние $MultiSearch)
Не знаю, она в ходу? Я просто не вижу в ней смысла. Хаб должен сам решать как и куда он пересылает поисковые запросы. Моё мнение - модификация команды не нужна. Сразу объявим $SCH как $MultiSearch на линкованых хабах.

$UserIP (описние $UserIP)
Обычная:
nmdc expansion by gif-t:

Уточнения:

1. Список $UIP всех пользователей отправляется хабом пользователю сразу после его присоединения и отправки ему списка $MyINFO.
2. $UIP отправляется обязательно после $MyINFO.
3. Администратор хаба сам решает, будут ли в данной команде передаваться TCP порты. Если будут - то команда $RCM не должна использоваться клиентами. Они должны сразу устанавливать соединение с нужными им пользователями. В случае если TCP порты в $UIP администратор не передает, клиенты должны использовать команду $RCM для получения TCP портов.
4. Команда отправляется один раз при входе и каждый раз при изменении портов пользователя. Таким образом обеспечивается экономия трафика. В таких командах как $SCH и $CTM ip адрес не передается. В $Search, к примеру, ip адрес передается при каждом поисковом запросе. Команда $Search на большинстве хабов является основным источником трафика.
5. Отсутствующий порт/адрес заполняется символом прочерк "-", чтобы не повторялся разделитель "$$", разделяющий блоки ников.
6. Т.к. передается два IP адреса, а проверяется только один - возможна организация UDP доса любого IP адреса ответами на поисковый запрос (соответственно только при поиске). Для избежания этого, ответы отсылаются клиентами только на IPv4 или IPv6 по которому клиент присоединен к хабу. После получения от клиенты данной команды, хаб у непроверенного ip адреса (противоположного относительно того, по которому он присоединен к хабу) UDP порт заменяет на знак "_" нижний прочерк и отсылает её всем пользователям. Таким образом хабу не нужно беспокоиться о проблеме доса, клиенты, отвечающие на поисковый запрос, знают какой IP адрес подвержден и будут слать ответ только на него.
   
   Также есть второй вариант - http://mydc.ru/topic5172.html?view=findpost&p=42452 - клиент должен устанавливать второе соединение с хабом и подтверждать второй ip адрес. Тогда в $UIP можно передавать оба UDP порта, поиск будет абсолютно полным и пользователи сразу с двумя ip адресами (ipv4 и ipv6) будут получать ответы на поисковый запрос по обоим (соответственно с ipv4 и ipv6 пользователей), т.е. от абсолютно всех пользователей хаба. Недостаток - это значительно усложняет алгоритм.
   
   В случае скачивания клиентам известны оба ip адреса и они могут организовать прямой файлообмен по IPv6 или IPv4 как им угодно.
7. IPv6 адрес без квадратных скобок спереди и сзади!
8. Если какого-то IP адреса нет, вместо него передается символ прочерк "-" для безопасности, чтобы не повторялся разделитель $$
9. Если передается TCP порты пользователя, клиент при необходимости может сразу связываться с ним напрямую, не беспокоя хаб командой $RCM (экономия трафика).
10. Два символа $$ - открывающий разделитель для нового блока. Т.е. после блока он не ставится. Это значит что команда не может закончиться на "$$|"

$ForceMove (описние $ForceMove)
Эту команду тоже стоит модифицировать, чтобы клиенту передавалось сразу два IP адреса, IPv6 и IPv4. Далее он сможет выбрать по какому он может устанавливать соединение.

Обычная:
nmdc expansion by gif-t:
Уточнения:

1. Хаб сам выбирает кому отправлять $FOM, а кому $ForceMove. Клиенты без поддержки $FOM, а значит и возможно IPv6, или без IPv6 адреса, в случае если хаб перенаправляет только на IPv6, будут потеряны, т.к. они не смогут установить соединение. Поэтому в $ForceMove рекомендуется передавать только ipv4 адрес.

$BotINFO / $HubINFO (описние $BotINFO и $HubINFO)
Тут впринципе модификация не требуется, т.к. адрес заполняется вручную администраторорм хаба/ администратором бота.
Пуска IPv6 адрес пишется в квадратных скобках. Это конечно усложняет функцию обработки... но несильно, сейчас сам набросал её (вышло +14 строк)
Если IPv6 адрес идет после всех других адресов, то сохраняется совместимость со старыми клиентами хаблистами (но теряется порт). Но лучше вместо ip адреса использовать IPv6 dns. В общем хаблисты разберутся - эти команды только для них, не для клиентов или хабов.

$Supports
Добавляем в команду GIFTEXT для идентификации хабов и клиентов, поддерживающих expansion by gif-t

--------------------------------------------------------------------------------------------------------------------------------------------
Как видите,
1) Длина команд сильно укоротилась за счет использования трехбайтовых ключей и за счет вынос адресов в команду $UIP
2) Команды очень легко разобрать, т.к. разделитель элементов всегда один - знак $ (в старых командах разделителей много - пробел, двоеточие, знак "$", знак "?").
В адресе IPv6 используется двоеточие для разделения блоков и скобки для отделения порта, т.к. он отделяется тоже двоеточием, - в моём предложении вообще не надо использовать квадратные скобки для разделения ipv6 адреса от порта! В обшем для обработки таких команд выйдет функция минимального размера, максимальной простоты и быстродействия.
3) Предложенная схема абсолютно совместима со старыми (текущими) клиентами. Т.к. старым клиентам отсылаются команды старого типа. В схеме, предложенной Setuper'ом, данные впихиваются в структуру старых команд. Таким образом получаем в его схеме

• Старые клиенты пытаются обработать такие команды и у них ничего не выходит или выходит непонятно что (вот будет круто если некоторые будут падать от этого )) )
• Новые клиенты обрабатывают их сложными функциями, с большей нагрузкой, но корректно
• Старые длинные команды отправляются дважды, сначала с ipv4, потом с ipv6. Это увеличивает трафик почти в 2 раза...
• Т.к. они отсылаются подряд, сначала с ipv4, потом с ipv6, новому клиенту нужно помнить содержмиое нескольких команд, чтобы не реагировать дважды... неочень удобно. Если запоминать слишком много - то некоторые уникальные новые запросыф могут быть отсеяны, если мало - на некоторые клиент будет отвечать два раза. На больших хабах поисковых запросов валится очень очень много, от разных пользователей - там буфер надо большой. На маленьких - наоборот ищут одни и теже пользователи, буфер надо маленький.
  Если клиент предпочитает ipv6, то при получении ipv4 ему нужно одождать некоторое время, вдруг придет ipv6... Конечно это исключительная ситуация, но всеже вцелом проблема связывания этих двух команд существует.

В моей схеме

• Старые клиенты должны получать команды старого типа и соответственно они будут их корректно обрабатывать. При получении команды нового типа (а такого происходить вообще-то не должно) они их просто проигнорируют. По этому пункту моя схема лучше.
• Новые клиенты обрабатывают их легко и быстро, т.к. новые команды гораздо проще по структуре. По этому пункту моя схема тоже лучше.
• Новые команды короче и клиенту в зависимости от поддержки отсылается либо старая длинная команда, либо новая короткая. Это приводит к сильному сокращению исходящего трафика хаба, особенно в будущем, когда большинство клиентом будет работать на командах нового типа. По этому пункту моя схема тоже лучше.
• Команда отсылается одна и сразу в себе содержет все необходимые параметры. По этому пункту моя схема тоже лучше.

Клиент при коннекте через саппортс сообщает хабу о поддержке модифицированных команд GIFTEXT. Отсылает ему эти команды и команды старого типа (не уверен что это правильно, т.к. на стороне хаба по новой команде на мой взгляд очень просто сформировать команду старого типа, но впринципе если уж тк проще, то пускай так и будет). Хаб без всякой нагрузки отсылает без изменения всем клиентам команды того типа, который они поддерживают (старым - старого, новым - нового). Вот и весь принцип...

Эмм, а можете поподробнее?

Подробней в RFC.
зы. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 14.23

Вы можете сказать своими словами? Зачем в маны сразу посылать? Типо я что-то там надумал, а что именно - ищите и разбирайтесь сами!
Я помню что браузер устанавливает tcp соединени и передает домен..., далее вебсервер решает как ему отвечать. Эта схема позволяет держать на одном ip множество сайтов... не понимаю как я это связано с обсуждаемой нами проблемой?
В общем пишите прямо!

Либо я не понял вашего поста, либо вы просто быстро забываете, что пишите. Прочитаем пост http://mydc.ru/topic5172.html?view=findpost&p=42615

Я всё прекрасно помню, я не понимаю вашего поста. Вы сказали:

тыпо вы чё, дураки, ответ же очевиден, слово Host!
Вот я и прошу чтобы вы пояснили, что за хост вы имеете ввиду.
А Вы сразу в маны посылаете... типо чтоб мы сами догадывали что вы имели ввиду.
Повашему это правильное отношение к собеседникам?
Пишите прямо что имееете ввиду, не надо юлить и запутывать разговор.

Отвечу на ваш вопрос, заголовок Host ничего мне не говоритю

Хорошо.

Каким образом, если в HTTP за определение запрашиваемого ресурса отвечает заголовок Host, когда в NMDC/ADC нет ничего подобного?

Saymon21, эмм не вижу проблемы.
Давайте продумаем по порядку, так проще всего:

1. У пользователя в фаворитах сохранен DNS в виде dchub://mydns.ru, ник и пароль.
2. Владелец DNS направил этот DNS на ip, под которым находится его nmdc хаб.
3. Далее пользователь заходит и флай автоматом авторизовывается на этом nmdc хабе.
4. Далее администратор перенаправляет редиректом пользователя на adc хаб, находящийся на этом же ip.
5. Пользователь получает команду редиректа на adc://mydns.ru
6. Флай смотрит и видет что это один и тотже днс - один и тот же хаб, заходит на ADC хаб и автоматически авторизовывается на нем.
7. Пользователь доволен, переход на ADC для него прошел без каких либо телодвижений, полностью автоматически и без проблем.

На каком шаге Вы видите возможность возникновения ошибки/проблемы?

Если администратор хачет поднять два хаба, то он может сделать так:
hub1.mydns.ru
hub2.mydns.ru:412
и т.д.
Или назначить каждому свой ip и оставить у каждого стандартный порт

Может уже хватит оффтопить?

ADC и NMDC - это не один и тот же хаб. В любом случае, пользователь должен будет переписать в клиенте адрес хаба с dchub:// на adc:// или adcs://.
Без этого никак. Для некоторых юзеров уделить пару сек. времени и переписать это вызовет кучу проблем. Странно, что вы этого не понимаете.
Во вторых, всётаки не понятно, как вы собрались делать два (или больше хабов) на одном айпи и порту, но разных доменах.


зы. Хватит редактировать посты уже постоянно! Говорили уже ведь!

Сообщение отредактировал Saymon21 - 10.2.2012, 20:41

Saymon21, я не понимаю вас, мы ведь говорим про редирект.
Редирект, это команда, отправляемая хабом и сообщающая клиенту адрес другого хаба, к которому ему нужно присоединиться.
На NMDC хабе, перенаправляющем на ADC она выглядит так:

Где вы здесь видите проблемы? Эта схема может работать постоянно, главное NMDC хаб не вырубать.
А потом IRainman еще предложил перманентный редирект
Setuper, пардон, больше не буду

грелка кстати запилил похожую фичу с полгода назад:

0.50-x64 (25.08.2011)
Поиск по открытым хабам при открытии dchub: или adc: ссылки. Если хаб уже открыт с другим url, но тем же ip+port, новое окно не открывается (OCTAGRAM)



вы пытаетесь зацепиться за невежество оппонента и послать его на RFC (что конечно правильно).
одна фактическая ошибка - и дальше, как в математическом доказательстве, вы всё последующее считаете несостоятельным.

но лучше попытаться расшифровать, что хотел сказать gift.
я так понял, он предлагает сделать доверенные зоны. при переходе на другой хаб без смены доменного имени клиент может передать те же логин/пароль, с какого хаба его переадресовали, считая, что пароль не уйдёт левым людям

это чисто клиентская заморока.
какая-то логика в ней есть, но хаб не может угадать, какой домен был в ссылке, с которой пришёл клиент и выдать редиректную ссылку, содержащую тот же домен.
поэтому решение недостаточно надёжное, чтобы бросаться реализовывать его в клиенте.

кстати, в ADC есть referer
http://dcpp.wordpress.com/2008/01/17/adc-hub-referrer/

[offtop]
Хех. У нас вот только вчера на работе говорилось, мол если ехать куда далеко и долго, бывает полезно перед поездкой распечатать какой нить RFC и читать в дороге...
Refer в ADC, ну да, знаем. Кстати вот, и в nmdc есть http://mydc.ru/topic5095.html?view=findpost&p=41616
[/offtop]

Petr Kozelka (разработчик птохи):

Честно говоря не понимаю, как можно создать ддост отаку по TCP в DC...? Я уже несколько раз описывал что с файлообменом никаких проблем нет, DOS отаку не организовать. Проблема только с UDP и соответственно если ip не подтвержден - то блокировать нужно только UDP, т.е. поиск. А возможность устаналивать TCP содинения нужно оставить т.к. по протоколу массовую TCP ддос отаку организовать не получится. Почему-то все заблуждаются на этот счет.
Разрабы птохи пошли по банальному пути наименьшего сопротивления, впихнули IPv6 адреса в старые команды....

Таким образом, если я правильно понял, в итоге получаем ИХ схему:

• Если хаб шлет старым клиентам команды с ipv6 - старые клиенты пытаются обработать такие команды и у них ничего не выходит или выходит непонятно что.
• Зачем-то затронули команду $MyINFO...
• Новые клиенты обрабатывают их сложными функциями, с большей нагрузкой, но корректно (Например для разделения блоков ipv6 и отделения порта от ipv6 используется один и тот же разделитель - знако двоеточия. В функции придется выделять квадратные скобки... в общем это не очень удобно)
• Команды соответствующего формата отправляются пользователям с соответствующим протоколом (IPv4/IPv6). Один пользователь не может использовать сразу оба протокола. Или же отсылается две команды с разными ip адресами подряд, сначала с ipv4, потом с ipv6. В таком случае новому клиенту нужно помнить содержмиое нескольких команд, чтобы не реагировать дважды на один запрос... неочень удобно. А также, весьма существенный факт - увеличивается трафик хаба. А, как вы все знаете, сейчас это большая проблема, хабы генерят слишком много трафика.
• Не получаем никакого выигрыша по трафику, хотя смысл этого не сделать, если совместимость со старыми клиентами всеравно теряем?...
• И самое интересное, если опять же я правильно понял, при каждом поиске по другому протоколу клиент устанавливает новое соединение с хабом...?

В моей схеме:

• Старые клиенты должны получать команды старого типа и соответственно они будут их корректно обрабатывать. При получении команды нового типа (а такого происходить вообще-то не должно) они их просто проигнорируют.
• Новые клиенты обрабатывают их легко и быстро, т.к. новые команды гораздо проще (идеальны) по структуре.
• Затронуто минимальное кол-во команд, необходимое для поддержки IPv6. MyINFO я не трогал...
• Новые команды короче и клиенту, в зависимости от поддержки, отсылается либо старая длинная команда, либо новая короткая. Это приводит к сильному сокращению исходящего трафика хаба, особенно в будущем, когда большинство клиентом будет работать на командах нового типа.
• Команда отсылается одна и сразу в себе содержет все необходимые параметры. Один клиент на хабе работает сразу одновременно по обоим протоколам. Т.е. качает и раздает сразу и по ipv4 и по ipv6. Поиск соответственно без подтверждения идет только по одному IPv4 или IPv6, ибо есть вероятность доса. А при подтверждении - сразу по обоим. Для подтверждения, как уже говорилось, нужно устанавливать второе соединение с хабом. Если это реализовать - ipv4 и ipv6 на NMDC будут поддерживаться одновременно и абсолютно полностью.
• Сокращен трафик за счет передачи IP адресов и портов отдельно и только при изменении. В Поисковых запросах и командах на установку соединения соответственно они не отсылаются. А также сокращен трафик за счет уменьшения длины ключей.

Ну я думаю картина вполне ясна, моё предложение оказалось весьма запоздалым и уже не получится переубедить создателей птохи.
Решайте что будете реализовывать, вериант птохи, мой или свой или все сразу или ничего. На ADC я советую не надеяться, админы хабов еще не скоро переселятся на него и переселят всех пользователей, даже под аргументом IPv6.

Еще добавлю одну вещь:

Это средняя популярность DC клиентов на хабах:

С разработчиками флайлинка они обязаны согласовать своё решение. Если флайлинк не будет поддерживать их модификацию - собственно говоря в ней не будет особого смысла.

знали бы вы как этот "разраб птохи" относится к вашим "обзываниям" птоки / PtokaX - "птохой"

Артём, я знаю, просто не звучит...
Я им кстате в письме пояснил что так некоторые русские называют их хаб
Товарищь IRainman тож пишет птоха: http://mydc.ru/topic5172s60.html?p=42614#entry42614

птоха - это почти официальный перевод на русский слова ptokax

Если разработчики флая поддержат их концепцию, то это значительно ухудшит ситуацию с распространением протокола ADC.
А так ещё есть шанс, что по мере получения ipv6 юзеры будут активнее юзать ADC. ADC протокол более продуманный, чем NMDC в части минимизации трафика.

Кстати, отказ клиентов от их концепции может помочь им открыть глаза для перехода на ADC.

Пока я не заметил поддержки их концепции со стороны флая...думаю сейчас IRainman отпишется
А куда писать насчет ADC, хочу предложить им добавить кое-что?

да, ADC-команда может содержать одновременно v4 и v6-адреса. без потери совместимости с существующими клиентами.
но вопрос второго коннекта клиента к хабу для подтверждения адреса в ADC не решён.

так что тут есть поле для велосипедостроения )))

Еще всетаки опционально могли бы сделать передачу TCP портов в INF и отключение команды RCM на хабе, т.к. не все админы хотят ограничивать некоторым пользователям файлообмен, и включение такой опции немного снизило бы трафик и нагрузку на ADC хабах, т.к. пассивные пользователи могли бы соединяться с активными напрямую, без отправки хабу RCM.

не-мо-гли-бы ни-ког-да!

что написано в референсном коде принятия соединения?

это NMDC.
ADC проверяется ещё и по токену, который прошёл через хаб.

если хаб не предупредил, что сейчас будет соединение от юзера, оно просто дропается.
конечно, если переделать все-все клиенты... но это фантастика.