NMDC Extensions, Расширения и новые команды NMDC протокола

Доброго времени суток друзья. Предлагаю вашему вниманию информацию по новым расширениям и дополнительным командам Neo Modus Direct Connect протокола, которые нарыл в интернетах. NMDC как бы и не собирается помирать



Расширение: TLS Шифрование

Тип взаимодействия: Клиент-Клиент
Хабы поддерживающие расширение: поддержка со стороны хаба не требуется.
Клиенты поддерживающие расширение: StrongDC++ 2.2 и выше, а также клиенты на нем базирующиеся.

Назначение: Шифрование трафика между клиентами (защищенная передача файлов).

Описание: Клиенты поддерживающие это расширение выставляют флаг 0x10 в передаваемой хабу команде $MyINFO. Клиент который хочет инициировать файлообмен и также поддерживающий это расширение отсылает команду $ConnectToMe, но добавляет в самый конец (приписывает к номеру порта) символ "S". Наличие этого символа приписанного к номеру порта говорит о том, что клиент хочет инициировать TLS-соединение и начать защищенное скачивание файла. Номер порта для TLS соединений указывается отдельно в настройках клиента.



Источник: http://strongdc.sourceforge.net/forum/view...f=11&t=5528



Расширение: NAT Traversal

Тип взаимодействия: Клиент-Клиент
Хабы поддерживающие расширение: поддержка со стороны хаба не требуется.
Клиенты поддерживающие расширение: StrongDC++ 2.40 и выше, а также клиенты на нем базирующиеся.

Назначение: Возможность передавать файлы между двумя пассивными клиентами за NAT.

Описание:
Клиенты поддерживающие это расширение выставляют флаг 0x20 в передаваемой хабу команде $MyINFO. Пассивный клиент "A" который хочет инициировать файлообмен с удаленным клиентом "B" отсылает стандартную команду $RevConnectToMe. Если удаленный клиент "B" также в пассивном режиме и поддерживает это расширение, то в ответ передает коменду $ConnectToMe вида:



где <port> это номер локального порта с которого клиент "B" подключен к хабу (outbond port, см. спецификацию сокетов). Как видно к номеру порта добавляется символ "N" ("NS" в случае TLS соединения). Когда клиент "A" получает эту команду, то пытается подключиться к указанному IP:port и одновременно отсылает обратно команду:



где <port> это также номер локального порта с которого уже клиент "A" подключен к хабу. Теперь к номеру порта добавляется символ "R" ("RS" в случае TLS соединения). Когда клиент "B" получает эту команду, то сразу пытается подключиться к указанному IP:port.

Данные манипуляции позволяют обойти ограничения NAT и организовать "туннель". Очень красивое и оригинальное решение (прим. переводчика).

Источник: http://strongdc.sourceforge.net/forum/view...f=11&t=6001




Расширение: Locale

Тип взаимодействия: Клиент-Хаб, Хаб-Клиент
Хабы поддерживающие расширение: FLEXHUB.
Клиенты поддерживающие расширение: ?? неизвестно.

Назначение: Согласование кодировки и других региональных настроек между клиентом и хабом.

Описание:

последовательность команд (C-клиент, H-хаб):



Следующие поля могут быть использованы, но могут и не указываться (автор придерживается стиля команд ADC протокола):

CS = кодировка
DI = направление написания текста, LR = слева-на-право, RL = справа-на-лево
DA=формат даты
TI=формат времени

Другие поля могут добавляться при необходимости.

Источник: http://www.flexhub.org/forum/index.php?topic=312.0





Расширение: SaltPass

Тип взаимодействия: Клиент-Хаб, Хаб-Клиент
Хабы поддерживающие расширение: FLEXHUB.
Клиенты поддерживающие расширение: DiCe!++, ?? неизвестно.

Назначение: безопасная валидация по паролю при входе на хаб.

Описание:

Безопасная передача запроса пароля в виде "соли" и самого пароля в виде хэша как производную от пароля и "соли".
Алгоритм вычисления "соли" и хэша аналогичен протоколу ADC. Хаб передаёт "соль" клиенту с помощью команды $GetPass, клиент добавляет "соль" к паролю и вычисляет хэш, который конвертируется в base32 текстовый формат и отсылается клиентом хабу с помощью команды $MyPass.

Последовательность команд:


Источник: http://www.flexhub.org/forum/index.php?topic=311.0

Полезная фича!

Плюсую. Осталось внедрить в другие клиенты.
А тему эту, кстати, думаю стоит закинуть сюда http://mydc.ru/topic915.html

Расширение: FailOver

Тип взаимодействия: Хаб-Клиент
Хабы поддерживающие расширение: FLEXHUB.
Клиенты поддерживающие расширение: ?? неизвестно.

Назначение: организация и изменение списка альтернативных адресов в клиенте для хаба.

Описание:
Алгоритм основан на FO extension из ADC протокола, и является реализацией для NMDC.

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

Синтаксис команды:



Последовательность команд:


Команда $FailOver может отправляться клиентам в любое время, но только после отсылки хабом команды характеристик $Supports и только тем клиентам которые поддерживают это расширение. Повторная отправка команды $FailOver перезаписывает (а не добавляет к уже существующим прим. переводчика) альтернативные адреса хаба в клиенте. Оправка пустой команды $FailOver| удаляет все альтернативные адреса (остаётся только основной прим. переводчика), клиент будет ждать когда основной адрес станет доступным.

Источник: http://www.flexhub.org/forum/index.php?topic=184.0




Расширение: $Lock

Тип взаимодействия: Клиент-Клиент
Хабы поддерживающие расширение: поддержка со стороны хаба не требуется.
Клиенты поддерживающие расширение: StrongDC 2.4 и выше, а также клиенты на нем базирующиеся..

Назначение: расширение команды $Lock отсылаемой клиенту.

Описание:
данное расширение команды $Lock используется при инициалиации соединения между клиентами, т.е. после отправки через хаб команды $ConnectToMe. Команда имеет вид:



как видно синтаксис идентичен старой версии команды, но в самом конце добавилась строка Ref=dc.domain.com:port причём без разделительного пробела, для совместимости сос тарыми клиентами. Данный параметр показывает на то с какого хаба клиентом была получена команда $ConnectToMe для инициализации соединения.

Для чего эту фичу добавили в стронг неизвестно, в вопросах файлообмена она абсолютно не нужна, но вот для владельцев хабов да и не только может быть очень полезной. В случае DDoS атаки CTM вам на блюдечке с каёмочкой клиенты будут слать адрес хаба с которого этот ддос устроили ;)

Возник вопрос. Очень хотелось бы услышать капитальный ответ.
В каких конкретно случаях для работы некоего расширения требуется поддержка со стороны клиента, в каких со стороны хаба, в каких с обеих сторон и что в этом случае означает "расширяемость протокола", заявленная как фича в ADC?

Или так.
Если модифицируется взаимодействие между клиентами, то какие следствия возникают при этом для хаба? Если модифицируется взаимодействие между хабом и клиентом, то где тот порог, когда поддержка мода нужна с обеих сторон? И если модификация в работе только на стороне хаба(uHub как пример), то как, чёрт возьми, тогда это вообще работает?
NMDC и ADC.

Или я всё усложнил? Разумею так.
Клиент сообщает, что умеет он. Хаб сообщает, что умеет он. Итого, взаимодействовать они будут по тому, что у них совпадёт в качестве поддержки. Клиенты же будут контачить как минимум по тому, что умеет хаб, а как максимум по тому, что хабу, возможно, и знать не надо. Только при такой модели всё же не совсем понятно что же это за расширяемость протокола такая. Почему именно протокола, если в конечном итоге всё определяется обменом любезностями? И что за проблемы с неадекватным количеством отправляемых хабу данных были с расширением FS Апекса?
Суточные дежурства, я вас обожаю.

Насколько я понял, есть базовый набор команд, которые и составляют основу протокола. Далее пошла отсебятина через расширения. И там ситуация именна та, как ты ее описал.
Хотя тут еще может быть такая фишка, что реализация на клиенте отличается от предполагаемой хабом. Например, клиент делает запрос файл-листа, хаб думает, что клиент будет качать и отдает IP+port. Клиент подбирает IP и уходит восвояси ничего не качая. Это утрировано.
Пока интерфейс останется тем же - все будет работать.

Это в NMDC. В ADC, насколько я вижу, все чуть иначе. Хаб может передавать команды расширений между клиентами, не вникая в сути команд. Т. е. поддержка расширения вроде и как бы не нужна.

А какой это по счету бит?

http://mydc.ru/topic915.html?p=6721#entry6721
Местоположение флага в строке майинфо не фиксированно и зависит от размера предыдущих частей.
Если же речь идет о бите в флаге, то 0x20 == 00100000.

Нет, с местоположением флага у меня нет проблем. Я не пойму, какой бит в флаге отвечает за поддержку NAT-T?
0x20 я тоже перевел в 00100000, но 1 находится на 3-ем месте. А по протоколу я знаю что за режим away отвечает второй бит, за сервер - третий бит, за бомбу - четвёртый бит. А NAT-T бит находится на 5-ом, 6, 7 или 8-ом месте.
Также я знаю что в флайлинке некоторое время бит NAT-T использовался для передачи пола пользователей.
Но какой это по порядку бит я не нашел, а на практике затруднительно набрать статистику, потому как NAT еще можно определить из команды connecttome, а она не содержет ника....в общем сложно....

А я знаю, что биты нумеруются справа налево...

От блин, а я уж и не припомню такого, получается шестой бит...
Большое спасибо, пойду проверять