myDC.ru

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

 

> Протокол IPv6 в протоколе NMDC, Спецификация и тестирование IPv6 в NMDC

Теги
gif-t
сообщение 4.2.2012, 0:12
Сообщение #61


Участник
**

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




Да, как бы неочень получается, продолжим ту тему здесь? Т.к. та тема не в том разделе и я предлагаю серьезно обсужадть не только спецификацию, но и тестировать..?
Моё предложение не слать 2 команды, т.к. хабы и так генерят много трафика, а хорошенько подумать и использовать сложившуюся ситуацию себе наруку. Потому как расплата за ошибки, допущенные сейчас, в будущем может быть очень большая.
Т.к. только хаб знает какие к нему присоединены клиенты, я предлагаю все команды, в которых передается ipv6 адрес, дублировать (так сказать, раз уж так получилось, подкорректируем протокол).
В общем здесь я опишу как я вижу решение проблемы, а дальше жду ваших комментариев.

nmdc expansion by gif-t, with ipv6 support
Цель:
  1. Поддержка в протоколе NMDC IPv4 и IPv6 адресов одновременно.
  2. Уменьшение трафика за счет правильной структуры новых команд, передачи адресов и портов отдельно и один раз, уменьшения длины ключей команд.
  3. Упрощение обработки, за счет правильной структуры новых команд.
  4. Требование минимального вмешательства в NMDC. Заменяются только те команды, без модификации которых не возможно функционирование ipv6. Остальные команды не затрагиваются.
  5. Сохраняются разделитель NMDC: команд "|". Блоков "$".

Основные положения:
  1. Расширение разработано в первую очередь для того, чтобы использовать сложившуюся ситуацию себе на руку и не только внедрить IPv6 в NMDC, но и уменьшить проблемы трафика и сложности обработки стандартных команд NMDC. Поэтому были разработаны новые команды, гораздо короче и проще старых.
  2. Для новых клиентов старые команды заменяются на новые:
    $UserIP -> $UIP (передает ip адреса и порты всех пользователей всем пользователям)
    $RevConnectToMe -> $RCM. вообще если в $UIP отсылаются адреса и порты всех пользователей всем пользователям - активы и пассивы могут устанавливать соединения с активами сразу напрямую, и $RCM можно не использовать. Но если администратор не передает tcp порты в команде $UIP, т.е. хочет управлять пользователями и одним разрешать качать, другим запрещать, то используется эта команда. Например в ADC её оставили, решили что администратор хаба должен решать кому можно качать. Но если её убрать - то при установлении соединения клиент не информирует хаб и тем самым нагрузка на хаб снижается.
    $ConnectToMe -> $CTM (актив паросит пассива присоединиться к нему, т.е. инициализировать соединение)
    $Search -> $SCH.
  3. Поддержка данного расширения протокола NMDC отпределяется по GIFTEXT в команде Suports.
  4. В случае присоединения клиента с поддержкой данного расширения к хабу без поддержки данного расширения, клиент работает с ним старыми командами, без использования IPv6.
  5. В случае присоединения к хабу с поддержкой данного расширения, новые клиенты отправляют на хаб сразу две команды - старого и нового типа. Старые клиенты - только старого соответственно.
  6. Хаб принимает команды старого и нового типа и рассылает команды старого типа клиентам без поддержки GIFTEXT, и новые клиентам с поддержкой GIFTEXT.
  7. В командах старого типа используется только IPv4. Таким образом старые клиенты не почуствуют какие либо неудобства.
  8. Для избежания доса, хаб перед отправкой (или при получении) заменяет в $UIP UDP порт неподтвержденного IP адреса на символ нижний прочерк: "_". Таким образом клиенты знают какой ip является подтвержденным и обязаны слать ответ только на него. (Есть еще вариант, для подтверждения второго IP адреса, с установкой по второму IP отдельного соединения с хабом. Вроде как этот вариант уже реализовали в птохе.)
  9. TCP порты обоих IP адресов передаются без изменения, таким образом клиенты сами могут выбирать протокол IPv4 или IPv6, по которому они будут организовывать файлообмен.(Т.е. ограничивается протоколом ipv6/ipv4 только поиск, скачивание - нет. И то если второй ip адрес не подтверждается установкой второго соединения с хабом)


$RevConnectToMe - команда, которую пассивный пользователь отправляет чтобы попросить другого пользователя попросить его инициировать с ним соединение, заменяются одной $RCM. Не используется клиентами на хабах, где администратор пропускает TCP порты в команде UIP. и (описние $RevConnectToMe)
Обычная:
Цитата
$RevConnectToMe [Ник1] [Ник2]|

nmdc expansion by gif-t:
Цитата
$RCM$[Ник_получателя]$[Ник_отправителя]|
Пример:
$RCM$Вася$Петя|

Уточнения:
  1. Как видете, команда предельно проста и коротка.
  2. СПОРНО Команды $RCM и $RevConnectToMe отправляются клиентом хабу вместе. Далее хаб сам выбирает каким клиентам какую рассылать. Модифицировать команду на стороне хаба не нужно. В плане трафика - это входящий для хаба трафик, который не представляет проблем. Или можно передавать только новую, а старую хаб будет генерировать сам...
  3. IP адреса передаются хабом при присоединении пользователя командой $UIP. Клиент сам решает по какому протоколу устаналвиать соединение. Или перебирает сначала ipv4, потом ipv6.
  4. Пометка - надо обязательно учесть недавние дополнения.




$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$Вася$Петя|

Уточнения:
  1. Как видете, команда предельно проста и коротка. Гораздо короче $ConnectToMe.
  2. СПОРНО Команды $CTM и $ConnectToMe отправляются клиентом хабу вместе. Далее хаб сам выбирает каким клиентам какую рассылать. Модифицировать команду на стороне хаба не нужно. В плане трафика - это входящий для хаба трафик, который не представляет проблем.
  3. IP адреса передаются хабом при присоединении пользователя командой $UIP. Клиент сам решает по какому протоколу устаналвиать соединение. Или перебирает сначала ipv4, потом ipv6.
  4. В $CTM клиент заполняет только те порты, ip адреса соответствующие которым у него есть.
  5. Пометка - надо обязательно учесть недавние дополнения.


Активный клиент (способный принимать входящие соединения) посылает данную команду на хаб для того, чтобы попросить пользователя [Ник_получателя] инициализировать соединение с ним (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|

Уточнения:
  1. Если строка поиска - текстовый, а не TTH запрос, и содержет несколько слов, разделенных пробелами, на месте пробела ставится знак пробела, а не "$", как это было непонятно зачем сделано в старой команде $Search.
  2. IP адреса и UDP порты передаются хабом при присоединении пользователя командой $UIP, описанной ниже.
  3. На линкованых хабах команда работает как $MultiSearch???
  4. СПОРНО Команды $SCH и $Search отправляются клиентом хабу вместе. Далее хаб сам выбиарет каким клиентам какую рассылать. Модифицировать команду на стороне хаба не нужно. В плане трафика - это входящий для хаба трафик, который не представляет проблем.


$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|

Уточнения:
  1. Список $UIP всех пользователей отправляется хабом пользователю сразу после его присоединения и отправки ему списка $MyINFO.
  2. $UIP отправляется обязательно после $MyINFO.
  3. Администратор хаба сам решает, будут ли в данной команде передаваться TCP порты. Если будут - то команда $RCM не должна использоваться клиентами. Они должны сразу устанавливать соединение с нужными им пользователями. В случае если TCP порты в $UIP администратор не передает, клиенты должны использовать команду $RCM для получения TCP портов.
  4. Команда отправляется один раз при входе и каждый раз при изменении портов пользователя. Таким образом обеспечивается экономия трафика. В таких командах как $SCH и $CTM ip адрес не передается. В $Search, к примеру, ip адрес передается при каждом поисковом запросе. Команда $Search на большинстве хабов является основным источником трафика.
  5. Отсутствующий порт/адрес заполняется символом прочерк "-", чтобы не повторялся разделитель "$$", разделяющий блоки ников.
  6. Т.к. передается два IP адреса, а проверяется только один - возможна организация UDP доса любого IP адреса ответами на поисковый запрос (соответственно только при поиске). Для избежания этого, ответы отсылаются клиентами только на IPv4 или IPv6 по которому клиент присоединен к хабу. После получения от клиенты данной команды, хаб у непроверенного ip адреса (противоположного относительно того, по которому он присоединен к хабу) UDP порт заменяет на знак "_" нижний прочерк и отсылает её всем пользователям. Таким образом хабу не нужно беспокоиться о проблеме доса, клиенты, отвечающие на поисковый запрос, знают какой IP адрес подвержден и будут слать ответ только на него.

    Также есть второй вариант - http://mydc.ru/topic5172.html?view=findpost&p=42452 - клиент должен устанавливать второе соединение с хабом и подтверждать второй ip адрес. Тогда в $UIP можно передавать оба UDP порта, поиск будет абсолютно полным и пользователи сразу с двумя ip адресами (ipv4 и ipv6) будут получать ответы на поисковый запрос по обоим (соответственно с ipv4 и ipv6 пользователей), т.е. от абсолютно всех пользователей хаба. Недостаток - это значительно усложняет алгоритм.

    В случае скачивания клиентам известны оба ip адреса и они могут организовать прямой файлообмен по IPv6 или IPv4 как им угодно.
  7. IPv6 адрес без квадратных скобок спереди и сзади!
  8. Если какого-то IP адреса нет, вместо него передается символ прочерк "-" для безопасности, чтобы не повторялся разделитель $$
  9. Если передается TCP порты пользователя, клиент при необходимости может сразу связываться с ним напрямую, не беспокоя хаб командой $RCM (экономия трафика).
  10. Два символа $$ - открывающий разделитель для нового блока. Т.е. после блока он не ставится. Это значит что команда не может закончиться на "$$|"


$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|

Уточнения:
  1. Хаб сам выбирает кому отправлять $FOM, а кому $ForceMove. Клиенты без поддержки $FOM, а значит и возможно IPv6, или без IPv6 адреса, в случае если хаб перенаправляет только на IPv6, будут потеряны, т.к. они не смогут установить соединение. Поэтому в $ForceMove рекомендуется передавать только ipv4 адрес.


$BotINFO / $HubINFO (описние $BotINFO и $HubINFO)
Тут впринципе модификация не требуется, т.к. адрес заполняется вручную администраторорм хаба/ администратором бота.
Пуска IPv6 адрес пишется в квадратных скобках. Это конечно усложняет функцию обработки... но несильно, сейчас сам набросал её (вышло +14 строк)
Если IPv6 адрес идет после всех других адресов, то сохраняется совместимость со старыми клиентами хаблистами (но теряется порт). Но лучше вместо ip адреса использовать IPv6 dns. В общем хаблисты разберутся - эти команды только для них, не для клиентов или хабов.

$Supports
Добавляем в команду GIFTEXT для идентификации хабов и клиентов, поддерживающих expansion by gif-t big_smile.gif

--------------------------------------------------------------------------------------------------------------------------------------------
Как видите,
1) Длина команд сильно укоротилась за счет использования трехбайтовых ключей и за счет вынос адресов в команду $UIP
2) Команды очень легко разобрать, т.к. разделитель элементов всегда один - знак $ (в старых командах разделителей много - пробел, двоеточие, знак "$", знак "?").
В адресе IPv6 используется двоеточие для разделения блоков и скобки для отделения порта, т.к. он отделяется тоже двоеточием, - в моём предложении вообще не надо использовать квадратные скобки для разделения ipv6 адреса от порта! В обшем для обработки таких команд выйдет функция минимального размера, максимальной простоты и быстродействия.
3) Предложенная схема абсолютно совместима со старыми (текущими) клиентами. Т.к. старым клиентам отсылаются команды старого типа. В схеме, предложенной Setuper'ом, данные впихиваются в структуру старых команд. Таким образом получаем в его схеме
  • Старые клиенты пытаются обработать такие команды и у них ничего не выходит или выходит непонятно что (вот будет круто если некоторые будут падать от этого )) )
  • Новые клиенты обрабатывают их сложными функциями, с большей нагрузкой, но корректно
  • Старые длинные команды отправляются дважды, сначала с ipv4, потом с ipv6. Это увеличивает трафик почти в 2 раза...
  • Т.к. они отсылаются подряд, сначала с ipv4, потом с ipv6, новому клиенту нужно помнить содержмиое нескольких команд, чтобы не реагировать дважды... неочень удобно. Если запоминать слишком много - то некоторые уникальные новые запросыф могут быть отсеяны, если мало - на некоторые клиент будет отвечать два раза. На больших хабах поисковых запросов валится очень очень много, от разных пользователей - там буфер надо большой. На маленьких - наоборот ищут одни и теже пользователи, буфер надо маленький.
    Если клиент предпочитает ipv6, то при получении ipv4 ему нужно одождать некоторое время, вдруг придет ipv6... Конечно это исключительная ситуация, но всеже вцелом проблема связывания этих двух команд существует.

В моей схеме
  • Старые клиенты должны получать команды старого типа и соответственно они будут их корректно обрабатывать. При получении команды нового типа (а такого происходить вообще-то не должно) они их просто проигнорируют. По этому пункту моя схема лучше.
  • Новые клиенты обрабатывают их легко и быстро, т.к. новые команды гораздо проще по структуре. По этому пункту моя схема тоже лучше.
  • Новые команды короче и клиенту в зависимости от поддержки отсылается либо старая длинная команда, либо новая короткая. Это приводит к сильному сокращению исходящего трафика хаба, особенно в будущем, когда большинство клиентом будет работать на командах нового типа. По этому пункту моя схема тоже лучше.
  • Команда отсылается одна и сразу в себе содержет все необходимые параметры. По этому пункту моя схема тоже лучше.

Клиент при коннекте через саппортс сообщает хабу о поддержке модифицированных команд GIFTEXT. Отсылает ему эти команды и команды старого типа (не уверен что это правильно, т.к. на стороне хаба по новой команде на мой взгляд очень просто сформировать команду старого типа, но впринципе если уж тк проще, то пускай так и будет). Хаб без всякой нагрузки отсылает без изменения всем клиентам команды того типа, который они поддерживают (старым - старого, новым - нового). Вот и весь принцип...


Спасибо сказали:
Go to the top of the page
+Quote Post
6 страниц V  « < 2 3 4 5 6 >  
Начать новую тему
Ответов
ShadoWx
сообщение 7.2.2012, 7:27
Сообщение #62


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

Группа: Пользователи
Сообщений: 216
Регистрация: 23.10.2008
Из: Саратов
Пользователь №: 865
Спасибо сказали: 60 раз




это все хорошо, но всегда есть большое, НО

я сам использовал adchpp более 6 месяцев, вполне приличный хаб, но пришлось потерять в пользователях около 300-400 человек, и вот в моих интересах чтобы была нормальная поддержка Ipv6 в nmdc.

И останется просто продолжать ждать того момента, когда большинство поймут что старые клиенты уже бесполезны...
Хотя если учесть как многие уже относятся к DC++, это уже маловероятно ...
Go to the top of the page
+Quote Post
Ksan
сообщение 7.2.2012, 15:39
Сообщение #63


Белый Волк
*********

Группа: Пользователи
Сообщений: 1 723
Регистрация: 11.9.2008
Из: г.Томск
Пользователь №: 516
Спасибо сказали: 657 раз




Цитата
когда большинство поймут что старые клиенты уже бесполезны..

ShadoWx, логика подсказывает, что если у большинства "старые", как ты это называешь, клиенты, то вряд ли они будут так считать big_smile.gif
Go to the top of the page
+Quote Post
gif-t
сообщение 7.2.2012, 17:34
Сообщение #64


Участник
**

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




Я про тоже, ADC хабов очень мало... (в dchublist.com всего штук 30, против 650 NMDC хабов)!!! Это главный аргумент.
Хотя ADC был анонсирован официально зарелизен в 2007 году (в декабре)! Это 4 года прошло! И всего 30 хабов!
IPv6 внедряется куда более большими темпами.
Тем не менее NMDC уже постепенно достигает своих пределов. Могу заявить что хабы, которые набориют по вечерам за 15 тыс - генерят трафика при значительном ограничении поиска на 600 и более мбит/с. И хорошо пока можно дальше резать поиск, MyINFO и т.д. и оставаться в пределах 1 гбит/с.
Но скоро на хабах будет 40 тыс пользователей, и для их удержания придется отключить поиск вообще. А после потребуется более 1 Гбит/с и сомневаюсь что у кого-то получится где-то дастать такой канал, а к ADC пользователи будут еще не готовы.. И даже если получится, существует также финансовая проблема. Согласитесь что только идиот будет заниматься подобной благотворительностью, ведь хабы не приносят дохода, в отличае от торрентов.
Именно по этому нужно отдалить дату упирания NMDC хабов в лимиты скорости, пока на замену не придет ADC, и воспользоваться моим предложением, сокращающим трафик NMDC хабов чуть ли не в 2 раза, когда к нему подключены клиенты с поддержкой.
Ну и одновременно нужно вести статистику клиентов с поддержкой ADC и в какой-то момент, когда их станет больше 95% - поставить на хабах редирект...
И тут тоже возникает проблема с "регистрацией пользователей", т.к. у многих пароли, записанные в фаворитах, идентифицируют хаб по ссылке, а не по адресу.
Т.е. пользователям придется переписывать fav, а в некоторых случаях восстанавливать пароль или даже перерегистрироваться.
ADC будет не скоро...
Go to the top of the page
+Quote Post
AMD
сообщение 7.2.2012, 20:09
Сообщение #65


Начинающий
*

Группа: Пользователи
Сообщений: 28
Регистрация: 3.7.2009
Пользователь №: 3 768
Спасибо сказали: 2 раза




Цитата(ShadoWx @ 7.2.2012, 8:27) *
в моих интересах чтобы была нормальная поддержка Ipv6 в nmdc.
И останется просто продолжать ждать того момента, когда большинство поймут что старые клиенты уже бесполезны...

несмотря на введение ipv6 на хабе, старые клиенты не смогут физически использовать его.
так что обновление клиентов - в первую очередь

а смигрировать юзеров не так сложно. не нужно закрывать старый порт, нужно делать редирект на adc
Go to the top of the page
+Quote Post
ShadoWx
сообщение 8.2.2012, 6:21
Сообщение #66


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

Группа: Пользователи
Сообщений: 216
Регистрация: 23.10.2008
Из: Саратов
Пользователь №: 865
Спасибо сказали: 60 раз




да смигрировать тем же xinetd или inetd сделать перенаправление ...я уже так делал, не хотелось бы народ терять =(
Go to the top of the page
+Quote Post
AMD
сообщение 8.2.2012, 20:39
Сообщение #67


Начинающий
*

Группа: Пользователи
Сообщений: 28
Регистрация: 3.7.2009
Пользователь №: 3 768
Спасибо сказали: 2 раза




Цитата(ShadoWx @ 8.2.2012, 7:21) *
да смигрировать тем же xinetd или inetd сделать перенаправление ...я уже так делал =(

честно - не понял, как это.
я говорил о редиректе на уровне протоколов NMDC/ADC, а не TCP
если направить юзеров NMDC-хаба на порт ADC-хаба, конечно ничего хорошего не получится
Go to the top of the page
+Quote Post
nail
сообщение 9.2.2012, 2:05
Сообщение #68


Начинающий
*

Группа: Пользователи
Сообщений: 25
Регистрация: 27.11.2009
Пользователь №: 5 183
Спасибо сказали: 1 раз




Ага, делали так. На NMDC все были зарегены, у всех клиент автоматически авторизовывался и пускало на хаб.
Сделали редирект, домен вроде тот-же, но ни флай, ни стронг, ни другие клиенты не определили этот хаб как тот же. Более того все клиенты считают что эти варианты:
Цитата

это всё разными хабами, и соответственно если прописан в фаворитах только dchub://mysite.ru, то зайдя на adc://mysite.ru - пользователю выведется "введите пароль", дц клиент и не подумает автоматически авторизовываться.
+ часть пользователей вообще не поддерживает ADC и не смогла зайти на хаб.
В итоге пришлось быстро возвращать всё на NMDC....
Единственное правильное решение какраз не вводить резко новый протокол, а постепенно совершенствовать старый, приводя его к идеальной форме и при этом сохраняя совместимость. А когда все будут готовы - отрубить совместимость со старым. Разрабы ADC поступили по своему - отказались от плавного перехода, и в результате имеем 30 ADC хабов.
Пока все не будут готовы к ADC, пока разрабы DC клиентов не профиксят багу с адресами, а зная темпы разработки тогоже флая я могу сказать что это будет нескоро, пока большая часть пользователей не перейдет на такие клиенты - NMDC будет работать.
Т.ч. делайте ipv6, им еще многие успеют попользоваться
Go to the top of the page
+Quote Post
Setuper
сообщение 9.2.2012, 8:48
Сообщение #69


RusHub team lead
**************

Группа: Модераторы
Сообщений: 4 030
Регистрация: 20.6.2008
Из: г. Королёв (Моск. обл.)
Пользователь №: 46
Спасибо сказали: 1708 раз




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

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


Спасибо сказали:
Go to the top of the page
+Quote Post
gif-t
сообщение 9.2.2012, 18:52
Сообщение #70


Участник
**

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




Гибридные хабы уже есть, на них подавляющее большинство сидит по NMDC
Go to the top of the page
+Quote Post
Saymon21
сообщение 9.2.2012, 19:00
Сообщение #71


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

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




gif-t, Это какие, в плане софт? Знаю только FlexHub.
Go to the top of the page
+Quote Post
gif-t
сообщение 9.2.2012, 19:32
Сообщение #72


Участник
**

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




Да, именно он. Я посидел на этом хабе, каждые 10 секунд бот упорно толдычил мне что с NMDC пользователей я качать не могу. А что мне делать, на это хабе почти 90% NMDC! Зашел по NMDC, сразу закачки и поиск пошел.
ADC на этом хабе оказался совершенно непрогрессивным и никакой плавности я не заметил, одни неудобства.
Т.е. если Вы, Setuper, предлагаете гибридный хаб, то вместе с ними предлагайте и гибридные DC клиенты, которые без неудобств будут работать на таких хабах.
В противном случае давайте введем 3 команды, которые я предложил во втором посте, сделаем плавно поддержку ipv6 в NMDC и оставим переход на ADC на лучшие времена... хотябы на тогда, когда у подавляющего большинства пользователей будут DC клиенты с полной поддержкой ADC и, как было сказано выше, рабочей определялкой адреса хаба. Пока таких пользователей не то что мало, а вообще нет. И переход на ADC сейчас будет сопровождаться большими неудобствами и потерями пользователей.
Go to the top of the page
+Quote Post
IRainman
сообщение 9.2.2012, 22:53
Сообщение #73


Начинающий
*

Группа: Пользователи
Сообщений: 16
Регистрация: 20.3.2009
Пользователь №: 2 666
Спасибо сказали: 2 раза




Нельзя делать поддержку IPv6 в NMDC! Объясню почему:

Надо сказать большой серой массе юзеров, что всё: NMDC устарел, протокол IPv6 он не поддерживает, и поддерживать не сможет. Обновляйте свои клиенты, и подключайтесь к adc версии хаба!
В общем действительно реальная задача это в первую очередь портирование скриптов на ADC хабы.

Для примера у меня сейчас запущены Ptokax и ADCH++ и оба работают на одном Экзекуторе из одной папки -это здорово. Всё благодаря мосту, но данная конструкция в боевых условиях (десятки тысяч пользователей) не тестировалсь, но я сомневаюсь что всё будет хорошо, у ADCH++ c высокими нагрузками и так, мягко сказано, почти никак big_smile.gif

p.s: Хватит уже тянуть кота за яйца - ему больно. Хватит писать новые расширения (зачёркнуто) костыли к NMDC протоколу, его похоронить давно пора. А IPv6 ныне последний способ перетащить всех без исключения юзеров на ADC. А если перехода не произойдёт хоронить надо будет не NMDC, а DC++ целиком.
Go to the top of the page
+Quote Post
nail
сообщение 10.2.2012, 2:32
Сообщение #74


Начинающий
*

Группа: Пользователи
Сообщений: 25
Регистрация: 27.11.2009
Пользователь №: 5 183
Спасибо сказали: 1 раз




IRainman, вы больно умный. Вот и говорите такое своим пользователям.
А я, и многие другие адекватные администраторы, так не хотят и не будут поступать.
Цитата
Хватит писать новые расширения костыли к NMDC протоколу, его похоронить давно пора.

Его не пора хоронить, это полностью рабочий, стабильный и годами отлаженный протокол, как на клиентах, так и на хабах, и успешно эксплуатируется по сей день, и его функционала хватает всем. И не надо называть расширения костылями! Правильное расширение - это ничто иное как развитие протокола.
А по вашим словам торрент - вообще не протокол, а сплошной костыль, т.к. сегодня он по сути состоит из одних расширений!
И поскольку NMDC будет лидирующим еще ниодин год, то поддержка ipv6 в нем обязательна!
И в данной теме спор идет не о вводе/не вводе, а о том, бездумно ли ввести (тогда это действительно можно будет назвать костылем), или пошевелить мозгами и ввести правильно, получив в придачу выгоду в других областях, например в трафике.

Кстати, разработчикам флая стоило бы заняться проблемой ADC, т.к. поддержку самого протокола добавили, но ничего не сделали, чтобы пересаживать пользователей на него. Вон Setuper молодец, пишет гибридный хаб, чтобы пользователи, готовые к переходу - переходили, а не готовые, оставались. Но чтобы эта схема работала безболезнено и для тех, и для других, нужна небольшая поддержка со стороны DC клиента, чтобы клиенты, работающие по разным протоколам, могли и взаимодействовали друг с другом. А именно качать друг с друга, отсылать результаты на поисковый запрос в формате соответствующего протокола и т.д. А всякие берюльки на свой клиент всегда успеете навешать.
Go to the top of the page
+Quote Post
IRainman
сообщение 10.2.2012, 15:08
Сообщение #75


Начинающий
*

Группа: Пользователи
Сообщений: 16
Регистрация: 20.3.2009
Пользователь №: 2 666
Спасибо сказали: 2 раза




nail, не путайте сладкое с мягким пожалуйста.

Цитата
чтобы пользователи, готовые к переходу - переходили, а не готовые, оставались.

Раз уж речь зашла про торренты, вспомните ситуацию когда у torrents.ru сменился домен на rutracker.org, вспомните также какие реальные проблемы в итоге эта дикая ситуация вызвала у пользователей, и ответьте на простой вопрос: какие пользователи и почему не готовы к переходу на ADC в DC++, и по каким причинам эта ситуация всё ещё возможна?

Вот кстати про пароль, имхо это единственная реальная проблема при переходе - простое и элегантное решение: давайте для команды редиректа добавим дополнительное поле, в котором будет указано что это постоянный редирект на новое место. Когда такая вариация команды приходит клиенту, клиент смотрит что адрес (протокол, сервер, порт) у него в избранном, и меняет его на новый. Всё, переход завершён хоть на ADC, хоть на новый домен, вообще никаких проблем для пользователя нет.

Всё же что описывается как улучшение и называется полным гибридным хабом в первую очередь является сильным архитектурным усложнением протокольных реализаций как на стороне клиента так и на стороне сервера, и в любом случае потребует обновления всего ПО у пользователей, также прошу задуматься какая это будет "печка" на сервере при десятках тысяч пользователей на хабе - ведь большую часть команд придётся конвертировать хабу.
Go to the top of the page
+Quote Post
mariner
сообщение 10.2.2012, 15:13
Сообщение #76


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

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




Цитата
Раз уж речь зашла про торренты, вспомните ситуацию когда у torrents.ru сменился домен на rutracker.org, вспомните также какие реальные проблемы в итоге эта дикая ситуация вызвала у пользователей

Никаких проблем не было. Все ведь просто
Код
sed -i 's/torrents.ru/rutracker.org/g' /srv/torrent/.config/cache/*


Цитата
протокольных реализаций как на стороне клиента так и на стороне сервера

Когда ж вы, блин, читать то начнете.

Сетапер предлагает сделать чтобы один хаб мог открытьвать 2 порта. Один с nmdc, другой с adc. Все! Ничего в клиенте менять не надо


Спасибо сказали:
Go to the top of the page
+Quote Post
IRainman
сообщение 10.2.2012, 16:03
Сообщение #77


Начинающий
*

Группа: Пользователи
Сообщений: 16
Регистрация: 20.3.2009
Пользователь №: 2 666
Спасибо сказали: 2 раза




mariner
Цитата
Никаких проблем не было. Все ведь просто

Именно, я как раз о том же.

Цитата
Когда ж вы, блин, читать то начнете.

Сетапер предлагает сделать чтобы один хаб мог открытьвать 2 порта. Один с nmdc, другой с adc. Все! Ничего в клиенте менять не надо


Я читал, и с концепцией Setuperа полностью согласен. big_smile.gif
Мой ответ предназначается только для nail потому что он старательно предлагает разнообразные костыли для меж-протокольного взаимодействия между клиентами и гибридным хабом.


Спасибо сказали:
Go to the top of the page
+Quote Post
gif-t
сообщение 10.2.2012, 18:59
Сообщение #78


Участник
**

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




IRainman, раз уж вы сюда зашли, сделайте в флае такое расширение, чтобы перманентный редирект действительно перезаписывал FAV у пользователя.
И поправьте обработку адреса хаба, чтобы флай не тупо идентифицировал по ссылке, со всеми её слешами, портами и приписками, а выдирал DNS адрес и использовал для идентификации только его. Тогда редиректить народ можно будет и без использования перманентного редиректа, если в пределах одного домена - флай автоматически авторизуется на ADC хабе после редиректа.

Насчет преобразования команд со стороны хаба - это простые операции, они не дают нагрузку.
В предложенном мной во втором посте дополнеии, хабу ничего преобразовывать не надо вообще. Если вводить ipv6 в NMDC - то моё дополнение будет самым правильным.
Впринципе решайте сами...я вижу что никому, кроме меня, моя идея не нравится, значит видимо действительно это не нужно. Но то, что вводится для подержки ipv6 в птохе - это действительно костыль, и вы вот сейчас отказались от продвижения моего варианта, а потом, когда в птохе окончательно введут свой ipv6 костыль, вам придется приспосабливаться, переписывать функции - обработчики и т.д. и вы поймете что надо было вводить дополнение gif-t'а когда он предлагал, тогдаб не было столько проблем и такой костыльности, и не проиграли бы в трафике и функциональности.
Go to the top of the page
+Quote Post
IRainman
сообщение 10.2.2012, 19:10
Сообщение #79


Начинающий
*

Группа: Пользователи
Сообщений: 16
Регистрация: 20.3.2009
Пользователь №: 2 666
Спасибо сказали: 2 раза




gif-t
на счёт слешей в конце ссылки вы полностью правы - это ошибка 100%, поправим, а вот если порты или протокол разный тут есть опасения что можно что то сломать, вдруг два разных хаба на одном сервере (домене) работают и как быть тогда?

p.s: пойду ишью запилю, а то что то расфлудился мая тут, и всё оффтоп по сути.

Цитата
В предложенном мной во втором посте дополнеии, хабу ничего преобразовывать не надо вообще. Если вводить ipv6 в NMDC - то моё дополнение будет самым правильным.

это факт - расширение правильное, я просто боюсь что отсутствие поддержки IPv6 это последнее средство которое может вразумить админов хаба к переходу на ADC. А на счёт птохи, надо им писать в первую очередь, если они введут ваше расширение это будет очень хорошо, потому что они с гарантией добьются его включения в новую версию NMDC протокола.


Спасибо сказали:
Go to the top of the page
+Quote Post
gif-t
сообщение 10.2.2012, 19:57
Сообщение #80


Участник
**

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




IRainman, надо просто сообразить. DNS для другого хаба администраторо ведь всегда может сделать другую.
У сайтов ведь DNS однозначно идентифицирует один определенный сайт. И браузеры сохраняют пароли именно по dns.
И я редко вижу такие сайты, в которых используется не 80 порт (для http само собой). Если администратору сайта нужен второй, он делает бесплатно dns третьего уровня и собачит сайт на него.
Думаю администраторам хабов пора практиковать такую же схему - один DNS - один хаб.
Пока я не придумал решения лучше.

Цитата
это факт - расширение правильное, я просто боюсь что отсутствие поддержки IPv6 это последнее средство которое может вразумить админов хаба к переходу на ADC. А на счёт птохи, надо им писать в первую очередь, если они введут ваше расширение это будет очень хорошо, потому что они с гарантией добьются его включения в новую версию NMDC протокола.


Я думал об этом, но практически единственное что я успеваю делать в перерывах между работой - написать здесь. И не могу похвастаться своим английским...
Хотя с другой сторону меня убивают такие варианты как отсылка старых команд два раза или то, что делают в птохе. Ну это явно неправильно...
Go to the top of the page
+Quote Post
Saymon21
сообщение 10.2.2012, 19:58
Сообщение #81


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

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




Заголовок Host ничего не говорит?
Go to the top of the page
+Quote Post

6 страниц V  « < 2 3 4 5 6 >
Ответить в данную темуНачать новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

Collapse

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

  Тема Ответов Автор Просмотров Последнее сообщение
No New Posts Topic has attachmentsПротокол
3 DaMaGeLaB 6 881 10.1.2016, 22:19 Посл. сообщение: Saymon21
No New Posts Слушает только IPv6?
PtokaX DC Hub 0.5.2.1
1 iTCenter 5 360 11.9.2015, 19:12 Посл. сообщение: alex82
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 Поиск в протоколе ADC
3 Crecee 8 540 4.7.2012, 0:14 Посл. сообщение: Crecee
No New Posts вопрос по NMDC.
.
6 Lamo 12 676 29.5.2012, 19:35 Посл. сообщение: Lamo
No New Posts NMDC Extensions
Расширения и новые команды NMDC протокола
10 Meloun 17 400 19.2.2012, 16:39 Посл. сообщение: gif-t
No New Posts Непонятки с пассивным и активным режимом пользователей в протоколе ADC
Как однозначно определить режим пользователей в протоколе ADC?
11 gif-t 14 175 19.2.2012, 4:51 Посл. сообщение: Delia
Moved Непонятки с пассивным и активным режимом пользователей в протоколе ADC
Как однозначно определить режим пользователей в протоколе ADC?
0 gif-t 0 18.2.2012, 19:42 Посл. сообщение: gif-t
No new Ipv6 Test Hub RusHub
40 CrazyKiller 30 385 8.2.2012, 0:08 Посл. сообщение: CrazyKiller
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

 



RSS Сейчас: 29.3.2024, 7:37