Протокол IPv6 в протоколе NMDC, Спецификация и тестирование IPv6 в NMDC |
Здравствуйте, гость ( Вход | Регистрация )
Протокол IPv6 в протоколе NMDC, Спецификация и тестирование IPv6 в NMDC |
4.2.2012, 0:12
Сообщение
#21
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Да, как бы неочень получается, продолжим ту тему здесь? Т.к. та тема не в том разделе и я предлагаю серьезно обсужадть не только спецификацию, но и тестировать..?
Моё предложение не слать 2 команды, т.к. хабы и так генерят много трафика, а хорошенько подумать и использовать сложившуюся ситуацию себе наруку. Потому как расплата за ошибки, допущенные сейчас, в будущем может быть очень большая. Т.к. только хаб знает какие к нему присоединены клиенты, я предлагаю все команды, в которых передается ipv6 адрес, дублировать (так сказать, раз уж так получилось, подкорректируем протокол). В общем здесь я опишу как я вижу решение проблемы, а дальше жду ваших комментариев. nmdc expansion by gif-t, with ipv6 support Цель:
Основные положения:
$RevConnectToMe - команда, которую пассивный пользователь отправляет чтобы попросить другого пользователя попросить его инициировать с ним соединение, заменяются одной $RCM. Не используется клиентами на хабах, где администратор пропускает TCP порты в команде UIP. и (описние $RevConnectToMe) Обычная: Цитата $RevConnectToMe [Ник1] [Ник2]| nmdc expansion by gif-t: Цитата $RCM$[Ник_получателя]$[Ник_отправителя]| Пример: $RCM$Вася$Петя| Уточнения:
$ConnectToMe - команда, которую активный пользователь отправляет чтобы попросить другого пользователя инициировать с ним соединение, заменяются одной $CTM (описние $ConnectToMe) Обычная: Цитата $ConnectToMe [Ник_получателя] [IP_отправителя]:[Порт_отправителя]| Пример: $ConnectToMe Вася 10.10.10.10:16437| nmdc expansion by gif-t: Цитата $CTM$[Ник_получателя]$[Ник_отправителя]$[IPv4_TCP_порт]$[IPv6_TCP_порт]| Вариант без IPv6 порта $CTM$Вася$Петя$163$| Вариант когда порты отдаются через $UIP и порты в $CTM не передаются вообще: $CTM$Вася$Петя| Уточнения:
Активный клиент (способный принимать входящие соединения) посылает данную команду на хаб для того, чтобы попросить пользователя [Ник_получателя] инициализировать соединение с ним (IP адрес и иногда порт тому клиенту уже извествен благодаря $UIP). $Search и $MultiSearch (описние $Search) (описние $MultiSearch) Обычная: Цитата Активный: $Search [IP]:[Порт] [Строка_поиска] $Search 10.10.10.10:412 T?T?500000?1?Gentoo$2005 Пассивный $Search Hub:[Ник] [Строка_поиска] $Search Hub:Вася T?T?500000?1?Gentoo$2005 Нет деления структуры на активный и пассивный поиски nmdc expansion by gif-t: Раскрывающийся текст Цитата $SCH$[Режим поиска_активный_пассивный]$[Ник_отправителя]$[Размер_ограничения]$[Максимальный_размер]$[Размер]$[[Тип_данных]$[Строка_поиска]| Активнй режим (Ответ отправляется по протоколу UDP) $SCH$A$Петя$T$T$67$1$Gentoo 2005| Пассивный режим (Ответ отправляется по протоколу TCP через хаб) $SCH$P$Петя$T$T$67$1$Gentoo 2005| Уточнения:
$SR - ответ на поисковый запрос (описние $SR) Нужно проверить, но я думаю эта фукция будет работать с ipv6 без модификации. $MultiSearch (описние $MultiSearch) Не знаю, она в ходу? Я просто не вижу в ней смысла. Хаб должен сам решать как и куда он пересылает поисковые запросы. Моё мнение - модификация команды не нужна. Сразу объявим $SCH как $MultiSearch на линкованых хабах. $UserIP (описние $UserIP) Обычная: Цитата $UserIP [Ник1] [IP1]$$[Ник2] [IP2]$$[Ник3] [IP3]$$ ... $$[НикN] [IPN]$$| nmdc expansion by gif-t: Раскрывающийся текст Цитата $UIP$$[Ник1]$[IPv4]$[Порт_TCP_v4]$[Порт_UDP_v4]$[IPv6]$[Порт_TCP_v6]$[Порт_UDP_v6]$$[Ник2]$[IPv4]$[Порт_TCP_v4]$[Порт_UDP_v4]$[IPv6]$[Порт_TCP_v6]$[Порт_UDP_v6]$$ ... $$[НикN]$[IPv4]$[Порт_TCP_v4]$[Порт_UDP_v4]$[IPv6]$[Порт_TCP_v6]$[Порт_UDP_v6]| Пример с одинковыми портами: $UIP$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$-$-| Пример с разыми портами: $UIP$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$645$486| Пример первый пользователь с разыми портами, второй с одинковыми портами: $UIP$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$645$486$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$-$-| Пример параметров клиента, рассылаемых командой $UIP хабом, когда клиент соединен с хабом по IPv6. (Т.е. ipv4 адрес не подтвержден и UDPv4 порт заменен на символ "_"): $UIP$$Петя$192.168.34.64$422$_$2001:470:26:1ef::1$645$486| Уточнения:
$ForceMove (описние $ForceMove) Эту команду тоже стоит модифицировать, чтобы клиенту передавалось сразу два IP адреса, IPv6 и IPv4. Далее он сможет выбрать по какому он может устанавливать соединение. Обычная: Цитата $ForceMove [Новый_адрес] nmdc expansion by gif-t: Цитата $FOM$[протокол]$[тип редиректа]$[IPv4]$[Порт_v4]$[IPv6]$[Порт_v6]| Временный редирект на NMDC $FOM$dchub$307$192.168.34.64$422$2001:470:26:1ef::1$645| Перманентный редирект на ADC, клиент меняет запись у себя в фаворитах, если такая имеется. $FOM$adc$301$192.168.34.64$422$2001:470:26:1ef::1$645| Уточнения:
$BotINFO / $HubINFO (описние $BotINFO и $HubINFO) Тут впринципе модификация не требуется, т.к. адрес заполняется вручную администраторорм хаба/ администратором бота. Пуска IPv6 адрес пишется в квадратных скобках. Это конечно усложняет функцию обработки... но несильно, сейчас сам набросал её (вышло +14 строк) Если IPv6 адрес идет после всех других адресов, то сохраняется совместимость со старыми $Supports Добавляем в команду GIFTEXT для идентификации хабов и клиентов, поддерживающих expansion by gif-t -------------------------------------------------------------------------------------------------------------------------------------------- Как видите, 1) Длина команд сильно укоротилась за счет использования трехбайтовых ключей и за счет вынос адресов в команду $UIP 2) Команды очень легко разобрать, т.к. разделитель элементов всегда один - знак $ (в старых командах разделителей много - пробел, двоеточие, знак "$", знак "?"). В адресе IPv6 используется двоеточие для разделения блоков и скобки для отделения порта, т.к. он отделяется тоже двоеточием, - в моём предложении вообще не надо использовать квадратные скобки для разделения ipv6 адреса от порта! В обшем для обработки таких команд выйдет функция минимального размера, максимальной простоты и быстродействия. 3) Предложенная схема абсолютно совместима со старыми (текущими) клиентами. Т.к. старым клиентам отсылаются команды старого типа. В схеме, предложенной Setuper'ом, данные впихиваются в структуру старых команд. Таким образом получаем в его схеме
В моей схеме
Клиент при коннекте через саппортс сообщает хабу о поддержке модифицированных команд GIFTEXT. Отсылает ему эти команды и команды старого типа (не уверен что это правильно, т.к. на стороне хаба по новой команде на мой взгляд очень просто сформировать команду старого типа, но впринципе если уж тк проще, то пускай так и будет). Хаб без всякой нагрузки отсылает без изменения всем клиентам команды того типа, который они поддерживают (старым - старого, новым - нового). Вот и весь принцип... |
|
|
4.2.2012, 17:58
Сообщение
#22
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
|
|
|
4.2.2012, 18:01
Сообщение
#23
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
Нет, замена не происходит. Клиент отсылает хабу новую и старую. Хотя я против этого... В общем хабу не нужно формировать старую, он просто отсылает старую старым клиентам, новую новым. Вот и всё. а, тогда всё вообще элементарно! пусть клиент посылает команды $ConnectToMe и $Search в старом виде но два раза - с v4 и v6 адресами. а там уже что-то как-то законектится и поищется ))) |
|
|
4.2.2012, 18:08
Сообщение
#24
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Дак в DC то сейчас для установки соединения используется один порт, который выставляется в том же флайлинке в настройках соединеия. И только он и нужен чтобы начать скачивание, т.к. у многих только он и открыт в роутере. И при скачивании в $ConnectToMe и $RevConnectToMe используется именно он, этот единственный порт.
Чем вам эта схема не угодила? Вы считаете нужно наоткрывать кучу портов и в каждом коннекте указывать новый? Почитайте еще раз пожалуйста http://mydc.ru/topic5172.html#entry42424, в данных командах принципы никакие не меняются, просто изменена структура команд для передачи ipv6 адреса дополнительно. И передача адресов и портов вынесена в отдельную команду, чтобы они не создавали лишний трафик в других, часто повторяющихся командах. |
|
|
4.2.2012, 18:10
Сообщение
#25
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Согласен, возможно написал бред, но отсылая порт 1 раз, ты снижаешь функциональность, которая заложена первоначально в протокол.
|
|
|
4.2.2012, 18:11
Сообщение
#26
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
|
|
|
4.2.2012, 18:15
Сообщение
#27
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Setuper, ну пока используется один порт... хотя я Павлу Пименову предлагал для актиного поиска использовать несколько UDP портов, чтобы снизить перемешивание результатов поисков.
НО в любом случая я специально предусмотрел "хвосты", чтобы можно было добавить что угодно, вплодь до еще множества портов, когда это понадобится. В старых командах кстати добавление портов не предусмотрено. |
|
|
4.2.2012, 18:17
Сообщение
#28
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
|
|
|
4.2.2012, 18:18
Сообщение
#29
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Все же придерживаюсь моей точки зрения: использование для соединения старых команд как с ipv4, так и с ipv6, определяя тип ip противоположной стороны по команде $UserIP. А при активном поиске отправлять сразу 2 команды.
И не городить огород! |
|
|
4.2.2012, 18:28
Сообщение
#30
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
Все же придерживаюсь моей точки зрения: использование для соединения старых команд как с ipv4, так и с ipv6, определяя тип ip противоположной стороны по команде $UserIP. можно. только UserIP немного излишняя. нужно только знать, какие протоколы поддерживает пир. помог бы какой-нибудь флажок типа "бомба", но флажки, увы, уже все разобраны (можно у грея отхапать флажки М/Ж, но тогда будет неразбериха). можно в тег признак в-общем, админы хабов обычно не выдают список IP не потому, что экономят трафик, а потому, что мнят себя царьками, что только они видят полный список IP. принудительное раскрытие IP снизит популярность хаба. опять же, не решается вопрос передачи двух адресов сразу. если сделать только флажки (умеет ли клиент v4 и v6), задача $ConnectToMe решается. |
|
|
4.2.2012, 18:28
Сообщение
#31
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Старые
$UserIP, $ConnectToMe, $RevConnectToMe и $Search Новые $UIP, $CTM и $SCH. Setuper, я не понимаю, что именно вас пугает? У вас функции для обработки старых команд с IPv6 адресом внутри выйдут гораздо больше, чем для предложенных мной. В общем я создал вам дополнение протокола, не вызывающее конфликтов, легкое в обработке, снижающее трафик и повышающее функциональность (благодаря возможности одновременного файлообмена и по ipv4 и по ipv6) Вы предложили свой вариант, гораздо более сложный в обработке, вызывающий конфликты у старых клиентов (потому как они просто непонятно как будут вынимать этот ipv6 адрес), увеличивающий трафик чуть ли не в два раза. Выбирайте. AMD, насчет портов, не проблема, сейчас могу вписать их. Порт будет отправляться в командах, если он отличный от указанного в $UIP. |
|
|
4.2.2012, 18:37
Сообщение
#32
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
AMD, Можно и в тэг. Например:
Код <FlylinkDC++ V:r500,M:A,H:1/1/1,S:10,C:4/6> <FlylinkDC++ V:r500,M:A,H:1/1/1,S:10,C:4> <FlylinkDC++ V:r500,M:A,H:1/1/1,S:10,C:6> В любом случае от хаба ничего не нужно. Все изменения со стороны клиента. gif-t, меня пугает навороченность, которая выглядит не продуманной. Не знаю что на это всё ответят разработчики клиентов, но думаю им также покажется это всё черезчур навороченным. |
|
|
4.2.2012, 18:44
Сообщение
#33
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Где навороченность? Навороченность - это ADC протокол.
У меня просто 3 команды с простой структурой для обработки. Яж не предлагаю устанавливать 2 соединения с хабом, слать всякие ключи, генерировать ID и т.п. Всё очень просто, вы наверно полностью не вникли... Я сделал на основе старых всего 3 команды и удалил ip:port из всех, кроме одной - $UIP Никакой навороченности нет... |
|
|
4.2.2012, 18:47
Сообщение
#34
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
В любом случае от хаба ничего не нужно. Все изменения со стороны клиента. от хаба только отключить проверку адреса в команде, если не заморачиваться со схемой подтверждения коннекта по второму протоколу. Где навороченность? Навороченность - это ADC протокол. У меня просто 3 команды с простой структурой для обработки. Яж не предлагаю устанавливать 2 соединения с хабом, слать всякие ключи, генерировать ID и т.п. Всё очень просто, вы наверно полностью не вникли... ну вроде RusHub и FlyLink - опенсорс. можешь проверить свою гипотезу о простоте изменений ))) Яж не предлагаю устанавливать 2 соединения с хабом, слать всякие ключи, генерировать ID и т.п. но так ты и не решаешь проблему подтверждения второго ip, позволяя проводить махинации, используя хаб для DDoS |
|
|
4.2.2012, 18:49
Сообщение
#35
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Ну проверка ip в русхабе отключается установкой в конфиге параметров bCheckCTMIp и bCheckSearchIp в 0.
Правда в текущей версии русхаба (2.3.8) существует баг с соединением по ipv6, но в следующей версии это уже будет исправлено (он уже исправлен на svn). |
|
|
4.2.2012, 18:49
Сообщение
#36
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Ну в флайлинк я не полезу
А в своем клиенте сделаю. Мне всего-то нужно добавить еще 3 функции для обработки этих 3-х команд и 3 для генерации. Т.к., повторяюсь, структура очень проста - всего один разделить $, эти функции получатся минимальны по размеру. Для вашего решения я уже написал функцию вынимания ipv6 адреса и search запроса (там проблема что и у блоков в адресе и у порта и адреса - разделитель двоеточие. Функция получилась очень корявой... а если учитывать что вы планируете передавать два адреса сразу, выйдет очень неаккуратный и кривой код. И вообще всё это теряет всякий смысл, зачем разбирать старые кривые неудобные команды, если можно сделать новые? Какраз такие, какие предложил я! Оставлять для IPv6 старые команды вообще бессмысленно, т.к. клиенты, которые существуют сейчас, их всеравно не смогут разобрать, а новым клиентам вы бросаете палки в колеса. Т.ч. взвесте всё еще раз, прочитайте http://mydc.ru/topic5172.html#entry42424 еще несколько раз и воспользуйтесь здравой логикой, правильное решение только одно! |
|
|
4.2.2012, 19:02
Сообщение
#37
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Ты лучше спроси у разработчиков клиентов что они об этом думают?
|
|
|
4.2.2012, 19:04
Сообщение
#38
|
|
Местная ТехПоддержка Группа: Администраторы Сообщений: 1 875 Регистрация: 18.7.2008 Из: Моск. Обл, г. королев, район Болшево Пользователь №: 221 Спасибо сказали: 220 раз |
Цитата А в своем клиенте сделаю. Это в каком же? |
|
|
4.2.2012, 19:06
Сообщение
#39
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
одного не понимаю: зачем делать новый хаб на старом протоколе?
поддержка супер-навороченных старых хабов - понятна. но в новом... пользователям протокол без разницы, а админам и программерам ADC удобнее. |
|
|
4.2.2012, 19:13
Сообщение
#40
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Setuper, попробую их сейчас привлечь сюда.
mariner, пишу свой клиент, полностью с нуля ) это будет долгая история AMD, я честно не знаю. Мне лично ADC не нравится, я не согласен с некоторыми его положениями. И если посмотреть статистику, со мной солидарны очень многие, adc хабов очень мало. Все крупные хабы остаются на NMDC, поэтому его стоит развивать. Setuper, а можно где-нибудь посмотреть лог присоединения к ADC хабу? Сейчас решил быстро накатать код, посмотреть механизм, но не нашел описание функции hash(PID) == CID... |
|
|
4.2.2012, 23:24
Сообщение
#41
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
не нашел описание функции hash(PID) == CID это обычный TTH 39-символьный PID декодируется в 24 байта двоичных данных (алгоритмом Base32). затем считаем TTH, как если бы эти 24 байта были записаны в файл. |
|
|
Похожие темы
|
Сейчас: 23.12.2024, 9:46 |