Версия для печати темы
Нажмите сюда для просмотра этой темы в обычном формате
MyDC.ru _ Всё о Direct Connect _ NMDC Extensions
Автор: Meloun 4.1.2012, 19:46
Доброго времени суток друзья. Предлагаю вашему вниманию информацию по новым расширениям и дополнительным командам Neo Modus Direct Connect протокола, которые нарыл в интернетах. NMDC как бы и не собирается помирать 
Расширение:
Тип взаимодействия: Клиент-Клиент
Хабы поддерживающие расширение: поддержка со стороны хаба не требуется.
Клиенты поддерживающие расширение: StrongDC++ 2.2 и выше, а также клиенты на нем базирующиеся.
Назначение: Шифрование трафика между клиентами (защищенная передача файлов).
Описание: Клиенты поддерживающие это расширение выставляют флаг 0x10 в передаваемой хабу команде http://mydc.ru/topic915.html?p=6721#entry6721. Клиент который хочет инициировать файлообмен и также поддерживающий это расширение отсылает команду http://mydc.ru/topic915.html?p=6692#entry6692, но добавляет в самый конец (приписывает к номеру порта) символ "S". Наличие этого символа приписанного к номеру порта говорит о том, что клиент хочет инициировать TLS-соединение и начать защищенное скачивание файла. Номер порта для TLS соединений указывается отдельно в настройках клиента.
Источник:
Расширение:
Тип взаимодействия: Клиент-Клиент
Хабы поддерживающие расширение: поддержка со стороны хаба не требуется.
Клиенты поддерживающие расширение: StrongDC++ 2.40 и выше, а также клиенты на нем базирующиеся.
Назначение: Возможность передавать файлы между двумя пассивными клиентами за NAT.
Описание:
Клиенты поддерживающие это расширение выставляют флаг 0x20 в передаваемой хабу команде http://mydc.ru/topic915.html?p=6721#entry6721. Пассивный клиент "A" который хочет инициировать файлообмен с удаленным клиентом "B" отсылает стандартную команду http://mydc.ru/topic915s20.html?p=6739#entry6739. Если удаленный клиент "B" также в пассивном режиме и поддерживает это расширение, то в ответ передает коменду http://mydc.ru/topic915.html?p=6692#entry6692 вида:
где <port> это номер локального порта с которого клиент "B" подключен к хабу (outbond port, см. спецификацию сокетов). Как видно к номеру порта добавляется символ "N" ("NS" в случае TLS соединения). Когда клиент "A" получает эту команду, то пытается подключиться к указанному IP:port и одновременно отсылает обратно команду:
где <port> это также номер локального порта с которого уже клиент "A" подключен к хабу. Теперь к номеру порта добавляется символ "R" ("RS" в случае TLS соединения). Когда клиент "B" получает эту команду, то сразу пытается подключиться к указанному IP:port.
Данные манипуляции позволяют обойти ограничения NAT и организовать "туннель". Очень красивое и оригинальное решение (прим. переводчика).
Источник:
Расширение: Locale
Тип взаимодействия: Клиент-Хаб, Хаб-Клиент
Хабы поддерживающие расширение: FLEXHUB.
Клиенты поддерживающие расширение: ?? неизвестно.
Назначение: Согласование кодировки и других региональных настроек между клиентом и хабом.
Описание:
последовательность команд (C-клиент, H-хаб):
H: $Supports Locale|
H: $Locale CSwindows-1251 DILR DA"<string>" TI"<string>"|
Следующие поля могут быть использованы, но могут и не указываться (автор придерживается стиля команд ADC протокола):
CS = кодировка
DI = направление написания текста, LR = слева-на-право, RL = справа-на-лево
DA=формат даты
TI=формат времени
Другие поля могут добавляться при необходимости.
Источник:
Расширение: SaltPass
Тип взаимодействия: Клиент-Хаб, Хаб-Клиент
Хабы поддерживающие расширение: FLEXHUB.
Клиенты поддерживающие расширение: DiCe!++, ?? неизвестно.
Назначение: безопасная валидация по паролю при входе на хаб.
Описание:
Безопасная передача запроса пароля в виде "соли" и самого пароля в виде хэша как производную от пароля и "соли".
Алгоритм вычисления "соли" и хэша аналогичен протоколу ADC. Хаб передаёт "соль" клиенту с помощью команды http://mydc.ru/topic915.html?p=6711#entry6711, клиент добавляет "соль" к паролю и вычисляет хэш, который конвертируется в base32 текстовый формат и отсылается клиентом хабу с помощью команды http://mydc.ru/topic915.html?p=6733#entry6733.
Последовательность команд:
H: $Supports SaltPass
C: $ValidateNick <nick>
H: $GetPass <salt>
C: $MyPass <salted pass>
Источник:
Автор: mariner 4.1.2012, 20:17
Полезная фича!
Автор: Saymon21 4.1.2012, 20:26
Плюсую. Осталось внедрить в другие клиенты.
А тему эту, кстати, думаю стоит закинуть сюда http://mydc.ru/topic915.html
Автор: Meloun 5.1.2012, 6:59
Расширение: FailOver
Тип взаимодействия: Хаб-Клиент
Хабы поддерживающие расширение: FLEXHUB.
Клиенты поддерживающие расширение: ?? неизвестно.
Назначение: организация и изменение списка альтернативных адресов в клиенте для хаба.
Описание:
Алгоритм основан на из ADC протокола, и является реализацией для NMDC.
Данное расширение обеспечивает поддержку клиентом нескольких альтернативных адресов для хаба (могут быть как адреса этого же хаба, так и других хабов), к которым клиент будет подключаться в случаях недоступности основного адреса.
В случае подключения к альтернативному адресу по причине недоступности основоного, клиент периодически проверяет доступность основного и в случае возобновления работы либо переключается обратно, либо выполняет другое действие указанное в настройках клиента.
Синтаксис команды:
Последовательность команд:
Hub: $Supports ... FailOver|
Hub: $FailOver someaddress.no-ip.org,adc://someotheraddress.com:5432|
Команда $FailOver может отправляться клиентам в любое время, но только после отсылки хабом команды характеристик $Supports и только тем клиентам которые поддерживают это расширение. Повторная отправка команды $FailOver перезаписывает (а не добавляет к уже существующим прим. переводчика) альтернативные адреса хаба в клиенте. Оправка пустой команды $FailOver| удаляет все альтернативные адреса (остаётся только основной прим. переводчика), клиент будет ждать когда основной адрес станет доступным.
Источник:
Расширение: http://mydc.ru/topic915.html?p=6719#entry6719
Тип взаимодействия: Клиент-Клиент
Хабы поддерживающие расширение: поддержка со стороны хаба не требуется.
Клиенты поддерживающие расширение: StrongDC 2.4 и выше, а также клиенты на нем базирующиеся..
Назначение: расширение команды $Lock отсылаемой клиенту.
Описание:
данное расширение команды $Lock используется при инициалиации соединения между клиентами, т.е. после отправки через хаб команды http://mydc.ru/topic915.html?p=6692#entry6692. Команда имеет вид:
как видно синтаксис идентичен старой версии команды, но в самом конце добавилась строка Ref=dc.domain.com:port причём без разделительного пробела, для совместимости сос тарыми клиентами. Данный параметр показывает на то с какого хаба клиентом была получена команда $ConnectToMe для инициализации соединения.
Для чего эту фичу добавили в стронг неизвестно, в вопросах файлообмена она абсолютно не нужна, но вот для владельцев хабов да и не только может быть очень полезной. В случае DDoS атаки CTM вам на блюдечке с каёмочкой клиенты будут слать адрес хаба с которого этот ддос устроили ;)
Автор: Delia 8.1.2012, 13:39
Возник вопрос. Очень хотелось бы услышать капитальный ответ.
В каких конкретно случаях для работы некоего расширения требуется поддержка со стороны клиента, в каких со стороны хаба, в каких с обеих сторон и что в этом случае означает "расширяемость протокола", заявленная как фича в ADC?
Или так.
Если модифицируется взаимодействие между клиентами, то какие следствия возникают при этом для хаба? Если модифицируется взаимодействие между хабом и клиентом, то где тот порог, когда поддержка мода нужна с обеих сторон? И если модификация в работе только на стороне хаба(uHub как пример), то как, чёрт возьми, тогда это вообще работает?
NMDC и ADC.
Или я всё усложнил? Разумею так.
Клиент сообщает, что умеет он. Хаб сообщает, что умеет он. Итого, взаимодействовать они будут по тому, что у них совпадёт в качестве поддержки. Клиенты же будут контачить как минимум по тому, что умеет хаб, а как максимум по тому, что хабу, возможно, и знать не надо. Только при такой модели всё же не совсем понятно что же это за расширяемость протокола такая. Почему именно протокола, если в конечном итоге всё определяется обменом любезностями? И что за проблемы с неадекватным количеством отправляемых хабу данных были с расширением FS Апекса?
Суточные дежурства, я вас обожаю.
Автор: Enyby 8.1.2012, 14:34
Насколько я понял, есть базовый набор команд, которые и составляют основу протокола. Далее пошла отсебятина через расширения. И там ситуация именна та, как ты ее описал.
Хотя тут еще может быть такая фишка, что реализация на клиенте отличается от предполагаемой хабом. Например, клиент делает запрос файл-листа, хаб думает, что клиент будет качать и отдает IP+port. Клиент подбирает IP и уходит восвояси ничего не качая. Это утрировано.
Пока интерфейс останется тем же - все будет работать.
Это в NMDC. В ADC, насколько я вижу, все чуть иначе. Хаб может передавать команды расширений между клиентами, не вникая в сути команд. Т. е. поддержка расширения вроде и как бы не нужна.
Хаб должен отослать эту команду всем клиентам, которые поддерживают данную характеристику. Поддержка клиентом той или иной характеристики определяется из поля SU, которое содержится в команде INF, отсылаемой клиентом.
Автор: gif-t 18.2.2012, 23:33
А какой это по счету бит?
Автор: Enyby 19.2.2012, 10:55
http://mydc.ru/topic915.html?p=6721#entry6721
Местоположение флага в строке майинфо не фиксированно и зависит от размера предыдущих частей.
Если же речь идет о бите в флаге, то 0x20 == 00100000.
Автор: gif-t 19.2.2012, 16:26
Нет, с местоположением флага у меня нет проблем. Я не пойму, какой бит в флаге отвечает за поддержку NAT-T?
0x20 я тоже перевел в 00100000, но 1 находится на 3-ем месте. А по протоколу я знаю что за режим away отвечает второй бит, за сервер - третий бит, за бомбу - четвёртый бит. А NAT-T бит находится на 5-ом, 6, 7 или 8-ом месте.
Также я знаю что в флайлинке некоторое время бит NAT-T использовался для передачи пола пользователей.
Но какой это по порядку бит я не нашел, а на практике затруднительно набрать статистику, потому как NAT еще можно определить из команды connecttome, а она не содержет ника....в общем сложно....
Автор: Enyby 19.2.2012, 16:28
А я знаю, что биты нумеруются справа налево...
87654321
Автор: gif-t 19.2.2012, 16:39
От блин, а я уж и не припомню такого, получается шестой бит...
Большое спасибо, пойду проверять