myDC.ru

Здравствуйте, гость ( Вход | Регистрация )

 
 
Ответить в данную темуНачать новую тему

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

Meloun
сообщение 4.1.2012, 19:46
Сообщение #1


Начинающий
*

Группа: Пользователи
Сообщений: 22
Регистрация: 16.11.2011
Пользователь №: 9 943
Спасибо сказали: 12 раз




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



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

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

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

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

Код
$ConnectToMe user1 IP:portS|


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



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

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

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

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

Код
$ConnectToMe <A's nick> <B's IP>:<port>N <B's nick>|


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

Код
$ConnectToMe <B's nick> <A's IP>:<port>R|


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

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

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




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

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

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

Описание:

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

Код
C: $Supports Locale|
H: $Supports Locale|
H: $Locale CSwindows-1251 DILR DA"<string>" TI"<string>"|


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

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

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

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





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

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

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

Описание:

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

Последовательность команд:
Код
C: $Supports SaltPass
H: $Supports SaltPass
C: $ValidateNick <nick>
H: $GetPass <salt>
C: $MyPass <salted pass>


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


Спасибо сказали:
Go to the top of the page
+Quote Post
mariner
сообщение 4.1.2012, 20:17
Сообщение #2


Местная ТехПоддержка
**********

Группа: Администраторы
Сообщений: 1 875
Регистрация: 18.7.2008
Из: Моск. Обл, г. королев, район Болшево
Пользователь №: 221
Спасибо сказали: 220 раз




Цитата
SaltPass

Полезная фича!
Go to the top of the page
+Quote Post
Saymon21
сообщение 4.1.2012, 20:26
Сообщение #3


Site Reliability Engineer
*********

Группа: Модераторы
Сообщений: 1 772
Регистрация: 27.6.2009
Из: Чувашия, г. Чебоксары
Пользователь №: 3 719
Спасибо сказали: 479 раз




Плюсую. Осталось внедрить в другие клиенты.
А тему эту, кстати, думаю стоит закинуть сюда http://mydc.ru/topic915.html
Go to the top of the page
+Quote Post
Meloun
сообщение 5.1.2012, 6:59
Сообщение #4


Начинающий
*

Группа: Пользователи
Сообщений: 22
Регистрация: 16.11.2011
Пользователь №: 9 943
Спасибо сказали: 12 раз




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

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

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

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

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

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

Код
$FailOver <address1[:port]>,<address2[:port]>|


Последовательность команд:
Код
Client:        $Supports ... FailOver|
Hub:    $Supports ... FailOver|
Hub:    $FailOver someaddress.no-ip.org,adc://someotheraddress.com:5432|


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

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




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

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

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

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

Код
$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.785Ref=dc.example.com:port


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

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




Спасибо сказали:
Go to the top of the page
+Quote Post
Delia
сообщение 8.1.2012, 13:39
Сообщение #5


Продвинутый участник
****

Группа: Пользователи
Сообщений: 133
Регистрация: 12.5.2010
Пользователь №: 6 838
Спасибо сказали: 24 раза




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

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

Или я всё усложнил? Разумею так.
Клиент сообщает, что умеет он. Хаб сообщает, что умеет он. Итого, взаимодействовать они будут по тому, что у них совпадёт в качестве поддержки. Клиенты же будут контачить как минимум по тому, что умеет хаб, а как максимум по тому, что хабу, возможно, и знать не надо. Только при такой модели всё же не совсем понятно что же это за расширяемость протокола такая. Почему именно протокола, если в конечном итоге всё определяется обменом любезностями? И что за проблемы с неадекватным количеством отправляемых хабу данных были с расширением FS Апекса?
Суточные дежурства, я вас обожаю.
Go to the top of the page
+Quote Post
Enyby
сообщение 8.1.2012, 14:34
Сообщение #6


Освоившийся участник
*****

Группа: Пользователи
Сообщений: 391
Регистрация: 4.11.2009
Из: Дом
Пользователь №: 4 923
Спасибо сказали: 239 раз




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

Это в NMDC. В ADC, насколько я вижу, все чуть иначе. Хаб может передавать команды расширений между клиентами, не вникая в сути команд. Т. е. поддержка расширения вроде и как бы не нужна.
Цитата
F (Feature broadcast)
Хаб должен отослать эту команду всем клиентам, которые поддерживают данную характеристику. Поддержка клиентом той или иной характеристики определяется из поля SU, которое содержится в команде INF, отсылаемой клиентом.
Go to the top of the page
+Quote Post
gif-t
сообщение 18.2.2012, 23:33
Сообщение #7


Участник
**

Группа: Пользователи
Сообщений: 49
Регистрация: 3.2.2012
Пользователь №: 10 254
Спасибо сказали: 1 раз




Цитата
Клиенты поддерживающие это расширение выставляют флаг 0x20 в передаваемой хабу команде $MyINFO

А какой это по счету бит?
Go to the top of the page
+Quote Post
Enyby
сообщение 19.2.2012, 10:55
Сообщение #8


Освоившийся участник
*****

Группа: Пользователи
Сообщений: 391
Регистрация: 4.11.2009
Из: Дом
Пользователь №: 4 923
Спасибо сказали: 239 раз




http://mydc.ru/topic915.html?p=6721#entry6721
Местоположение флага в строке майинфо не фиксированно и зависит от размера предыдущих частей.
Если же речь идет о бите в флаге, то 0x20 == 00100000.
Go to the top of the page
+Quote Post
gif-t
сообщение 19.2.2012, 16:26
Сообщение #9


Участник
**

Группа: Пользователи
Сообщений: 49
Регистрация: 3.2.2012
Пользователь №: 10 254
Спасибо сказали: 1 раз




Нет, с местоположением флага у меня нет проблем. Я не пойму, какой бит в флаге отвечает за поддержку NAT-T?
0x20 я тоже перевел в 00100000, но 1 находится на 3-ем месте. А по протоколу я знаю что за режим away отвечает второй бит, за сервер - третий бит, за бомбу - четвёртый бит. А NAT-T бит находится на 5-ом, 6, 7 или 8-ом месте.
Также я знаю что в флайлинке некоторое время бит NAT-T использовался для передачи пола пользователей.
Но какой это по порядку бит я не нашел, а на практике затруднительно набрать статистику, потому как NAT еще можно определить из команды connecttome, а она не содержет ника....в общем сложно....
Go to the top of the page
+Quote Post
Enyby
сообщение 19.2.2012, 16:28
Сообщение #10


Освоившийся участник
*****

Группа: Пользователи
Сообщений: 391
Регистрация: 4.11.2009
Из: Дом
Пользователь №: 4 923
Спасибо сказали: 239 раз




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


Спасибо сказали:
Go to the top of the page
+Quote Post
gif-t
сообщение 19.2.2012, 16:39
Сообщение #11


Участник
**

Группа: Пользователи
Сообщений: 49
Регистрация: 3.2.2012
Пользователь №: 10 254
Спасибо сказали: 1 раз




От блин, а я уж и не припомню такого, получается шестой бит...
Большое спасибо, пойду проверять
Go to the top of the page
+Quote Post

Ответить в данную темуНачать новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

Collapse

> Похожие темы

  Тема Ответов Автор Просмотров Последнее сообщение
No new Topic has attachmentsВопросы по протоколу NMDC
Делаю программу
26 Master255 27 415 12.1.2015, 0:38 Посл. сообщение: Master255
No New Posts От: вопрос по NMDC.
От темы с ID: 4932
0 MIKHAIL 5 185 25.1.2013, 19:48 Посл. сообщение: MIKHAIL
No New Posts вопрос по NMDC.
.
6 Lamo 12 676 29.5.2012, 19:35 Посл. сообщение: Lamo
No new Topic has attachmentsПротокол IPv6 в протоколе NMDC
Спецификация и тестирование IPv6 в NMDC
109 gif-t 88 779 26.2.2012, 10:12 Посл. сообщение: AMD
No New Posts От: NMDC Extensions
От темы с ID: 5095
0 Артём 5 281 4.1.2012, 18:56 Посл. сообщение: Артём
No new Topic has attachmentsПингер NMDC-хабов
Ударим опенсорсом по нездоровой шняге
23 alex82 36 861 11.4.2011, 18:12 Посл. сообщение: alex82
No New Posts От: Пингер NMDC-хабов
От темы с ID: 4787
1 Invisible 6 257 4.4.2011, 1:10 Посл. сообщение: EvilNico
No new Скачивание файл-листа, nmdc
Последовательность команд
16 HackFresse 24 819 3.11.2010, 12:48 Посл. сообщение: Atlant
No new Реализация NMDC команды $MCTo
дабы не затерялось
15 Setuper 21 496 28.8.2009, 16:59 Посл. сообщение: Delion
Closed ВАЖНО: Описание Протокола NMDC
NeoModus Direct Connect Protocol
73 Setuper 246 604 14.8.2009, 16:45 Посл. сообщение: Setuper
No New Posts От: Описание Протокола NMDC
От темы с ID: 915
0 Setuper 5 926 9.1.2009, 21:41 Посл. сообщение: Setuper

 



RSS Сейчас: 28.3.2024, 12:54