Версия для печати темы

Автор: gif-t 3.2.2012, 23:42

Собственно говоря продолжение темы с dchublist с уклоном в сторону программирования и RusHub'а.
Как я понял, IPv6 в RusHub'е частично уже поддерживается, но как, совершенно непонятно.
Давайте составим спецификацию (если её еще нет, а если есть... покритикуем?), т.к. в этой задаче есть много спорных моментов.
Приведу простой пример - поддержка сразу и ipv6 и ipv4 в поисковых запросах, или только ipv6 или ipv4? Первый вариант конечно лучше, но в его случае нужно отсылать сразу 2 адреса, что соответственно изменяет структуру команды search... в общем нужно обмозговать и наверно сделать команду search2, но с уклоном на простоту обработки (хотя search более менее нормально составлена...), хаб пускай разбирает и без изменения отсылает клиентам с поддержкой ipv6, а клиентам с ipv4 отправляет команду старого типа, если в search2 есть ipv4 адрес?
И также выкладываем адресочки ipv6 хабов для проверки работоспособности. Пока мне не попадался ниодин хаб, на котором мой клиент мог бы стабильно работать "сидеть" и слушать без разбора всё, что ему шлет хаб.

Автор: Setuper 3.2.2012, 23:54

http://mydc.ru/index.html?showtopic=5167&view=findpost&p=42402

Автор: gif-t 4.2.2012, 0:12

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

Цель:

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. и http://mydc.ru/topic915s20.html?p=6739#entry6739
Обычная:
nmdc expansion by gif-t:

Уточнения:

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

$ConnectToMe - команда, которую активный пользователь отправляет чтобы попросить другого пользователя инициировать с ним соединение, заменяются одной $CTM http://mydc.ru/topic915.html?p=6692#entry6692
Обычная:
nmdc expansion by gif-t:

Уточнения:

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

Активный клиент (способный принимать входящие соединения) посылает данную команду на хаб для того, чтобы попросить пользователя [Ник_получателя] инициализировать соединение с ним (IP адрес и иногда порт тому клиенту уже извествен благодаря $UIP).

$Search и $MultiSearch http://mydc.ru/topic915s20.html?p=6743#entry6743 http://mydc.ru/topic915s40.html?p=7334#entry7334

Обычная:
Нет деления структуры на активный и пассивный поиски
nmdc expansion by gif-t:
Уточнения:

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

$SR - ответ на поисковый запрос http://mydc.ru/topic915s20.html?p=6845#entry6845
Нужно проверить, но я думаю эта фукция будет работать с ipv6 без модификации.

$MultiSearch http://mydc.ru/topic915s40.html?p=7334#entry7334
Не знаю, она в ходу? Я просто не вижу в ней смысла. Хаб должен сам решать как и куда он пересылает поисковые запросы. Моё мнение - модификация команды не нужна. Сразу объявим $SCH как $MultiSearch на линкованых хабах.

$UserIP http://mydc.ru/topic915s20.html?p=6893#entry6893
Обычная:
nmdc expansion by gif-t:

Уточнения:

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 http://mydc.ru/topic915.html?p=6705#entry6705
Эту команду тоже стоит модифицировать, чтобы клиенту передавалось сразу два IP адреса, IPv6 и IPv4. Далее он сможет выбрать по какому он может устанавливать соединение.

Обычная:
nmdc expansion by gif-t:
Уточнения:

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

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

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

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

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

В моей схеме

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

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

Автор: Setuper 4.2.2012, 14:41

Во-первых, интересно что такое Gif-t ? Это оно: http://mydc.ru/r/?http://ru.wikipedia.org/wiki/GiFT ?

Во-вторых, описанное решение проблемы понравилось, но есть некоторые замечания/предложения:

1) Проблема с "хвостом". Возникает неоднозначность, когда порты равны, но есть хвост, и когда порты разные, но хвоста нету. Предлагаю разрешить эту неоднозначность, убрав этот хвост.

2) Все же предлагаю назвать новые команды в стиле ADC. Вместо $cm писать $CTM, а вместо $sh - $SCH.

3) В ADC протоколе к этому делу действительно подошли круче. Там ip адреса передаются в команде INF (аналог $MyINFO для NMDC). Действительно, зачем каждый раз отправлять ip адрес при поиске или при коннекте, когда проще отправить его 1 раз в команде INF, и клиенту известны все ip адреса всех пользователей хаба.

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

Кстати, еще нужно придумать название характеристики, которую нужно будет отсылать в команде $Supports.

Автор: gif-t 4.2.2012, 14:50

скорее gif-t - мой ник в сети ) Поэтому я назвал это дополнение протокола expansion by gif-t
1) Проблема с "хвостом". Я более точно поясню как это должно работать. Проблемы на самом деле нет.
2) Можно назвать и в стиле ADC. Вместо $cm писать $CTM, а вместо $sh - $SCH. Так будет проще не запутаться, но в итоге потеряем 1 байт на команду.
3) Да, надо так сделать, сейчас посмотрю как там
4) Это не проблема, именно модификацию легко уладить, сейчас опишу как.

Автор: Setuper 4.2.2012, 16:11

Лучше не модифицировать свои посты, а писать новые, так как приходится перечитывать по нескольку раз, кроме того, при модификации теряется старая версия написанного и сложно отследить логику

Автор: gif-t 4.2.2012, 16:22

Дописал.
Жду критику.

Автор: AMD 4.2.2012, 16:38

обычный dc++ хаб не принимает IP клиента, он смотрит с какого адреса произошло соединение с хабом.

посему, чтобы подтвердить не один адрес, а пару, клиент обязан создать два коннекта (4 и 6) к хабу и криптографическими методами доказать, что они от одного источника (по одной лишь паре адресов v4 и v6 технически невозможно установить, что они принадлежат одному клиенту)

соответственно, либо мы строго решаем вопрос аутентификации, либо сознательно на него забиваем, оставляя пространство для махинаций и ДоС-атак (например, Петя с адреса 22.33.44.55 подключается к хабу и говорит - Вася, коннектся на мой IPv6 - и подставяет адрес Миши. так он законнектил Васю с Мишей против их желания)

самое простое - юзер открывает две вкладки хаба (по разным адресам - v4 и v6). на одной вкладе - только юзеры v4, на другой - только v6. и ничего в протоколе менять не надо

Автор: gif-t 4.2.2012, 16:48

Нет, давайте не городить с двумы вкладками. Я действительно это не учел.
Надо сообразить чего мы теряем отказываясь от использования сразу двух ip адресов.
Получится что если есть 2 пользователя:
1) один ipv6 и ipv4, но так, как принимаем только один адрес - ipv4
2) второй ipv6
Они оба с ipv6 но взаимодействовать не смогут? Нехорошо...
Может быть стоит сделать 2 коннекта для подтверждения обоих адресов, а дальше один отбрасывать?
И надо посмотреть как в торренте. Лично я не хочу урезать функциональность протокола только потому что что-то там тяжело реализовать.

Автор: Setuper 4.2.2012, 16:49

Это уже не дополнение какое-то, а попытка переделать протокол и создать что-то наподобие уже созданного ADC протокола.
Очень сложно. Особенно механизм отправки сразу нескольких команд $INF, $CTM.

Наша ведь задача научиться узнавать ip адрес. Наверное логично смотреть в сторону уже существующих команд, дабы не усложнять. Предлагаю смотреть в сторону команды: http://mydc.ru/r/?http://wiki.mydc.ru/$UserIP

Автор: gif-t 4.2.2012, 17:03

Я описал $UserIP с ipv6 как http://mydc.ru/topic5172.html?gopid=42448#entry42424.
Для коннекта пользователей пускай клиенты используют оба адреса как им нравится. А в поиске - только один. Так?
Помоему нормальное решение... клиент при активном поиске указывает свой ipv6, а далее на него все шлют ответ, кто владеет ipv6 адресом. И также с ipv4.

Всмысле я уже сам путаюсь. Не указывает адрес, а он уже один известен и передается одинт раз в $UIP

Тогда команда принимает такую форму:
$UIP$$[Ник1]$[IPv4]$[Порт_TCP_ipv4]$[Порт_UDP_ipv4]$[IPv6]$[Порт_TCP_ipv6]$[Порт_UDP_ipv6]$[Хвост1]$[Хвост2]|
В $UIP передаем UDP только того адреса, по которому клиент соединен с хабом, т.к. он подтвержденный. При поиске соответственно клиенты будут слать UDP ответы только на один конкретный подтвержденный IPv4 или IPv6 адрес. А коннектиться смогут по обеми адресам по TCP.
Таким образом получаем защиту от доса, возможность качать по обоим адресам и искать по одному, по которому клиент подсоединен к хабу.

Я пометил это как на усмотрение администратора хаба. Не вижу в это проблем.
$UIP можно слать как $UserIP, один раз, при входе.

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

Эти моменты улажены, я могу занести изменения в $UIP?

Автор: AMD 4.2.2012, 17:12

в торренте тупо. зашёл на трекер по v6 - ты точно v6, зашёл по v4 - ты v4 и тебе трекер отдаёт список v4-пиров.
смешение 6 и 4 происходит через DHT, однако эти сети полностью разделены и независимы

нашлись альтернативные источники в DHT v6 - вот и качаешь с них


откуда-ж мы порты знаем?
надо ещё менять команду $MyInfo, чтобы она отдавала все эти порты.
тогда прощай работа через Socks5 в активном режиме, когда нет постоянного входящего порта, а он открывается каждый раз новый по необходимости

Автор: gif-t 4.2.2012, 17:30

Ну значит я предлагаю сделать круче, чем сделано у них.

Дак яж предложил для этого http://mydc.ru/topic5172.html?gopid=42448#entry42424.
Она передается:
клиент -> хаб (при входе, при этом хаб вырезает UPD порт ip адреса, отличного от того, по которому клиент к нему присоединен и сохраняет её)
хаб -> клиенты (тоже при входе)

Отсылается она как $UserIP, один раз, при входе, после отсылки списка $MyINFO

Далее полученные адреса используется в $CTM и $SCH для поиска и установки соединения соответственно.
Стандартные команды при этом не затрагиваются, они продолжают работать только на ipv4, ибо с ними больше ничего не сделать... хотя можно влепить в них адреса и сделать их для всех старых клиентов кривыми... по вашему это правильно?
А на ipv6 мы строим надстройку в протоколе из $UIP + $CTM и $SCH, которая более функциональна и + старые клиенты при получении просто игнорируют эти команды. Но получать их они не должны, т.к. хаб для них должен транслировать команды старого типа.

Откорректировал описание $UIP для дособезопасности.

Автор: AMD 4.2.2012, 17:36

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

моё предложение:

1. клиент, умеющий два протокола выставляет "DualPro" в $Supports
2. хаб после входа такого клиента придумывает ему уникальный(!) одноразовый 16-значный пароль (но длина пароля пусть не фиксируется протоколом) и высылает команду
$DualAddress <адрес-проверки> <порт> <пароль>
<адрес-проверки> - v6, если клиент зашёл по v4, и наоборот v4, если основное подключение v6
3. клиент в любой ему удобный момент подключается по адресу+порту и передаёт строку
$DualPsw <пароль>
4. сервер отвечает $ОК, если пароль верен либо $ХУЙ, если неверен. так клиент узнаёт, послали его с паролем или нет. проверочное соединение закрывается
5. сервер теперь знает все v4 и v6 адреса клиентов.
6. клиент пользуется старыми командами, указывая v4 или v6 по своему усмотрению.
7. сервер, при передаче $ConnectToMe или массовой рассылке $Search, проверяет, может ли получатель оперировать тем же адресом, что и отправитель. если не может - заменяет адрес (такие замены, по идее, редкое явление). если замена невозможна (у одного только v4, а у другого только v6), посылка дропается
8. ???
9. PROFIT

Автор: gif-t 4.2.2012, 17:40

А чего сожного, я предлогаю для новых клиентов старые команды заменить тремя новыми
$UserIP -> $UIP
$ConnectToMe и $RevConnectToMe -> $CTM
$Search -> $SCH.
А старым слать старые.
Больше ничего грандиозного..., всё очень просто... структура команд для обработки очень проста, они разбираются легко в цикле из 4-х строк. + Получаем огромный выигрышь в трафике.


Ну можно и так, это конечно на порядок сложнее моего предложения, но зато поиск будет работать по обоим протоколам.
В моём предложении поиск работает только по тому, по которому установлено соединение с хабом.
А вот функции установки соединения между пользователями ни там, ни там не ограничены.

Я думаю тут нужно послушать мнение хабописателя ) Стоит ли ради улучшения поиска писать такую функцию... наверно стоит?

Автор: Setuper 4.2.2012, 17:40

Нужно как можно меньше модификации.


Итак, есть критерий: защита от DDoS. Хаб должен осуществлять контроль ip адреса, поэтому адрес для соединения между клиентами должен совпадать с адресом коннекта к хабу (не рассматриваю специфические архитектуры приватных сетей, для которых это может быть не так, и где можно отключить проверку ip).


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


Случай 1: ipv6 (актив) коннектится к ipv6 (актив/пассив).
Тут должно быть всё ОК.

Случай 2: ipv6 (пассив) коннектится к ipv6 (актив).
Тут должно быть всё ОК.

Случай 3: ipv6 (актив) коннектится к ipv4 (актив/пассив).
Тут существует несколько вариантов развития ситуации:
1). Клиент с ipv4 физически не поддерживает коннект по ipv6.
2). Клиент с ipv4 программно (старый клиент) не поддерживает коннект по ipv6.
3). Клиент с ipv4 поддерживает коннект по ipv6.

Случай 4: ipv6 (пассив) коннектится к ipv4 (актив).
Тут должно быть всё ОК.

Случай 5: ipv4 (актив) коннектится к ipv6 (актив/пассив).
Тут существует несколько вариантов развития ситуации:
1). Клиент с ipv4 физически не поддерживает коннект по ipv6.
2). Клиент с ipv4 программно (старый клиент) не поддерживает коннект по ipv6.
3). Клиент с ipv4 поддерживает коннект по ipv6.

Случай 6: ipv4 (пассив) коннектится к ipv6 (актив).
Тут существует несколько вариантов развития ситуации:
1). Клиент с ipv4 физически не поддерживает коннект по ipv6.
2). Клиент с ipv4 программно (старый клиент) не поддерживает коннект по ipv6.
3). Клиент с ipv4 поддерживает коннект по ipv6.

Случай 7: ipv4 (актив) коннектится к ipv4 (актив/пассив).
Тут должно быть всё ОК.

Случай 8: ipv4 (пассив) коннектится к ipv4 (актив).
Тут должно быть всё ОК.


Проблемные случаи 3, 5 и 6. Но в случае 3 может помочь переподключение к хабу по ipv4 вместо ipv6.


Отсюда делаю вывод, что для соединения между клиентами полностью подходит вариант 2, который предложен мною для клиентов тут: http://mydc.ru/index.html?showtopic=5167&view=findpost&p=42402 но только с отправкой только 1 команды, узнав предварительно тип ip адреса противоположной стороны посредствам команды $UserIP.

Автор: gif-t 4.2.2012, 17:47

Setuper дак ужеж решили эти проблемы. Читайте выше. Я уже передаю два адреса сразу вместе с портами, и всего один раз, при коннекте командо $UIP. При этом моё решение проблемы уменьшает трафик хаба от обычного.
А ваше решение какраз огород. Ради какого-то IPv6 увеличивать трафик от хаба в 2 раза + путать старые клиенты командами, которые для них кривые. Непонятно как старый клиент поведет, когда получит в $Search ip адрес в виде квадратной скобки и 4-х буково, и после еще множество портов, тоже в виде буковок.

Автор: AMD 4.2.2012, 17:51

юз-кейс: старый клиент хочет скачать с нового, у него ничего не получается, он уходит с хаба )))
очень важно, чтобы как можно больше старых клиентов работали полноценно.
быстро сделает новый клиент только Fly, а остальные (gl и т.п.) просто не будут менять клиента из-за одного хаба.


http://mydc.ru/r/?http://xkcd.com/927/
;)

Автор: gif-t 4.2.2012, 17:54

Дак написано же, а старым слать старые!
Т.е. старые клиенты будут полноценно работать по IPv4. Они только не будут получать команды от клиентов, которые работают ТОЛЬКО по ipv6.
От ipv6&ipv4 и ipv4 only клиентов они будут получать не $SCH, а старый $Search с ipv4 адресом внутри.
Т.е. мои команды никоим образом не вредят и не мешают старым клиентам.

Автор: AMD 4.2.2012, 17:56

уточни, замена команды происходит на хабе?

Автор: gif-t 4.2.2012, 17:58

Нет, замена не происходит. Клиент отсылает хабу новую и старую. Хотя я против этого...
В общем хабу не нужно формировать старую, он просто отсылает старую старым клиентам, новую новым. Вот и всё.

Автор: AMD 4.2.2012, 18:01

а, тогда всё вообще элементарно!
пусть клиент посылает команды $ConnectToMe и $Search в старом виде но два раза - с v4 и v6 адресами.
а там уже что-то как-то законектится и поищется )))

Автор: gif-t 4.2.2012, 18:08

Дак в DC то сейчас для установки соединения используется один порт, который выставляется в том же флайлинке в настройках соединеия. И только он и нужен чтобы начать скачивание, т.к. у многих только он и открыт в роутере. И при скачивании в $ConnectToMe и $RevConnectToMe используется именно он, этот единственный порт.
Чем вам эта схема не угодила? Вы считаете нужно наоткрывать кучу портов и в каждом коннекте указывать новый?
Почитайте еще раз пожалуйста http://mydc.ru/topic5172.html#entry42424, в данных командах принципы никакие не меняются, просто изменена структура команд для передачи ipv6 адреса дополнительно. И передача адресов и портов вынесена в отдельную команду, чтобы они не создавали лишний трафик в других, часто повторяющихся командах.

Автор: Setuper 4.2.2012, 18:10

Согласен, возможно написал бред, но отсылая порт 1 раз, ты снижаешь функциональность, которая заложена первоначально в протокол.

Автор: AMD 4.2.2012, 18:11

это придётся делать при работе через Socks5.
хотя наверное мало кто ходит в dc через прокси

Автор: gif-t 4.2.2012, 18:15

Setuper, ну пока используется один порт... хотя я Павлу Пименову предлагал для актиного поиска использовать несколько UDP портов, чтобы снизить перемешивание результатов поисков.
НО в любом случая я специально предусмотрел "хвосты", чтобы можно было добавить что угодно, вплодь до еще множества портов, когда это понадобится.
В старых командах кстати добавление портов не предусмотрено.

Автор: AMD 4.2.2012, 18:17

а старые - это какие?

Автор: Setuper 4.2.2012, 18:18

Все же придерживаюсь моей точки зрения: использование для соединения старых команд как с ipv4, так и с ipv6, определяя тип ip противоположной стороны по команде $UserIP. А при активном поиске отправлять сразу 2 команды.

И не городить огород!

Автор: AMD 4.2.2012, 18:28

можно. только UserIP немного излишняя. нужно только знать, какие протоколы поддерживает пир.
помог бы какой-нибудь флажок типа "бомба", но флажки, увы, уже все разобраны (можно у грея отхапать флажки М/Ж, но тогда будет неразбериха).
можно в тег признак

в-общем, админы хабов обычно не выдают список IP не потому, что экономят трафик, а потому, что мнят себя царьками, что только они видят полный список IP.
принудительное раскрытие IP снизит популярность хаба.

опять же, не решается вопрос передачи двух адресов сразу. если сделать только флажки (умеет ли клиент v4 и v6), задача $ConnectToMe решается.

Автор: gif-t 4.2.2012, 18:28

Старые
$UserIP, $ConnectToMe, $RevConnectToMe и $Search
Новые
$UIP, $CTM и $SCH.

Setuper, я не понимаю, что именно вас пугает? У вас функции для обработки старых команд с IPv6 адресом внутри выйдут гораздо больше, чем для предложенных мной.

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

AMD, насчет портов, не проблема, сейчас могу вписать их. Порт будет отправляться в командах, если он отличный от указанного в $UIP.

Автор: Setuper 4.2.2012, 18:37

AMD, Можно и в тэг. Например:

В любом случае от хаба ничего не нужно. Все изменения со стороны клиента.

gif-t, меня пугает навороченность, которая выглядит не продуманной. Не знаю что на это всё ответят разработчики клиентов, но думаю им также покажется это всё черезчур навороченным.

Автор: gif-t 4.2.2012, 18:44

Где навороченность? Навороченность - это ADC протокол.
У меня просто 3 команды с простой структурой для обработки. Яж не предлагаю устанавливать 2 соединения с хабом, слать всякие ключи, генерировать ID и т.п.
Всё очень просто, вы наверно полностью не вникли...
Я сделал на основе старых всего 3 команды и удалил ip:port из всех, кроме одной - $UIP
Никакой навороченности нет...

Автор: AMD 4.2.2012, 18:47

от хаба только отключить проверку адреса в команде, если не заморачиваться со схемой подтверждения коннекта по второму протоколу.



ну вроде RusHub и FlyLink - опенсорс. можешь проверить свою гипотезу о простоте изменений )))



но так ты и не решаешь проблему подтверждения второго ip, позволяя проводить махинации, используя хаб для DDoS

Автор: Setuper 4.2.2012, 18:49

Ну проверка ip в русхабе отключается установкой в конфиге параметров bCheckCTMIp и bCheckSearchIp в 0.

Правда в текущей версии русхаба (2.3.8) существует баг с соединением по ipv6, но в следующей версии это уже будет исправлено (он уже исправлен на svn).

Автор: gif-t 4.2.2012, 18:49

Ну в флайлинк я не полезу
А в своем клиенте сделаю.
Мне всего-то нужно добавить еще 3 функции для обработки этих 3-х команд и 3 для генерации.
Т.к., повторяюсь, структура очень проста - всего один разделить $, эти функции получатся минимальны по размеру.

Для вашего решения я уже написал функцию вынимания ipv6 адреса и search запроса (там проблема что и у блоков в адресе и у порта и адреса - разделитель двоеточие. Функция получилась очень корявой... а если учитывать что вы планируете передавать два адреса сразу, выйдет очень неаккуратный и кривой код. И вообще всё это теряет всякий смысл, зачем разбирать старые кривые неудобные команды, если можно сделать новые? Какраз такие, какие предложил я!
Оставлять для IPv6 старые команды вообще бессмысленно, т.к. клиенты, которые существуют сейчас, их всеравно не смогут разобрать, а новым клиентам вы бросаете палки в колеса.
Т.ч. взвесте всё еще раз, прочитайте http://mydc.ru/topic5172.html#entry42424 еще несколько раз и воспользуйтесь здравой логикой, правильное решение только одно!

Автор: Setuper 4.2.2012, 19:02

Ты лучше спроси у разработчиков клиентов что они об этом думают?

Автор: mariner 4.2.2012, 19:04

Это в каком же?

Автор: AMD 4.2.2012, 19:06

одного не понимаю: зачем делать новый хаб на старом протоколе?
поддержка супер-навороченных старых хабов - понятна.

но в новом... пользователям протокол без разницы, а админам и программерам ADC удобнее.

Автор: gif-t 4.2.2012, 19:13

Setuper, попробую их сейчас привлечь сюда.
mariner, пишу свой клиент, полностью с нуля ) это будет долгая история
AMD, я честно не знаю. Мне лично ADC не нравится, я не согласен с некоторыми его положениями. И если посмотреть статистику, со мной солидарны очень многие, adc хабов очень мало. Все крупные хабы остаются на NMDC, поэтому его стоит развивать.


Setuper, а можно где-нибудь посмотреть лог присоединения к ADC хабу? Сейчас решил быстро накатать код, посмотреть механизм, но не нашел описание функции hash(PID) == CID...

Автор: AMD 4.2.2012, 23:24

это обычный TTH
39-символьный PID декодируется в 24 байта двоичных данных (алгоритмом Base32).
затем считаем TTH, как если бы эти 24 байта были записаны в файл.

Автор: gif-t 4.2.2012, 23:32

Вроде разобрался

Автор: Setuper 5.2.2012, 0:49

Поковырял исходники птохи и посмотрел что реализовано там.

Итак, вот последовательность входа на хаб:

Если соединение с хабом происходит по ipv6, то в команде $Supports может быть отослана характеристика IPv4. В этом случае клиент не будет считаться вошедшим на хаб, пока после команды $MyINFO он не отошлёт на хаб через ipv4 команду $MyNick со своим ником. Таким образом клиент подтверждает, что этот ipv4 именно его. Получается у клиента есть 2 ip адреса (ipv4 и ipv6).

Что касается команд поиска и соединения, то клиент сам решает какой ip в них отсылать.

Вот это грамотный подход.

Автор: gif-t 5.2.2012, 1:13

Setuper, вроде как такой подход был отвергнут еще на первой странице этой темы из-за черезмерного усложнения ради всего-лишь возможности искать по ipv4 и ipv6 сразу? Всетаки установка второго соединения и все последующий действия - это не простая модификация команд, которую предлагаю я...
К томуже, как я ранее сказал, в данном случае правильнее ввести новые команды, а не использовать старые.
Старым клиентам принципиально никакой разницы, а новым - обработка гораздо проще.... + нет, чтобы воспользоваться ситуацией и подкорректировать всё под себя, будем слать два раза один и тот же поисковый запрос с разными ip адресами, генерить трафик за просто так.... это глупо и и вообще категорически неразумно.

Но если в птохе уже реализовали, то наверно пускай оно так и будет. Хотя лично я с таким подходом вообще не согласен. (никто не желает меня поддержать? у нас еще есть время всё исправить)

Автор: mariner 5.2.2012, 2:02

А где оно тут?

Автор: Setuper 5.2.2012, 10:32

Второе соединение устанавливается только для отсылки одной команды: $MyNick. После получения этой команды хаб принудительно закрывает это соединение, сохранив его ipv4 адрес для уже существующего соединения.

Автор: AMD 5.2.2012, 10:44

минусы есть, в сравнении с тем, что я предлагал на предыдущей странице
1. Supports IPv4 высылается только при коннекте по IPv6. а хотелось бы симметрично: при коннекте по IPv4 уметь альтернативно указать v6 (Supports IPv6). чтобы не заморачиваться выбором разных Supports можно вместо двух придумать один общий
2. схема второго коннекта избыточна. я так понимаю, происходит обычный вход (Lock, Supports, Hello, Version, MyNick, ...) причём схема не защищает от подделки. ведь по v4 может зайти другой юзер с другого IP и передать тот же ник. одноразовый пароль лучше. ну и, что хуже, кусок обработчика протокола для второго коннекта нужно будет приделывать в клиент и хаб, когда предложенный выше вариант был наиболее простым: посылка - ответ.
3. хаб не передаёт свой альтернативный адрес (например, v4 при входе по v6). вычислить его нельзя. DNS? а если хаб на IP, без доменного имени. бесплатный DNS, типа no-ip.org? там он не может полноценно одновременно регистрировать запись и v4, и v6. клиент не должен угадывать второй адрес хаба. хаб должен сам его сообщить



вот это тоже не нравится. коннект на второй адрес всё равно асинхронный, неизвестно когда произойдёт.
намного проще не переводить таких юзеров в "отстойник" для ожидающих подтверждения v4 (а в реальном мире могут быть технические проблемы и подтверждение не произойдёт), а разрешить юзеру дополнительно авторизоваться позже в любой момент. даже порт на это дело выделить другой, чтобы не смешивать протоколы. после авторизации второго адреса IP-фильтр в $Search и $ConnectToMe будет узнавать второй адрес и не блокировать его

Автор: Setuper 5.2.2012, 11:53

1. Ну вообще-то по коду существует ещё характеристика IP64, однако на данный момент она не используется нигде.
2. Ты неправильно понял. Никакого второго входа не происходит, точнее происходит, но с отсылкой всего лишь одной команды, а не полного входа. И схема защищена от подделки, так как пользователь не считается вошедшим, пока не отошлёт эту команду. Другой пользователь не может передать тот же ник в этой команде, так как это возможно сделать только на стадии входа, а не когда либо. Теоретически это конечно возможно, но обычно ты не знаешь когда войдёт тот или иной пользователь. Конечно можно сидеть и сниферить его соединение с хабом, но это специфичный и очень редкий случай. На этот случай защита может быть со стороны клиента.
3. В птохе по всей видимости предполагается, что адреса известны, ибо под них существую строгие настройки на хабе.

На ожидание команды $MyNick отводится определенное время ожидания, если за это время она не была отослана, то клиент отключается. Это время достаточно большое чтобы обойти любые неполадки в сети. И это ничем не отличается от времени ожидания любой другой команды входа!

Автор: AMD 5.2.2012, 12:36

ок. я просто посчитал, что дополнительная защита не помешает


самой птохе известны. а клиент-то как узнает? например, клиент заходит на хаб по голому IPv6-адресу или IPv4 DNS от сервиса динамических IP


я о ситуации, когда v6-пакеты ходят, а v4 - не ходят. тогда клиент вообще не сможет зайти на хаб. а можно заранее продумать эту ситуацию и минимизировать проблемы у юзера

Автор: Setuper 5.2.2012, 13:59

Ну этот контроль уже должен быть на стороне клиента, если не получается отослать $MyNick по ipv4, то значит не дано и клиент должен переподключиться без IPv4 в $Supports.

Автор: AMD 5.2.2012, 14:18

когда делаешь протокол, надо думать на 2 хода вперёд.

по моему сценарию, если v4-канал недоступен, клиент просто в чат выведет предупреждение.
если юзер далёк от технических тонкостей, он просто проигнорирует и будет качать только с некоторых пиров. иначе поднастроит.

никто, я уверен, не будет писать логику переподключения с урезанным набором в Supports на второй попытке. то есть костыль прямо таки напрашивается.
сначала введут галочку в клиент "не использовать IPv4 при входе на v6-хаб", затем её попросят сделать индивидуально для хаба.
и ещё откроют кучу тем на форумах по этой проблеме. зачем, если заранее можно сдлать хорошо. тем более, это не усложняет код, а упрощает (либо никак не влияет).

Автор: gif-t 5.2.2012, 16:08

Невнимательно прочитали... или вообще не прочитали мой второй пост в этой теме. Там я описал что проблема доса - это только проблема поиска. Т.ч. не надо сюда приплетать файлообмен между пользователями, он безопасен без подтверждения второго ip адреса.
Т.о. подтверждение второго ip адреса нужно только для более полного активного поиска.
В остальном я с вами согласен, зачем делать костыльно и быстро, если с этим костылем нам потом жить вечность? Сложившуюся ситуацию надо использовать наруку, именно поэтому моё предложение лучше, чем предложение слать подряд две команды старого типа с ipv4 и ipv6.

Я немного дополнил свой второй пост снизу, привел все плюсы и минусы решений, у варианта с отсылкой двух команд старого типа вообще нет плюсов.

Автор: Setuper 5.2.2012, 16:22

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

Автор: gif-t 5.2.2012, 16:30

Я только дописал снизу сравнение, для тех, кто первый раз зашел в тему и не понимает в чем спор. Остальное в посте я не менял.

Автор: Setuper 5.2.2012, 16:38

Ты изобрёл свой велосипед. Этот велосипед уже изобретён и называется ADC протокол.

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

То есть, хочешь ipv6 - переходи на ADC!
Нужно продвигать новый протокол, а не продолжать накручивать что-то на старый.

Автор: gif-t 5.2.2012, 16:53

Мне не нравится ADC, я хочу продолжать накручивать старый
Тем более добавление 3-х команд - это не накрутка, это однократное, необходимое и малюсенькое дополнение
А расписал всё так подробно, потому что меня воротит от черезчур кратких описаний, в которых постоянно нужно что-то догадывать. Например такое отвратительное описание у протокола ADC. А текст моего дополнения охватывает абсолютно все аспекты и ни у кого при его чтении не возникнет вопросов, там нет неоднозначностей.
Можно подождать пару неделек, а потом устроить голосование, стоит ли вообще делать поддержку ipv6 или нет, и если да, то по какому варианту.

Автор: Setuper 5.2.2012, 17:09

По мне так в документации ADC протокола всё понятно описано. Что именно тебе там не нравится?

Ты лучше бы поговорил с разработчиками клиентов, что они об этом думают?

Автор: gif-t 5.2.2012, 18:18

Ну например что
hash() - это обычный TTH

Не нашел я этого, спасибо AMD, что подсказал.
Потом я присоединяюсь к хабу - и вижу в CDM отлидчике параметры, которые в протоколе вообще не описаны. И таких неописанных параметров очень много. Приходится гадать какой отвечает за сжатие, какой за еще что-то...

Насчет разработчиков клиентов, Павел Пименов молчит, а другим нужно переводить, у меня время будет только на следующих выходных..

Автор: Setuper 5.2.2012, 19:01

Так это наверное расширения протокола: http://mydc.ru/r/?http://adc.sourceforge.net/ADC-EXT.html
Всё отлично описано.

Автор: gif-t 5.2.2012, 21:07

Не нашел описания ключей в INF: AP, FS, KP
А также не нашел ключа, определяющего режим клиента (пассив/актив) и не нашел ключа, определяющего DHT порт.
US максимальная скорость закачки (байт/сек), а DS максимальная скорость скачки (байт/сек) - не определено относительно кого? Самого пользователя о котором информация или относительно других пользователей?
Не понял почему в INF отсылаются только UDP порты, почему нет TCP???? Ведь если всего лишь отослать TCP порты в INF, можно сразу исключить команду RCM! И при необходимости клиенты могли бы сразу соединялись с нужными им клиентоми, без отсылки команы RCM хабу. У хаба и так других дел полно...
Про \s \n и т.д. я вообще молчу, этот мега костыль сразу бросается в глаза.
Протокол построен неидеально и явно не продуман до конца... не понимаю, вроде там написано куча народа собралась для его разработки... как вообще такое могло получиться?
Надеюсь в следующих версиях введут TCP порты в INF...

Да, часть есть там...

Автор: AMD 5.2.2012, 21:42

FS - число свободных слотов. описано в change log для DC++ 0.781
KP - http://mydc.ru/r/?http://forums.apexdc.net/topic/3075-keyp-keyprint-draft-proposal/
AP - дополнение к VE. раньше было - VE="Flylink r501", а теперь AP=FlyLink, VE=r501. для порядка разделили. по пол-ву байт небольшая разница


для пассива I4=0.0.0.0, т.е. внешний IP-адрес не существует


разумеется, хаб не знает о DHT


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


в NMDC тоже есть escape-символы, экранирующие | $ & и прочие служебные. в ADC экранируется только \s \n + принудительная поддержка Unicode - тоже огромный шаг вперёд.



DS пишет сам юзер. например, я указал свою скорость инета (по тарифу) - 40 мегабит. в DS передаётся DS5000000 (5 МБ/с).
US совпадает с DS

но если выставлен лимитер на up или down, в этих свойствах появляется информация из лимитера, тогда DS и US могут различаться.

Автор: ShadoWx 7.2.2012, 7:27

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

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

И останется просто продолжать ждать того момента, когда большинство поймут что старые клиенты уже бесполезны...
Хотя если учесть как многие уже относятся к DC++, это уже маловероятно ...

Автор: Ksan 7.2.2012, 15:39

ShadoWx, логика подсказывает, что если у большинства "старые", как ты это называешь, клиенты, то вряд ли они будут так считать

Автор: gif-t 7.2.2012, 17:34

Я про тоже, 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 будет не скоро...

Автор: AMD 7.2.2012, 20:09

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

а смигрировать юзеров не так сложно. не нужно закрывать старый порт, нужно делать редирект на adc

Автор: ShadoWx 8.2.2012, 6:21

да смигрировать тем же xinetd или inetd сделать перенаправление ...я уже так делал, не хотелось бы народ терять =(

Автор: AMD 8.2.2012, 20:39

честно - не понял, как это.
я говорил о редиректе на уровне протоколов NMDC/ADC, а не TCP
если направить юзеров NMDC-хаба на порт ADC-хаба, конечно ничего хорошего не получится

Автор: nail 9.2.2012, 2:05

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

это всё разными хабами, и соответственно если прописан в фаворитах только dchub://mysite.ru, то зайдя на adc://mysite.ru - пользователю выведется "введите пароль", дц клиент и не подумает автоматически авторизовываться.
+ часть пользователей вообще не поддерживает ADC и не смогла зайти на хаб.
В итоге пришлось быстро возвращать всё на NMDC....
Единственное правильное решение какраз не вводить резко новый протокол, а постепенно совершенствовать старый, приводя его к идеальной форме и при этом сохраняя совместимость. А когда все будут готовы - отрубить совместимость со старым. Разрабы ADC поступили по своему - отказались от плавного перехода, и в результате имеем 30 ADC хабов.
Пока все не будут готовы к ADC, пока разрабы DC клиентов не профиксят багу с адресами, а зная темпы разработки тогоже флая я могу сказать что это будет нескоро, пока большая часть пользователей не перейдет на такие клиенты - NMDC будет работать.
Т.ч. делайте ipv6, им еще многие успеют попользоваться

Автор: Setuper 9.2.2012, 8:48

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

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

Автор: gif-t 9.2.2012, 18:52

Гибридные хабы уже есть, на них подавляющее большинство сидит по NMDC

Автор: Saymon21 9.2.2012, 19:00

gif-t, Это какие, в плане софт? Знаю только FlexHub.

Автор: gif-t 9.2.2012, 19:32

Да, именно он. Я посидел на этом хабе, каждые 10 секунд бот упорно толдычил мне что с NMDC пользователей я качать не могу. А что мне делать, на это хабе почти 90% NMDC! Зашел по NMDC, сразу закачки и поиск пошел.
ADC на этом хабе оказался совершенно непрогрессивным и никакой плавности я не заметил, одни неудобства.
Т.е. если Вы, Setuper, предлагаете гибридный хаб, то вместе с ними предлагайте и гибридные DC клиенты, которые без неудобств будут работать на таких хабах.
В противном случае давайте введем 3 команды, которые я предложил во втором посте, сделаем плавно поддержку ipv6 в NMDC и оставим переход на ADC на лучшие времена... хотябы на тогда, когда у подавляющего большинства пользователей будут DC клиенты с полной поддержкой ADC и, как было сказано выше, рабочей определялкой адреса хаба. Пока таких пользователей не то что мало, а вообще нет. И переход на ADC сейчас будет сопровождаться большими неудобствами и потерями пользователей.

Автор: IRainman 9.2.2012, 22:53

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

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

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

p.s: Хватит уже тянуть кота за яйца - ему больно. Хватит писать новые расширения (зачёркнуто) костыли к NMDC протоколу, его похоронить давно пора. А IPv6 ныне последний способ перетащить всех без исключения юзеров на ADC. А если перехода не произойдёт хоронить надо будет не NMDC, а DC++ целиком.

Автор: nail 10.2.2012, 2:32

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

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

Кстати, разработчикам флая стоило бы заняться проблемой ADC, т.к. поддержку самого протокола добавили, но ничего не сделали, чтобы пересаживать пользователей на него. Вон Setuper молодец, пишет гибридный хаб, чтобы пользователи, готовые к переходу - переходили, а не готовые, оставались. Но чтобы эта схема работала безболезнено и для тех, и для других, нужна небольшая поддержка со стороны DC клиента, чтобы клиенты, работающие по разным протоколам, могли и взаимодействовали друг с другом. А именно качать друг с друга, отсылать результаты на поисковый запрос в формате соответствующего протокола и т.д. А всякие берюльки на свой клиент всегда успеете навешать.

Автор: IRainman 10.2.2012, 15:08

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

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

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

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

Автор: mariner 10.2.2012, 15:13

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



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

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

Автор: IRainman 10.2.2012, 16:03

mariner

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



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

Автор: gif-t 10.2.2012, 18:59

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

Насчет преобразования команд со стороны хаба - это простые операции, они не дают нагрузку.
В предложенном мной во втором посте дополнеии, хабу ничего преобразовывать не надо вообще. Если вводить ipv6 в NMDC - то моё дополнение будет самым правильным.
Впринципе решайте сами...я вижу что никому, кроме меня, моя идея не нравится, значит видимо действительно это не нужно. Но то, что вводится для подержки ipv6 в птохе - это действительно костыль, и вы вот сейчас отказались от продвижения моего варианта, а потом, когда в птохе окончательно введут свой ipv6 костыль, вам придется приспосабливаться, переписывать функции - обработчики и т.д. и вы поймете что надо было вводить дополнение gif-t'а когда он предлагал, тогдаб не было столько проблем и такой костыльности, и не проиграли бы в трафике и функциональности.

Автор: IRainman 10.2.2012, 19:10

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

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

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

Автор: gif-t 10.2.2012, 19:57

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

Я думал об этом, но практически единственное что я успеваю делать в перерывах между работой - написать здесь. И не могу похвастаться своим английским...
Хотя с другой сторону меня убивают такие варианты как отсылка старых команд два раза или то, что делают в птохе. Ну это явно неправильно...

Автор: Saymon21 10.2.2012, 19:58

Заголовок Host ничего не говорит?

Автор: gif-t 10.2.2012, 20:00

Эмм, а можете поподробнее?

Автор: Saymon21 10.2.2012, 20:04

Подробней в RFC.
зы. http://mydc.ru/r/?http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 14.23

Автор: gif-t 10.2.2012, 20:09

Вы можете сказать своими словами? Зачем в маны сразу посылать? Типо я что-то там надумал, а что именно - ищите и разбирайтесь сами!
Я помню что браузер устанавливает tcp соединени и передает домен..., далее вебсервер решает как ему отвечать. Эта схема позволяет держать на одном ip множество сайтов... не понимаю как я это связано с обсуждаемой нами проблемой?
В общем пишите прямо!

Автор: Saymon21 10.2.2012, 20:19

Либо я не понял вашего поста, либо вы просто быстро забываете, что пишите. Прочитаем пост http://mydc.ru/topic5172.html?view=findpost&p=42615

Автор: gif-t 10.2.2012, 20:22

Я всё прекрасно помню, я не понимаю вашего поста. Вы сказали:

тыпо вы чё, дураки, ответ же очевиден, слово Host!
Вот я и прошу чтобы вы пояснили, что за хост вы имеете ввиду.
А Вы сразу в маны посылаете... типо чтоб мы сами догадывали что вы имели ввиду.
Повашему это правильное отношение к собеседникам?
Пишите прямо что имееете ввиду, не надо юлить и запутывать разговор.

Отвечу на ваш вопрос, заголовок Host ничего мне не говоритю

Автор: Saymon21 10.2.2012, 20:25

Хорошо.

Каким образом, если в HTTP за определение запрашиваемого ресурса отвечает заголовок Host, когда в NMDC/ADC нет ничего подобного?

Автор: gif-t 10.2.2012, 20:32

Saymon21, эмм не вижу проблемы.
Давайте продумаем по порядку, так проще всего:

1. У пользователя в фаворитах сохранен DNS в виде dchub://mydns.ru, ник и пароль.
2. Владелец DNS направил этот DNS на ip, под которым находится его nmdc хаб.
3. Далее пользователь заходит и флай автоматом авторизовывается на этом nmdc хабе.
4. Далее администратор перенаправляет редиректом пользователя на adc хаб, находящийся на этом же ip.
5. Пользователь получает команду редиректа на adc://mydns.ru
6. Флай смотрит и видет что это один и тотже днс - один и тот же хаб, заходит на ADC хаб и автоматически авторизовывается на нем.
7. Пользователь доволен, переход на ADC для него прошел без каких либо телодвижений, полностью автоматически и без проблем.

На каком шаге Вы видите возможность возникновения ошибки/проблемы?

Если администратор хачет поднять два хаба, то он может сделать так:
hub1.mydns.ru
hub2.mydns.ru:412
и т.д.
Или назначить каждому свой ip и оставить у каждого стандартный порт

Автор: Setuper 10.2.2012, 20:39

Может уже хватит оффтопить?

Автор: Saymon21 10.2.2012, 20:39

ADC и NMDC - это не один и тот же хаб. В любом случае, пользователь должен будет переписать в клиенте адрес хаба с dchub:// на adc:// или adcs://.
Без этого никак. Для некоторых юзеров уделить пару сек. времени и переписать это вызовет кучу проблем. Странно, что вы этого не понимаете.
Во вторых, всётаки не понятно, как вы собрались делать два (или больше хабов) на одном айпи и порту, но разных доменах.


зы. Хватит редактировать посты уже постоянно! Говорили уже ведь!

Автор: gif-t 10.2.2012, 21:15

Saymon21, я не понимаю вас, мы ведь говорим про редирект.
Редирект, это команда, отправляемая хабом и сообщающая клиенту адрес другого хаба, к которому ему нужно присоединиться.
На NMDC хабе, перенаправляющем на ADC она выглядит так:

Где вы здесь видите проблемы? Эта схема может работать постоянно, главное NMDC хаб не вырубать.
А потом IRainman еще предложил перманентный редирект
Setuper, пардон, больше не буду

Автор: AMD 11.2.2012, 11:55

грелка кстати запилил похожую фичу с полгода назад:

0.50-x64 (25.08.2011)
Поиск по открытым хабам при открытии dchub: или adc: ссылки. Если хаб уже открыт с другим url, но тем же ip+port, новое окно не открывается (OCTAGRAM)



вы пытаетесь зацепиться за невежество оппонента и послать его на RFC (что конечно правильно).
одна фактическая ошибка - и дальше, как в математическом доказательстве, вы всё последующее считаете несостоятельным.

но лучше попытаться расшифровать, что хотел сказать gift.
я так понял, он предлагает сделать доверенные зоны. при переходе на другой хаб без смены доменного имени клиент может передать те же логин/пароль, с какого хаба его переадресовали, считая, что пароль не уйдёт левым людям

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

кстати, в ADC есть referer
http://mydc.ru/r/?http://dcpp.wordpress.com/2008/01/17/adc-hub-referrer/

Автор: Saymon21 11.2.2012, 12:38

[offtop]
Хех. У нас вот только вчера на работе говорилось, мол если ехать куда далеко и долго, бывает полезно перед поездкой распечатать какой нить RFC и читать в дороге...
Refer в ADC, ну да, знаем. Кстати вот, и в nmdc есть http://mydc.ru/topic5095.html?view=findpost&p=41616
[/offtop]

Автор: gif-t 12.2.2012, 18:23

Petr Kozelka (разработчик птохи):

Честно говоря не понимаю, как можно создать ддост отаку по TCP в DC...? Я уже несколько раз описывал что с файлообменом никаких проблем нет, DOS отаку не организовать. Проблема только с UDP и соответственно если ip не подтвержден - то блокировать нужно только UDP, т.е. поиск. А возможность устаналивать TCP содинения нужно оставить т.к. по протоколу массовую TCP ддос отаку организовать не получится. Почему-то все заблуждаются на этот счет.
Разрабы птохи пошли по банальному пути наименьшего сопротивления, впихнули IPv6 адреса в старые команды....

Таким образом, если я правильно понял, в итоге получаем ИХ схему:

• Если хаб шлет старым клиентам команды с ipv6 - старые клиенты пытаются обработать такие команды и у них ничего не выходит или выходит непонятно что.
• Зачем-то затронули команду $MyINFO...
• Новые клиенты обрабатывают их сложными функциями, с большей нагрузкой, но корректно (Например для разделения блоков ipv6 и отделения порта от ipv6 используется один и тот же разделитель - знако двоеточия. В функции придется выделять квадратные скобки... в общем это не очень удобно)
• Команды соответствующего формата отправляются пользователям с соответствующим протоколом (IPv4/IPv6). Один пользователь не может использовать сразу оба протокола. Или же отсылается две команды с разными ip адресами подряд, сначала с ipv4, потом с ipv6. В таком случае новому клиенту нужно помнить содержмиое нескольких команд, чтобы не реагировать дважды на один запрос... неочень удобно. А также, весьма существенный факт - увеличивается трафик хаба. А, как вы все знаете, сейчас это большая проблема, хабы генерят слишком много трафика.
• Не получаем никакого выигрыша по трафику, хотя смысл этого не сделать, если совместимость со старыми клиентами всеравно теряем?...
• И самое интересное, если опять же я правильно понял, при каждом поиске по другому протоколу клиент устанавливает новое соединение с хабом...?

В моей схеме:

• Старые клиенты должны получать команды старого типа и соответственно они будут их корректно обрабатывать. При получении команды нового типа (а такого происходить вообще-то не должно) они их просто проигнорируют.
• Новые клиенты обрабатывают их легко и быстро, т.к. новые команды гораздо проще (идеальны) по структуре.
• Затронуто минимальное кол-во команд, необходимое для поддержки IPv6. MyINFO я не трогал...
• Новые команды короче и клиенту, в зависимости от поддержки, отсылается либо старая длинная команда, либо новая короткая. Это приводит к сильному сокращению исходящего трафика хаба, особенно в будущем, когда большинство клиентом будет работать на командах нового типа.
• Команда отсылается одна и сразу в себе содержет все необходимые параметры. Один клиент на хабе работает сразу одновременно по обоим протоколам. Т.е. качает и раздает сразу и по ipv4 и по ipv6. Поиск соответственно без подтверждения идет только по одному IPv4 или IPv6, ибо есть вероятность доса. А при подтверждении - сразу по обоим. Для подтверждения, как уже говорилось, нужно устанавливать второе соединение с хабом. Если это реализовать - ipv4 и ipv6 на NMDC будут поддерживаться одновременно и абсолютно полностью.
• Сокращен трафик за счет передачи IP адресов и портов отдельно и только при изменении. В Поисковых запросах и командах на установку соединения соответственно они не отсылаются. А также сокращен трафик за счет уменьшения длины ключей.

Ну я думаю картина вполне ясна, моё предложение оказалось весьма запоздалым и уже не получится переубедить создателей птохи.
Решайте что будете реализовывать, вериант птохи, мой или свой или все сразу или ничего. На ADC я советую не надеяться, админы хабов еще не скоро переселятся на него и переселят всех пользователей, даже под аргументом IPv6.

Еще добавлю одну вещь:

Это средняя популярность DC клиентов на хабах:

С разработчиками флайлинка они обязаны согласовать своё решение. Если флайлинк не будет поддерживать их модификацию - собственно говоря в ней не будет особого смысла.

Автор: Артём 12.2.2012, 18:27

знали бы вы как этот "разраб птохи" относится к вашим "обзываниям" птоки / PtokaX - "птохой"

Автор: gif-t 12.2.2012, 18:35

Артём, я знаю, просто не звучит...
Я им кстате в письме пояснил что так некоторые русские называют их хаб
Товарищь IRainman тож пишет птоха: http://mydc.ru/topic5172s60.html?p=42614#entry42614

птоха - это почти официальный перевод на русский слова ptokax

Автор: Setuper 12.2.2012, 19:10

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

Кстати, отказ клиентов от их концепции может помочь им открыть глаза для перехода на ADC.

Автор: gif-t 12.2.2012, 19:11

Пока я не заметил поддержки их концепции со стороны флая...думаю сейчас IRainman отпишется
А куда писать насчет ADC, хочу предложить им добавить кое-что?

Автор: AMD 12.2.2012, 21:06

да, ADC-команда может содержать одновременно v4 и v6-адреса. без потери совместимости с существующими клиентами.
но вопрос второго коннекта клиента к хабу для подтверждения адреса в ADC не решён.

так что тут есть поле для велосипедостроения )))

Автор: nail 13.2.2012, 0:36

Еще всетаки опционально могли бы сделать передачу TCP портов в INF и отключение команды RCM на хабе, т.к. не все админы хотят ограничивать некоторым пользователям файлообмен, и включение такой опции немного снизило бы трафик и нагрузку на ADC хабах, т.к. пассивные пользователи могли бы соединяться с активными напрямую, без отправки хабу RCM.

Автор: AMD 13.2.2012, 20:10

не-мо-гли-бы ни-ког-да!

что написано в референсном коде принятия соединения?

это NMDC.
ADC проверяется ещё и по токену, который прошёл через хаб.

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

Автор: nail 14.2.2012, 3:14

Не понимаю, в чем смысл вводить столько глупых ограничений?
Надо фиксить это в клиентах, удалять нафиг такие алгоритмические лажи. Протокол должен быть максимально гибок.
+ это же значительная и вообще бессмысленная нагрузка на хабы...
Еще я выяснил что в протокол NMDC не заложено ограничение на количество пользователей, а в ADC заложено - 1 048 576.
Это ошибка из области ipv4 или 32 битных систем. И в первом и во втором случае лимиты были достигнуты намного раньше чем предполагалось.

Автор: AMD 15.2.2012, 22:30

приватные хабы и всё такое.
заходишь - прошёл регистрацию - можешь качать. иначе насканил портов через nmap, нашёл dc++, дёрнул файл-лист и давай приватные файлы выкачивать

публичные хабы - вершина айсберга dc++


да ну фигня. SID везде в клиентах и хабах хранится как Int32. просто генераторы, применяемые в текущих хабах, берут символы из набора base32.
если брать все ASCII-знаки (вроме пробела), sid останется красиво читаемым и ёмкость хаба будет (128-32-1)^4 = 81 450 625 юзеров.
даже сейчас можно в SID класть любые байты, экранируя \n и \s согласно правилам кодирования в протоколе.
так что легко модифицировать генератор SID-ов в хабе - расширить ёмкость до 4 миллиардов, и это без потери совместимости с самыми ранними adc-клиентами.
но дальше уже лимит протокола

Автор: Setuper 16.2.2012, 16:18

В протоколе написано:

Если использовать ASCII, то это уже не ADC протокол. Перекраивать это никто не собирается.
Да и вообще о чём речь? какой миллион? современное железо даже 100000 не потянет

Автор: gif-t 16.2.2012, 23:10

Setuper, а это не важно. Когда IPv4 был создан, тоже ходили слухи что не возможно построить сеть из нескольких миллиардов компов, потому что столько не сделать, а если и сделают, такая сеть не сможет функционировать. И с оператовкой тоже самое. Это было время когда 10 мегабайт было очень много, никто и не думал что величина в 4 гигабайта достижима. И процессоры были 100 мегагерц...
И вы сейчас так рукой махаете, типо а о чём речь? какой миллион? современное железо даже 100000 не потянет.... а вот посмотрим что будет через 20 лет.
Сейчас интел почти подобралась к физическому пределу уменьшения тех процесс. Там, на уровне атомов, уже другие процессы... и кто знает чего за это время там откроют, может процы начнут выпускать по несколько сотен гигагерц, кто знает....
В общем ограничений быть не должно, или оно должно быть запредельным, хотябы 64 бита.

Автор: AMD 17.2.2012, 22:32

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


ограничение на 4 символа удобно для обработки на 32-битных машинах.
никто не мешает сделать ADC 2.0, где SID может быть из 8 символов (чтобы помещаться в 64 битную переменную).
протокол текстовый, ничего не сломается. клиентов переделать - задача на 15 минут.

Автор: nail 18.2.2012, 15:02

Всеравно это будет неприятно.
Вообще не понимаю, почему некоторые данные фиксированной длины не передавать в бинарном виде, ведь там толпа народа собралась, неужели никто не догадался... Пользователи то не видят что там передается, нафига расходовать трафик за зря, ради наглядности.
Вон в контре все пакеты бинарные, получил строку, сразу знаешь где 4 байта - это 32 битный int, прямо копируешь в массив без всяких преобразований.
Сколько бы только на SID, CID, IPv4, U4, IPv6, U6 сэкономили бы трафика...
CID занимает 39 байт, а так бы занимал 25 байт.
IPv6 максимум 39 байт, а так 16 байт.
IPv4 максимум 15 байт, а так 4 байт.
Порт 5 байт, а так 2 байта.
Рано еще на ADC переходить, совершенно сырой и не продуманный протокол, масса потенциала для оптимизации и дополнений.

Автор: gif-t 18.2.2012, 17:06

Чем больше я углубляюсь в ADC, тем больше он поражает меня своим несовершенством и непродуманностью.
И убивает то, что при разработке они даже не спросили пользователей, а с какими проблемами сталкивались они в NMDC, не спросили администраторов крупных хабов, вообще не спросили основных потребителей - русских. С такими ужасными показателями ADC еще долго будет в тени.
У нас есть мозги, нам надо было разработать свой, нормальный, без таких банальных косяков, протокол и поддерживать его. А не тянуть продукт, сделанный забугорными людьми без мозгов.
И они делают DC для небольших локалок, а у нас люди строят на ней серьезные глобальные проекты, гигантские хабы. Их масштабы мыслей не соизмеримы с нашими, однако мы почему-то упрямо не хотим брать всё в свои руки. У нас очень много хороших разработчиков, наш клиент flylink обгоняет по популярность всех! Обидно что инициативы не то что нет, а она даже не приветствуется.

Автор: AMD 20.2.2012, 22:52

тексты/бинари, байты/спрайты, нравится/нет это все шелуха.
настоящая проблема - в организации DC сети: каждый пук любого клиента транслируется на тысячи соединений и никакая экономия пяти байт в заголовке это не исправит.

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

нужно доделать DHT-поиск, чтобы он искал не только по TTH, а полноценно по имени файла. тогда весь поисковый трафик плавно размажется по всей сети и не будет узким местом.

хабы - это точки входа в DHT-сеть и не более того.

Автор: gif-t 23.2.2012, 23:06

Что-то я пытался разобраться с DHT, но нигде нормальной документации с примерами последовательностей подключения и обмена командами не нашел... Пытался даже как-то отснифферить, но ничего не вышло, в бинарных командах непросто разобраться.

Автор: AMD 26.2.2012, 10:12

они не бинарные. это обычные текстовые ADC-команды, пожатые zlib и закрытые RC4 (устаревший шифр. защищает скорее не от взлома, а от технической блокировки на оборудовании провайдера. слегка пришифрованный пакет нельзя классифицировать как DC++ и заблокировать, ведь это также может быть SIP или Skype, чего закрывать нельзя)

в открытом виде DHT-обмен можно посмотреть в окне отладчика в greylink