|
Здравствуйте, гость ( Вход | Регистрация )
|
![]()
Сообщение
#1
|
|
![]() Участник ![]() ![]() Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз ![]() |
Да, как бы неочень получается, продолжим ту тему здесь? Т.к. та тема не в том разделе и я предлагаю серьезно обсужадть не только спецификацию, но и тестировать..?
Моё предложение не слать 2 команды, т.к. хабы и так генерят много трафика, а хорошенько подумать и использовать сложившуюся ситуацию себе наруку. Потому как расплата за ошибки, допущенные сейчас, в будущем может быть очень большая. Т.к. только хаб знает какие к нему присоединены клиенты, я предлагаю все команды, в которых передается ipv6 адрес, дублировать (так сказать, раз уж так получилось, подкорректируем протокол). В общем здесь я опишу как я вижу решение проблемы, а дальше жду ваших комментариев. nmdc expansion by gif-t, with ipv6 support Цель:
Основные положения:
$RevConnectToMe - команда, которую пассивный пользователь отправляет чтобы попросить другого пользователя попросить его инициировать с ним соединение, заменяются одной $RCM. Не используется клиентами на хабах, где администратор пропускает TCP порты в команде UIP. и (описние $RevConnectToMe) Обычная: Цитата $RevConnectToMe [Ник1] [Ник2]| nmdc expansion by gif-t: Цитата $RCM$[Ник_получателя]$[Ник_отправителя]| Пример: $RCM$Вася$Петя| Уточнения:
$ConnectToMe - команда, которую активный пользователь отправляет чтобы попросить другого пользователя инициировать с ним соединение, заменяются одной $CTM (описние $ConnectToMe) Обычная: Цитата $ConnectToMe [Ник_получателя] [IP_отправителя]:[Порт_отправителя]| Пример: $ConnectToMe Вася 10.10.10.10:16437| nmdc expansion by gif-t: Цитата $CTM$[Ник_получателя]$[Ник_отправителя]$[IPv4_TCP_порт]$[IPv6_TCP_порт]| Вариант без IPv6 порта $CTM$Вася$Петя$163$| Вариант когда порты отдаются через $UIP и порты в $CTM не передаются вообще: $CTM$Вася$Петя| Уточнения:
Активный клиент (способный принимать входящие соединения) посылает данную команду на хаб для того, чтобы попросить пользователя [Ник_получателя] инициализировать соединение с ним (IP адрес и иногда порт тому клиенту уже извествен благодаря $UIP). $Search и $MultiSearch (описние $Search) (описние $MultiSearch) Обычная: Цитата Активный: $Search [IP]:[Порт] [Строка_поиска] $Search 10.10.10.10:412 T?T?500000?1?Gentoo$2005 Пассивный $Search Hub:[Ник] [Строка_поиска] $Search Hub:Вася T?T?500000?1?Gentoo$2005 Нет деления структуры на активный и пассивный поиски nmdc expansion by gif-t: Раскрывающийся текст Цитата $SCH$[Режим поиска_активный_пассивный]$[Ник_отправителя]$[Размер_ограничения]$[Максимальный_размер]$[Размер]$[[Тип_данных]$[Строка_поиска]| Активнй режим (Ответ отправляется по протоколу UDP) $SCH$A$Петя$T$T$67$1$Gentoo 2005| Пассивный режим (Ответ отправляется по протоколу TCP через хаб) $SCH$P$Петя$T$T$67$1$Gentoo 2005| Уточнения:
$SR - ответ на поисковый запрос (описние $SR) Нужно проверить, но я думаю эта фукция будет работать с ipv6 без модификации. $MultiSearch (описние $MultiSearch) Не знаю, она в ходу? Я просто не вижу в ней смысла. Хаб должен сам решать как и куда он пересылает поисковые запросы. Моё мнение - модификация команды не нужна. Сразу объявим $SCH как $MultiSearch на линкованых хабах. $UserIP (описние $UserIP) Обычная: Цитата $UserIP [Ник1] [IP1]$$[Ник2] [IP2]$$[Ник3] [IP3]$$ ... $$[НикN] [IPN]$$| nmdc expansion by gif-t: Раскрывающийся текст Цитата $UIP$$[Ник1]$[IPv4]$[Порт_TCP_v4]$[Порт_UDP_v4]$[IPv6]$[Порт_TCP_v6]$[Порт_UDP_v6]$$[Ник2]$[IPv4]$[Порт_TCP_v4]$[Порт_UDP_v4]$[IPv6]$[Порт_TCP_v6]$[Порт_UDP_v6]$$ ... $$[НикN]$[IPv4]$[Порт_TCP_v4]$[Порт_UDP_v4]$[IPv6]$[Порт_TCP_v6]$[Порт_UDP_v6]| Пример с одинковыми портами: $UIP$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$-$-| Пример с разыми портами: $UIP$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$645$486| Пример первый пользователь с разыми портами, второй с одинковыми портами: $UIP$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$645$486$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$-$-| Пример параметров клиента, рассылаемых командой $UIP хабом, когда клиент соединен с хабом по IPv6. (Т.е. ipv4 адрес не подтвержден и UDPv4 порт заменен на символ "_"): $UIP$$Петя$192.168.34.64$422$_$2001:470:26:1ef::1$645$486| Уточнения:
$ForceMove (описние $ForceMove) Эту команду тоже стоит модифицировать, чтобы клиенту передавалось сразу два IP адреса, IPv6 и IPv4. Далее он сможет выбрать по какому он может устанавливать соединение. Обычная: Цитата $ForceMove [Новый_адрес] nmdc expansion by gif-t: Цитата $FOM$[протокол]$[тип редиректа]$[IPv4]$[Порт_v4]$[IPv6]$[Порт_v6]| Временный редирект на NMDC $FOM$dchub$307$192.168.34.64$422$2001:470:26:1ef::1$645| Перманентный редирект на ADC, клиент меняет запись у себя в фаворитах, если такая имеется. $FOM$adc$301$192.168.34.64$422$2001:470:26:1ef::1$645| Уточнения:
$BotINFO / $HubINFO (описние $BotINFO и $HubINFO) Тут впринципе модификация не требуется, т.к. адрес заполняется вручную администраторорм хаба/ администратором бота. Пуска IPv6 адрес пишется в квадратных скобках. Это конечно усложняет функцию обработки... но несильно, сейчас сам набросал её (вышло +14 строк) Если IPv6 адрес идет после всех других адресов, то сохраняется совместимость со старыми $Supports Добавляем в команду GIFTEXT для идентификации хабов и клиентов, поддерживающих expansion by gif-t ![]() -------------------------------------------------------------------------------------------------------------------------------------------- Как видите, 1) Длина команд сильно укоротилась за счет использования трехбайтовых ключей и за счет вынос адресов в команду $UIP 2) Команды очень легко разобрать, т.к. разделитель элементов всегда один - знак $ (в старых командах разделителей много - пробел, двоеточие, знак "$", знак "?"). В адресе IPv6 используется двоеточие для разделения блоков и скобки для отделения порта, т.к. он отделяется тоже двоеточием, - в моём предложении вообще не надо использовать квадратные скобки для разделения ipv6 адреса от порта! В обшем для обработки таких команд выйдет функция минимального размера, максимальной простоты и быстродействия. 3) Предложенная схема абсолютно совместима со старыми (текущими) клиентами. Т.к. старым клиентам отсылаются команды старого типа. В схеме, предложенной Setuper'ом, данные впихиваются в структуру старых команд. Таким образом получаем в его схеме
В моей схеме
Клиент при коннекте через саппортс сообщает хабу о поддержке модифицированных команд GIFTEXT. Отсылает ему эти команды и команды старого типа (не уверен что это правильно, т.к. на стороне хаба по новой команде на мой взгляд очень просто сформировать команду старого типа, но впринципе если уж тк проще, то пускай так и будет). Хаб без всякой нагрузки отсылает без изменения всем клиентам команды того типа, который они поддерживают (старым - старого, новым - нового). Вот и весь принцип... |
|
|
![]() |
![]()
Сообщение
#2
|
|
![]() Участник ![]() ![]() Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз ![]() |
Собственно говоря продолжение темы с dchublist с уклоном в сторону программирования и RusHub'а.
Как я понял, IPv6 в RusHub'е частично уже поддерживается, но как, совершенно непонятно. Давайте составим спецификацию (если её еще нет, а если есть... покритикуем?), т.к. в этой задаче есть много спорных моментов. Приведу простой пример - поддержка сразу и ipv6 и ipv4 в поисковых запросах, или только ipv6 или ipv4? Первый вариант конечно лучше, но в его случае нужно отсылать сразу 2 адреса, что соответственно изменяет структуру команды search... в общем нужно обмозговать и наверно сделать команду search2, но с уклоном на простоту обработки (хотя search более менее нормально составлена...), хаб пускай разбирает и без изменения отсылает клиентам с поддержкой ipv6, а клиентам с ipv4 отправляет команду старого типа, если в search2 есть ipv4 адрес? И также выкладываем адресочки ipv6 хабов для проверки работоспособности. Пока мне не попадался ниодин хаб, на котором мой клиент мог бы стабильно |
|
|
![]()
Сообщение
#3
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
|
|
|
![]()
Сообщение
#4
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
Во-первых, интересно что такое Gif-t ? Это оно:
Во-вторых, описанное решение проблемы понравилось, но есть некоторые замечания/предложения: 1) Проблема с "хвостом". Возникает неоднозначность, когда порты равны, но есть хвост, и когда порты разные, но хвоста нету. Предлагаю разрешить эту неоднозначность, убрав этот хвост. 2) Все же предлагаю назвать новые команды в стиле ADC. Вместо $cm писать $CTM, а вместо $sh - $SCH. 3) В ADC протоколе к этому делу действительно подошли круче. Там ip адреса передаются в команде INF (аналог $MyINFO для NMDC). Действительно, зачем каждый раз отправлять ip адрес при поиске или при коннекте, когда проще отправить его 1 раз в команде INF, и клиенту известны все ip адреса всех пользователей хаба. 4) По поводу модификации команд со стороны хаба. Конечно это экономия трафика, но для русхаба это к тому же будет значительным ухудшением скорости обработки. Дело в том, что в русхабе используется буферизованния отсылка массовых сообщений (кроме сообщений чата). Другими словами, для того чтобы не оббегать гигантские списки пользователей хаба с целью отослать им какие-то данные, эти данные складываются в буфер, а буфер рассылается время от времени (обычно каждые 2 секунды). На крупных хабах за 2 секунды набежит достаточно много команд которые нужно разослать всем, и все они будут отправлены за один раз из буфера. Кстати, еще нужно придумать название характеристики, которую нужно будет отсылать в команде $Supports. |
|
|
![]()
Сообщение
#5
|
|
![]() Участник ![]() ![]() Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз ![]() |
скорее gif-t - мой ник в сети ) Поэтому я назвал это дополнение протокола expansion by gif-t
![]() 1) Проблема с "хвостом". Я более точно поясню как это должно работать. Проблемы на самом деле нет. 2) Можно назвать и в стиле ADC. Вместо $cm писать $CTM, а вместо $sh - $SCH. Так будет проще не запутаться, но в итоге потеряем 1 байт на команду. 3) Да, надо так сделать, сейчас посмотрю как там 4) Это не проблема, именно модификацию легко уладить, сейчас опишу как. |
|
|
![]()
Сообщение
#6
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
Лучше не модифицировать свои посты, а писать новые, так как приходится перечитывать по нескольку раз, кроме того, при модификации теряется старая версия написанного и сложно отследить логику
|
|
|
![]()
Сообщение
#7
|
|
![]() Участник ![]() ![]() Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз ![]() |
Дописал.
Жду критику. |
|
|
![]()
Сообщение
#8
|
|
![]() Начинающий ![]() Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза ![]() |
обычный dc++ хаб не принимает IP клиента, он смотрит с какого адреса произошло соединение с хабом.
посему, чтобы подтвердить не один адрес, а пару, клиент обязан создать два коннекта (4 и 6) к хабу и криптографическими методами доказать, что они от одного источника (по одной лишь паре адресов v4 и v6 технически невозможно установить, что они принадлежат одному клиенту) соответственно, либо мы строго решаем вопрос аутентификации, либо сознательно на него забиваем, оставляя пространство для махинаций и ДоС-атак (например, Петя с адреса 22.33.44.55 подключается к хабу и говорит - Вася, коннектся на мой IPv6 - и подставяет адрес Миши. так он законнектил Васю с Мишей против их желания) самое простое - юзер открывает две вкладки хаба (по разным адресам - v4 и v6). на одной вкладе - только юзеры v4, на другой - только v6. и ничего в протоколе менять не надо |
|
|
![]()
Сообщение
#9
|
|
![]() Участник ![]() ![]() Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз ![]() |
Нет, давайте не городить с двумы вкладками. Я действительно это не учел.
Надо сообразить чего мы теряем отказываясь от использования сразу двух ip адресов. Получится что если есть 2 пользователя: 1) один ipv6 и ipv4, но так, как принимаем только один адрес - ipv4 2) второй ipv6 Они оба с ipv6 но взаимодействовать не смогут? Нехорошо... Может быть стоит сделать 2 коннекта для подтверждения обоих адресов, а дальше один отбрасывать? И надо посмотреть как в торренте. Лично я не хочу урезать функциональность протокола только потому что что-то там тяжело реализовать. |
|
|
![]()
Сообщение
#10
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
Это уже не дополнение какое-то, а попытка переделать протокол и создать что-то наподобие уже созданного ADC протокола.
Очень сложно. Особенно механизм отправки сразу нескольких команд $INF, $CTM. Наша ведь задача научиться узнавать ip адрес. Наверное логично смотреть в сторону уже существующих команд, дабы не усложнять. Предлагаю смотреть в сторону команды: |
|
|
![]()
Сообщение
#11
|
|
![]() Участник ![]() ![]() Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз ![]() |
Я описал $UserIP с ipv6 как $UIP.
Для коннекта пользователей пускай клиенты используют оба адреса как им нравится. А в поиске - только один. Так? Помоему нормальное решение... клиент при активном поиске указывает свой 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? |
|
|
![]()
Сообщение
#12
|
|
![]() Начинающий ![]() Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза ![]() |
И надо посмотреть как в торренте. Лично я не хочу урезать функциональность протокола только потому что что-то там тяжело реализовать. в торренте тупо. зашёл на трекер по v6 - ты точно v6, зашёл по v4 - ты v4 и тебе трекер отдаёт список v4-пиров. смешение 6 и 4 происходит через DHT, однако эти сети полностью разделены и независимы Цитата There are two distinct DHTs: the IPv4 DHT, and the IPv6 DHT. The two DHTs are independent, meaning that no IPv6 data is stored in the IPv4 DHT, and, conversely, no IPv4 data is stored in the IPv6 DHT. A node wishing to participate in both DHTs must maintain two distinct routing tables, one for IPv4 and one for IPv6. нашлись альтернативные источники в DHT v6 - вот и качаешь с них Передаем только тот адрес, по которому клиент соединен с хабом, а также TCP порт для установки соединения и UDP порт для ловли поисковых ответов. Так? откуда-ж мы порты знаем? надо ещё менять команду $MyInfo, чтобы она отдавала все эти порты. тогда прощай работа через Socks5 в активном режиме, когда нет постоянного входящего порта, а он открывается каждый раз новый по необходимости |
|
|
![]()
Сообщение
#13
|
|
![]() Участник ![]() ![]() Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз ![]() |
Цитата в торренте тупо. зашёл на трекер по v6 - ты точно v6, зашёл по v4 - ты v4 и тебе трекер отдаёт список v4-пиров. Ну значит я предлагаю сделать круче, чем сделано у них. Цитата откуда-ж мы порты знаем? Дак яж предложил для этого $UIP. Она передается: клиент -> хаб (при входе, при этом хаб вырезает UPD порт ip адреса, отличного от того, по которому клиент к нему присоединен и сохраняет её) хаб -> клиенты (тоже при входе) Отсылается она как $UserIP, один раз, при входе, после отсылки списка $MyINFO Далее полученные адреса используется в $CTM и $SCH для поиска и установки соединения соответственно. Стандартные команды при этом не затрагиваются, они продолжают работать только на ipv4, ибо с ними больше ничего не сделать... хотя можно влепить в них адреса и сделать их для всех старых клиентов кривыми... по вашему это правильно? А на ipv6 мы строим надстройку в протоколе из $UIP + $CTM и $SCH, которая более функциональна и + старые клиенты при получении просто игнорируют эти команды. Но получать их они не должны, т.к. хаб для них должен транслировать команды старого типа. Откорректировал описание $UIP для дособезопасности. |
|
|
![]()
Сообщение
#14
|
|
![]() Начинающий ![]() Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза ![]() |
как-то всё слишком сложно. сразу нифига ничего не будет в клиентах, особенно в старых и упёртых Апексах.
нужно, чтобы пользователи как можно меньше замечали двойственность адресов и старые клиенты работали на полную моё предложение: 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 |
|
|
![]()
Сообщение
#15
|
|
![]() Участник ![]() ![]() Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз ![]() |
Цитата как-то всё слишком сложно. сразу нифига ничего не будет в клиентах, особенно в старых и упёртых Апексах. А чего сожного, я предлогаю для новых клиентов старые команды заменить тремя новыми $UserIP -> $UIP $ConnectToMe и $RevConnectToMe -> $CTM $Search -> $SCH. А старым слать старые. Больше ничего грандиозного..., всё очень просто... структура команд для обработки очень проста, они разбираются легко в цикле из 4-х строк. + Получаем огромный выигрышь в трафике. Цитата моё предложение: Ну можно и так, это конечно на порядок сложнее моего предложения, но зато поиск будет работать по обоим протоколам. В моём предложении поиск работает только по тому, по которому установлено соединение с хабом. А вот функции установки соединения между пользователями ни там, ни там не ограничены. Я думаю тут нужно послушать мнение хабописателя ) Стоит ли ради улучшения поиска писать такую функцию... наверно стоит? |
|
|
![]()
Сообщение
#16
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
Нужно как можно меньше модификации.
Итак, есть критерий: защита от 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&a...ost&p=42402 но только с отправкой только 1 команды, узнав предварительно тип ip адреса противоположной стороны посредствам команды $UserIP. |
|
|
![]()
Сообщение
#17
|
|
![]() Участник ![]() ![]() Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз ![]() |
Setuper дак ужеж решили эти проблемы. Читайте выше. Я уже передаю два адреса сразу вместе с портами, и всего один раз, при коннекте командо $UIP. При этом моё решение проблемы уменьшает трафик хаба от обычного.
А ваше решение какраз огород. Ради какого-то IPv6 увеличивать трафик от хаба в 2 раза + путать старые клиенты командами, которые для них кривые. Непонятно как старый клиент поведет, когда получит в $Search ip адрес в виде квадратной скобки и 4-х буково, и после еще множество портов, тоже в виде буковок. |
|
|
![]()
Сообщение
#18
|
|
![]() Начинающий ![]() Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза ![]() |
А чего сожного, я предлогаю для новых клиентов старые команды заменить тремя новыми $UserIP -> $UIP $ConnectToMe и $RevConnectToMe -> $CTM $Search -> $SCH. А старым слать старые. юз-кейс: старый клиент хочет скачать с нового, у него ничего не получается, он уходит с хаба ))) очень важно, чтобы как можно больше старых клиентов работали полноценно. быстро сделает новый клиент только Fly, а остальные (gl и т.п.) просто не будут менять клиента из-за одного хаба. и не надо огород городить ;) |
|
|
![]()
Сообщение
#19
|
|
![]() Участник ![]() ![]() Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз ![]() |
Цитата юз-кейс: старый клиент хочет скачать с нового, у него ничего не получается, он уходит с хаба ))) Дак написано же, а старым слать старые! Т.е. старые клиенты будут полноценно работать по IPv4. Они только не будут получать команды от клиентов, которые работают ТОЛЬКО по ipv6. От ipv6&ipv4 и ipv4 only клиентов они будут получать не $SCH, а старый $Search с ipv4 адресом внутри. Т.е. мои команды никоим образом не вредят и не мешают старым клиентам. |
|
|
![]()
Сообщение
#20
|
|
![]() Начинающий ![]() Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза ![]() |
|
|
|
![]() ![]() |
Похожие темы
![]() |
Сейчас: 8.9.2024, 2:38 |