Протокол IPv6 в протоколе NMDC, Спецификация и тестирование IPv6 в NMDC |
Здравствуйте, гость ( Вход | Регистрация )
Протокол IPv6 в протоколе NMDC, Спецификация и тестирование IPv6 в NMDC |
4.2.2012, 0:12
Сообщение
#81
|
|
Участник Группа: Пользователи Сообщений: 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. Отсылает ему эти команды и команды старого типа (не уверен что это правильно, т.к. на стороне хаба по новой команде на мой взгляд очень просто сформировать команду старого типа, но впринципе если уж тк проще, то пускай так и будет). Хаб без всякой нагрузки отсылает без изменения всем клиентам команды того типа, который они поддерживают (старым - старого, новым - нового). Вот и весь принцип... |
|
|
10.2.2012, 20:00
Сообщение
#82
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Цитата Заголовок Host ничего не говорит? Эмм, а можете поподробнее?
|
|
|
10.2.2012, 20:04
Сообщение
#83
|
|
Site Reliability Engineer Группа: Модераторы Сообщений: 1 772 Регистрация: 27.6.2009 Из: Чувашия, г. Чебоксары Пользователь №: 3 719 Спасибо сказали: 479 раз |
Подробней в RFC.
зы. |
|
|
10.2.2012, 20:09
Сообщение
#84
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Вы можете сказать своими словами? Зачем в маны сразу посылать? Типо я что-то там надумал, а что именно - ищите и разбирайтесь сами!
Я помню что браузер устанавливает tcp соединени и передает домен..., далее вебсервер решает как ему отвечать. Эта схема позволяет держать на одном ip множество сайтов... не понимаю как я это связано с обсуждаемой нами проблемой? В общем пишите прямо! |
|
|
10.2.2012, 20:19
Сообщение
#85
|
|
Site Reliability Engineer Группа: Модераторы Сообщений: 1 772 Регистрация: 27.6.2009 Из: Чувашия, г. Чебоксары Пользователь №: 3 719 Спасибо сказали: 479 раз |
Либо я не понял вашего поста, либо вы просто быстро забываете, что пишите. Прочитаем пост http://mydc.ru/topic5172.html?view=findpost&p=42615
|
|
|
10.2.2012, 20:22
Сообщение
#86
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Я всё прекрасно помню, я не понимаю вашего поста. Вы сказали:
Цитата Заголовок Host ничего не говорит? тыпо вы чё, дураки, ответ же очевиден, слово Host! Вот я и прошу чтобы вы пояснили, что за хост вы имеете ввиду. А Вы сразу в маны посылаете... типо чтоб мы сами догадывали что вы имели ввиду. Повашему это правильное отношение к собеседникам? Пишите прямо что имееете ввиду, не надо юлить и запутывать разговор. Отвечу на ваш вопрос, заголовок Host ничего мне не говоритю |
|
|
10.2.2012, 20:25
Сообщение
#87
|
|
Site Reliability Engineer Группа: Модераторы Сообщений: 1 772 Регистрация: 27.6.2009 Из: Чувашия, г. Чебоксары Пользователь №: 3 719 Спасибо сказали: 479 раз |
Хорошо.
Цитата И я редко вижу такие сайты, в которых используется не 80 порт (для http само собой). Если администратору сайта нужен второй, он делает бесплатно dns третьего уровня и собачит сайт на него. Думаю администраторам хабов пора практиковать такую же схему - один DNS - один хаб. Каким образом, если в HTTP за определение запрашиваемого ресурса отвечает заголовок Host, когда в NMDC/ADC нет ничего подобного? |
|
|
10.2.2012, 20:32
Сообщение
#88
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Saymon21, эмм не вижу проблемы.
Давайте продумаем по порядку, так проще всего:
На каком шаге Вы видите возможность возникновения ошибки/проблемы? Если администратор хачет поднять два хаба, то он может сделать так: hub1.mydns.ru hub2.mydns.ru:412 и т.д. Или назначить каждому свой ip и оставить у каждого стандартный порт |
|
|
10.2.2012, 20:39
Сообщение
#89
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Может уже хватит оффтопить?
|
|
|
10.2.2012, 20:39
Сообщение
#90
|
|
Site Reliability Engineer Группа: Модераторы Сообщений: 1 772 Регистрация: 27.6.2009 Из: Чувашия, г. Чебоксары Пользователь №: 3 719 Спасибо сказали: 479 раз |
ADC и NMDC - это не один и тот же хаб. В любом случае, пользователь должен будет переписать в клиенте адрес хаба с dchub:// на adc:// или adcs://.
Без этого никак. Для некоторых юзеров уделить пару сек. времени и переписать это вызовет кучу проблем. Странно, что вы этого не понимаете. Во вторых, всётаки не понятно, как вы собрались делать два (или больше хабов) на одном айпи и порту, но разных доменах. зы. Хватит редактировать посты уже постоянно! Говорили уже ведь! Сообщение отредактировал Saymon21 - 10.2.2012, 20:41 |
|
|
10.2.2012, 21:15
Сообщение
#91
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Saymon21, я не понимаю вас, мы ведь говорим про редирект.
Редирект, это команда, отправляемая хабом и сообщающая клиенту адрес другого хаба, к которому ему нужно присоединиться. На NMDC хабе, перенаправляющем на ADC она выглядит так: Цитата $ForceMove adc://mydns.ru| Где вы здесь видите проблемы? Эта схема может работать постоянно, главное NMDC хаб не вырубать. А потом IRainman еще предложил перманентный редирект Setuper, пардон, больше не буду |
|
|
11.2.2012, 11:55
Сообщение
#92
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
Сделали редирект, домен вроде тот-же, но ни флай, ни стронг, ни другие клиенты не определили этот хаб как тот же. Более того все клиенты считают что эти варианты: это всё разными хабами грелка кстати запилил похожую фичу с полгода назад: 0.50-x64 (25.08.2011) Поиск по открытым хабам при открытии dchub: или adc: ссылки. Если хаб уже открыт с другим url, но тем же ip+port, новое окно не открывается (OCTAGRAM) Либо я не понял вашего поста, либо вы просто быстро забываете, что пишите. вы пытаетесь зацепиться за невежество оппонента и послать его на RFC (что конечно правильно). одна фактическая ошибка - и дальше, как в математическом доказательстве, вы всё последующее считаете несостоятельным. но лучше попытаться расшифровать, что хотел сказать gift. я так понял, он предлагает сделать доверенные зоны. при переходе на другой хаб без смены доменного имени клиент может передать те же логин/пароль, с какого хаба его переадресовали, считая, что пароль не уйдёт левым людям это чисто клиентская заморока. какая-то логика в ней есть, но хаб не может угадать, какой домен был в ссылке, с которой пришёл клиент и выдать редиректную ссылку, содержащую тот же домен. поэтому решение недостаточно надёжное, чтобы бросаться реализовывать его в клиенте. кстати, в ADC есть referer |
|
|
11.2.2012, 12:38
Сообщение
#93
|
|
Site Reliability Engineer Группа: Модераторы Сообщений: 1 772 Регистрация: 27.6.2009 Из: Чувашия, г. Чебоксары Пользователь №: 3 719 Спасибо сказали: 479 раз |
[offtop]
Хех. У нас вот только вчера на работе говорилось, мол если ехать куда далеко и долго, бывает полезно перед поездкой распечатать какой нить RFC и читать в дороге... Refer в ADC, ну да, знаем. Кстати вот, и в nmdc есть http://mydc.ru/topic5095.html?view=findpost&p=41616 [/offtop] |
|
|
12.2.2012, 18:23
Сообщение
#94
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Petr Kozelka (разработчик птохи):
Цитата Hi. I know about that and i don't understand to this disease of creating new protocol commands when it is not needed. ADC was created for that... Another thing that i don't understand how hub check IPv4 address of user who connected to hub with IPv6 to allow him to connect in active mode to IPv4 users. Without checking it can't be allowed, because then clients can be used for DDOS attacks. Anyway, it is too late because in PtokaX and CzDC IPv6 with IPV4 check and connections of IPv6 users to IPv4 users is already working for few months. Protocol extension is very simple and using already existing protocol commands. Documentation is in PtokaX wiki CzDC with IPv6 support PtokaX with IPv6 support Testing hub running on IPv6 dchub://ipv6-test.czdc.org:4861 Честно говоря не понимаю, как можно создать ддост отаку по TCP в DC...? Я уже несколько раз описывал что с файлообменом никаких проблем нет, DOS отаку не организовать. Проблема только с UDP и соответственно если ip не подтвержден - то блокировать нужно только UDP, т.е. поиск. А возможность устаналивать TCP содинения нужно оставить т.к. по протоколу массовую TCP ддос отаку организовать не получится. Почему-то все заблуждаются на этот счет. Разрабы птохи пошли по банальному пути наименьшего сопротивления, впихнули IPv6 адреса в старые команды.... Таким образом, если я правильно понял, в итоге получаем ИХ схему:
В моей схеме:
Ну я думаю картина вполне ясна, моё предложение оказалось весьма запоздалым и уже не получится переубедить создателей птохи. Решайте что будете реализовывать, вериант птохи, мой или свой или все сразу или ничего. На ADC я советую не надеяться, админы хабов еще не скоро переселятся на него и переселят всех пользователей, даже под аргументом IPv6. Еще добавлю одну вещь: Цитата FlylinkDC++50,8% StrgDC++ 16,3% DC++ 7,1% ApexDC++ 3,3% GreylinkDC++ 2,2% SSQLite++ 1,2% PeLink 0,8% AvaLink 0,6% Это средняя популярность DC клиентов на хабах: Цитата С разработчиками флайлинка они обязаны согласовать своё решение. Если флайлинк не будет поддерживать их модификацию - собственно говоря в ней не будет особого смысла. |
|
|
12.2.2012, 18:27
Сообщение
#95
|
|
Наруто на аваторке Группа: Пользователи Сообщений: 2 606 Регистрация: 11.10.2008 Из: Харькова Пользователь №: 771 Спасибо сказали: 774 раза |
Цитата Разрабы птохи знали бы вы как этот "разраб птохи" относится к вашим "обзываниям" птоки / PtokaX - "птохой" |
|
|
12.2.2012, 18:35
Сообщение
#96
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Артём, я знаю, просто не звучит...
Я им кстате в письме пояснил что так некоторые русские называют их хаб Товарищь IRainman тож пишет птоха: http://mydc.ru/topic5172s60.html?p=42614#entry42614 ..... ADC. А на счёт птохи, надо им писать в первую очередь, если они введ птоха - это почти официальный перевод на русский слова ptokax |
|
|
12.2.2012, 19:10
Сообщение
#97
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Если разработчики флая поддержат их концепцию, то это значительно ухудшит ситуацию с распространением протокола ADC.
А так ещё есть шанс, что по мере получения ipv6 юзеры будут активнее юзать ADC. ADC протокол более продуманный, чем NMDC в части минимизации трафика. Кстати, отказ клиентов от их концепции может помочь им открыть глаза для перехода на ADC. |
|
|
12.2.2012, 19:11
Сообщение
#98
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Пока я не заметил поддержки их концепции со стороны флая...думаю сейчас IRainman отпишется
А куда писать насчет ADC, хочу предложить им добавить кое-что? |
|
|
12.2.2012, 21:06
Сообщение
#99
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
Если разработчики флая поддержат их концепцию, то это значительно ухудшит ситуацию с распространением протокола ADC. А так ещё есть шанс, что по мере получения ipv6 юзеры будут активнее юзать ADC. ADC протокол более продуманный, чем NMDC в части минимизации трафика. да, ADC-команда может содержать одновременно v4 и v6-адреса. без потери совместимости с существующими клиентами. но вопрос второго коннекта клиента к хабу для подтверждения адреса в ADC не решён. так что тут есть поле для велосипедостроения ))) |
|
|
13.2.2012, 0:36
Сообщение
#100
|
|
Начинающий Группа: Пользователи Сообщений: 25 Регистрация: 27.11.2009 Пользователь №: 5 183 Спасибо сказали: 1 раз |
Еще всетаки опционально могли бы сделать передачу TCP портов в INF и отключение команды RCM на хабе, т.к. не все админы хотят ограничивать некоторым пользователям файлообмен, и включение такой опции немного снизило бы трафик и нагрузку на ADC хабах, т.к. пассивные пользователи могли бы соединяться с активными напрямую, без отправки хабу RCM.
|
|
|
13.2.2012, 20:10
Сообщение
#101
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
Еще всетаки опционально могли бы сделать передачу TCP портов в INF и отключение команды RCM на хабе, т.к. не все админы хотят ограничивать некоторым пользователям файлообмен, и включение такой опции немного снизило бы трафик и нагрузку на ADC хабах, т.к. пассивные пользователи могли бы соединяться с активными напрямую, без отправки хабу RCM. не-мо-гли-бы ни-ког-да! что написано в референсном коде принятия соединения? Код // Try to guess where this came from... pair<string, string> i = expectedConnections.remove(aNick); if(i.second.empty()) { dcassert(i.first.empty()); dcdebug("Unknown incoming connection from %s\n", aNick.c_str()); putConnection(aSource); return; } это NMDC. ADC проверяется ещё и по токену, который прошёл через хаб. если хаб не предупредил, что сейчас будет соединение от юзера, оно просто дропается. конечно, если переделать все-все клиенты... но это фантастика. |
|
|
Похожие темы
|
Сейчас: 23.12.2024, 13:35 |