Протокол IPv6 в протоколе NMDC, Спецификация и тестирование IPv6 в NMDC |
Здравствуйте, гость ( Вход | Регистрация )
Протокол IPv6 в протоколе NMDC, Спецификация и тестирование IPv6 в NMDC |
4.2.2012, 0:12
Сообщение
#41
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Да, как бы неочень получается, продолжим ту тему здесь? Т.к. та тема не в том разделе и я предлагаю серьезно обсужадть не только спецификацию, но и тестировать..?
Моё предложение не слать 2 команды, т.к. хабы и так генерят много трафика, а хорошенько подумать и использовать сложившуюся ситуацию себе наруку. Потому как расплата за ошибки, допущенные сейчас, в будущем может быть очень большая. Т.к. только хаб знает какие к нему присоединены клиенты, я предлагаю все команды, в которых передается ipv6 адрес, дублировать (так сказать, раз уж так получилось, подкорректируем протокол). В общем здесь я опишу как я вижу решение проблемы, а дальше жду ваших комментариев. nmdc expansion by gif-t, with ipv6 support Цель:
Основные положения:
$RevConnectToMe - команда, которую пассивный пользователь отправляет чтобы попросить другого пользователя попросить его инициировать с ним соединение, заменяются одной $RCM. Не используется клиентами на хабах, где администратор пропускает TCP порты в команде UIP. и (описние $RevConnectToMe) Обычная: Цитата $RevConnectToMe [Ник1] [Ник2]| nmdc expansion by gif-t: Цитата $RCM$[Ник_получателя]$[Ник_отправителя]| Пример: $RCM$Вася$Петя| Уточнения:
$ConnectToMe - команда, которую активный пользователь отправляет чтобы попросить другого пользователя инициировать с ним соединение, заменяются одной $CTM (описние $ConnectToMe) Обычная: Цитата $ConnectToMe [Ник_получателя] [IP_отправителя]:[Порт_отправителя]| Пример: $ConnectToMe Вася 10.10.10.10:16437| nmdc expansion by gif-t: Цитата $CTM$[Ник_получателя]$[Ник_отправителя]$[IPv4_TCP_порт]$[IPv6_TCP_порт]| Вариант без IPv6 порта $CTM$Вася$Петя$163$| Вариант когда порты отдаются через $UIP и порты в $CTM не передаются вообще: $CTM$Вася$Петя| Уточнения:
Активный клиент (способный принимать входящие соединения) посылает данную команду на хаб для того, чтобы попросить пользователя [Ник_получателя] инициализировать соединение с ним (IP адрес и иногда порт тому клиенту уже извествен благодаря $UIP). $Search и $MultiSearch (описние $Search) (описние $MultiSearch) Обычная: Цитата Активный: $Search [IP]:[Порт] [Строка_поиска] $Search 10.10.10.10:412 T?T?500000?1?Gentoo$2005 Пассивный $Search Hub:[Ник] [Строка_поиска] $Search Hub:Вася T?T?500000?1?Gentoo$2005 Нет деления структуры на активный и пассивный поиски nmdc expansion by gif-t: Раскрывающийся текст Цитата $SCH$[Режим поиска_активный_пассивный]$[Ник_отправителя]$[Размер_ограничения]$[Максимальный_размер]$[Размер]$[[Тип_данных]$[Строка_поиска]| Активнй режим (Ответ отправляется по протоколу UDP) $SCH$A$Петя$T$T$67$1$Gentoo 2005| Пассивный режим (Ответ отправляется по протоколу TCP через хаб) $SCH$P$Петя$T$T$67$1$Gentoo 2005| Уточнения:
$SR - ответ на поисковый запрос (описние $SR) Нужно проверить, но я думаю эта фукция будет работать с ipv6 без модификации. $MultiSearch (описние $MultiSearch) Не знаю, она в ходу? Я просто не вижу в ней смысла. Хаб должен сам решать как и куда он пересылает поисковые запросы. Моё мнение - модификация команды не нужна. Сразу объявим $SCH как $MultiSearch на линкованых хабах. $UserIP (описние $UserIP) Обычная: Цитата $UserIP [Ник1] [IP1]$$[Ник2] [IP2]$$[Ник3] [IP3]$$ ... $$[НикN] [IPN]$$| nmdc expansion by gif-t: Раскрывающийся текст Цитата $UIP$$[Ник1]$[IPv4]$[Порт_TCP_v4]$[Порт_UDP_v4]$[IPv6]$[Порт_TCP_v6]$[Порт_UDP_v6]$$[Ник2]$[IPv4]$[Порт_TCP_v4]$[Порт_UDP_v4]$[IPv6]$[Порт_TCP_v6]$[Порт_UDP_v6]$$ ... $$[НикN]$[IPv4]$[Порт_TCP_v4]$[Порт_UDP_v4]$[IPv6]$[Порт_TCP_v6]$[Порт_UDP_v6]| Пример с одинковыми портами: $UIP$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$-$-| Пример с разыми портами: $UIP$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$645$486| Пример первый пользователь с разыми портами, второй с одинковыми портами: $UIP$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$645$486$$Петя$192.168.34.64$422$423$2001:470:26:1ef::1$-$-| Пример параметров клиента, рассылаемых командой $UIP хабом, когда клиент соединен с хабом по IPv6. (Т.е. ipv4 адрес не подтвержден и UDPv4 порт заменен на символ "_"): $UIP$$Петя$192.168.34.64$422$_$2001:470:26:1ef::1$645$486| Уточнения:
$ForceMove (описние $ForceMove) Эту команду тоже стоит модифицировать, чтобы клиенту передавалось сразу два IP адреса, IPv6 и IPv4. Далее он сможет выбрать по какому он может устанавливать соединение. Обычная: Цитата $ForceMove [Новый_адрес] nmdc expansion by gif-t: Цитата $FOM$[протокол]$[тип редиректа]$[IPv4]$[Порт_v4]$[IPv6]$[Порт_v6]| Временный редирект на NMDC $FOM$dchub$307$192.168.34.64$422$2001:470:26:1ef::1$645| Перманентный редирект на ADC, клиент меняет запись у себя в фаворитах, если такая имеется. $FOM$adc$301$192.168.34.64$422$2001:470:26:1ef::1$645| Уточнения:
$BotINFO / $HubINFO (описние $BotINFO и $HubINFO) Тут впринципе модификация не требуется, т.к. адрес заполняется вручную администраторорм хаба/ администратором бота. Пуска IPv6 адрес пишется в квадратных скобках. Это конечно усложняет функцию обработки... но несильно, сейчас сам набросал её (вышло +14 строк) Если IPv6 адрес идет после всех других адресов, то сохраняется совместимость со старыми $Supports Добавляем в команду GIFTEXT для идентификации хабов и клиентов, поддерживающих expansion by gif-t -------------------------------------------------------------------------------------------------------------------------------------------- Как видите, 1) Длина команд сильно укоротилась за счет использования трехбайтовых ключей и за счет вынос адресов в команду $UIP 2) Команды очень легко разобрать, т.к. разделитель элементов всегда один - знак $ (в старых командах разделителей много - пробел, двоеточие, знак "$", знак "?"). В адресе IPv6 используется двоеточие для разделения блоков и скобки для отделения порта, т.к. он отделяется тоже двоеточием, - в моём предложении вообще не надо использовать квадратные скобки для разделения ipv6 адреса от порта! В обшем для обработки таких команд выйдет функция минимального размера, максимальной простоты и быстродействия. 3) Предложенная схема абсолютно совместима со старыми (текущими) клиентами. Т.к. старым клиентам отсылаются команды старого типа. В схеме, предложенной Setuper'ом, данные впихиваются в структуру старых команд. Таким образом получаем в его схеме
В моей схеме
Клиент при коннекте через саппортс сообщает хабу о поддержке модифицированных команд GIFTEXT. Отсылает ему эти команды и команды старого типа (не уверен что это правильно, т.к. на стороне хаба по новой команде на мой взгляд очень просто сформировать команду старого типа, но впринципе если уж тк проще, то пускай так и будет). Хаб без всякой нагрузки отсылает без изменения всем клиентам команды того типа, который они поддерживают (старым - старого, новым - нового). Вот и весь принцип... |
|
|
4.2.2012, 23:32
Сообщение
#42
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Вроде разобрался
|
|
|
5.2.2012, 0:49
Сообщение
#43
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Поковырял исходники птохи и посмотрел что реализовано там.
Итак, вот последовательность входа на хаб: Код H->C: $Lock EXTENDEDPROTOCOL... Pk=PtokaX| C->H: $Supports NoHello IPv4|$Key ...|$ValidateNick nick| H->C: $Supports NoHello IPv4| H->C: $Hello nick| C->H: $Version 1,0091|$GetNickList|$MyINFO $ALL ...| C->H: $MyNick nick| Если соединение с хабом происходит по ipv6, то в команде $Supports может быть отослана характеристика IPv4. В этом случае клиент не будет считаться вошедшим на хаб, пока после команды $MyINFO он не отошлёт на хаб через ipv4 команду $MyNick со своим ником. Таким образом клиент подтверждает, что этот ipv4 именно его. Получается у клиента есть 2 ip адреса (ipv4 и ipv6). Что касается команд поиска и соединения, то клиент сам решает какой ip в них отсылать. Вот это грамотный подход. |
|
|
5.2.2012, 1:13
Сообщение
#44
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Setuper, вроде как такой подход был отвергнут еще на первой странице этой темы из-за черезмерного усложнения ради всего-лишь возможности искать по ipv4 и ipv6 сразу? Всетаки установка второго соединения и все последующий действия - это не простая модификация команд, которую предлагаю я...
К томуже, как я ранее сказал, в данном случае правильнее ввести новые команды, а не использовать старые. Старым клиентам принципиально никакой разницы, а новым - обработка гораздо проще.... + нет, чтобы воспользоваться ситуацией и подкорректировать всё под себя, будем слать два раза один и тот же поисковый запрос с разными ip адресами, генерить трафик за просто так.... это глупо и и вообще категорически неразумно. Но если в птохе уже реализовали, то наверно пускай оно так и будет. Хотя лично я с таким подходом вообще не согласен. (никто не желает меня поддержать? у нас еще есть время всё исправить) |
|
|
5.2.2012, 2:02
Сообщение
#45
|
|
Местная ТехПоддержка Группа: Администраторы Сообщений: 1 875 Регистрация: 18.7.2008 Из: Моск. Обл, г. королев, район Болшево Пользователь №: 221 Спасибо сказали: 220 раз |
Цитата установка второго соединения А где оно тут? |
|
|
5.2.2012, 10:32
Сообщение
#46
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Второе соединение устанавливается только для отсылки одной команды: $MyNick. После получения этой команды хаб принудительно закрывает это соединение, сохранив его ipv4 адрес для уже существующего соединения.
|
|
|
5.2.2012, 10:44
Сообщение
#47
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
Если соединение с хабом происходит по ipv6, то в команде $Supports может быть отослана характеристика IPv4. ... Вот это грамотный подход. минусы есть, в сравнении с тем, что я предлагал на предыдущей странице 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. клиент не должен угадывать второй адрес хаба. хаб должен сам его сообщить в команде $Supports может быть отослана характеристика IPv4. В этом случае клиент не будет считаться вошедшим на хаб, пока после команды $MyINFO он не отошлёт на хаб через ipv4 вот это тоже не нравится. коннект на второй адрес всё равно асинхронный, неизвестно когда произойдёт. намного проще не переводить таких юзеров в "отстойник" для ожидающих подтверждения v4 (а в реальном мире могут быть технические проблемы и подтверждение не произойдёт), а разрешить юзеру дополнительно авторизоваться позже в любой момент. даже порт на это дело выделить другой, чтобы не смешивать протоколы. после авторизации второго адреса IP-фильтр в $Search и $ConnectToMe будет узнавать второй адрес и не блокировать его |
|
|
5.2.2012, 11:53
Сообщение
#48
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
1. Ну вообще-то по коду существует ещё характеристика IP64, однако на данный момент она не используется нигде.
2. Ты неправильно понял. Никакого второго входа не происходит, точнее происходит, но с отсылкой всего лишь одной команды, а не полного входа. И схема защищена от подделки, так как пользователь не считается вошедшим, пока не отошлёт эту команду. Другой пользователь не может передать тот же ник в этой команде, так как это возможно сделать только на стадии входа, а не когда либо. Теоретически это конечно возможно, но обычно ты не знаешь когда войдёт тот или иной пользователь. Конечно можно сидеть и сниферить его соединение с хабом, но это специфичный и очень редкий случай. На этот случай защита может быть со стороны клиента. 3. В птохе по всей видимости предполагается, что адреса известны, ибо под них существую строгие настройки на хабе. На ожидание команды $MyNick отводится определенное время ожидания, если за это время она не была отослана, то клиент отключается. Это время достаточно большое чтобы обойти любые неполадки в сети. И это ничем не отличается от времени ожидания любой другой команды входа! |
|
|
5.2.2012, 12:36
Сообщение
#49
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
2. Ты неправильно понял. Никакого второго входа не происходит, точнее происходит, но с отсылкой всего лишь одной команды, а не полного входа. И схема защищена от подделки, так как пользователь не считается вошедшим, пока не отошлёт эту команду. Другой пользователь не может передать тот же ник в этой команде, так как это возможно сделать только на стадии входа, а не когда либо. Теоретически это конечно возможно, но обычно ты не знаешь когда войдёт тот или иной пользователь. Конечно можно сидеть и сниферить его соединение с хабом, но это специфичный и очень редкий случай. На этот случай защита может быть со стороны клиента. ок. я просто посчитал, что дополнительная защита не помешает 3. В птохе по всей видимости предполагается, что адреса известны, ибо под них существую строгие настройки на хабе. самой птохе известны. а клиент-то как узнает? например, клиент заходит на хаб по голому IPv6-адресу или IPv4 DNS от сервиса динамических IP На ожидание команды $MyNick отводится определенное время ожидания, если за это время она не была отослана, то клиент отключается. Это время достаточно большое чтобы обойти любые неполадки в сети. И это ничем не отличается от времени ожидания любой другой команды входа! я о ситуации, когда v6-пакеты ходят, а v4 - не ходят. тогда клиент вообще не сможет зайти на хаб. а можно заранее продумать эту ситуацию и минимизировать проблемы у юзера |
|
|
5.2.2012, 13:59
Сообщение
#50
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
я о ситуации, когда v6-пакеты ходят, а v4 - не ходят. тогда клиент вообще не сможет зайти на хаб. а можно заранее продумать эту ситуацию и минимизировать проблемы у юзера Ну этот контроль уже должен быть на стороне клиента, если не получается отослать $MyNick по ipv4, то значит не дано и клиент должен переподключиться без IPv4 в $Supports. |
|
|
5.2.2012, 14:18
Сообщение
#51
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
Ну этот контроль уже должен быть на стороне клиента, если не получается отослать $MyNick по ipv4, то значит не дано и клиент должен переподключиться без IPv4 в $Supports. когда делаешь протокол, надо думать на 2 хода вперёд. по моему сценарию, если v4-канал недоступен, клиент просто в чат выведет предупреждение. если юзер далёк от технических тонкостей, он просто проигнорирует и будет качать только с некоторых пиров. иначе поднастроит. никто, я уверен, не будет писать логику переподключения с урезанным набором в Supports на второй попытке. то есть костыль прямо таки напрашивается. сначала введут галочку в клиент "не использовать IPv4 при входе на v6-хаб", затем её попросят сделать индивидуально для хаба. и ещё откроют кучу тем на форумах по этой проблеме. зачем, если заранее можно сдлать хорошо. тем более, это не усложняет код, а упрощает (либо никак не влияет). |
|
|
5.2.2012, 16:08
Сообщение
#52
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Невнимательно прочитали... или вообще не прочитали мой второй пост в этой теме. Там я описал что проблема доса - это только проблема поиска. Т.ч. не надо сюда приплетать файлообмен между пользователями, он безопасен без подтверждения второго ip адреса.
Т.о. подтверждение второго ip адреса нужно только для более полного активного поиска. В остальном я с вами согласен, зачем делать костыльно и быстро, если с этим костылем нам потом жить вечность? Сложившуюся ситуацию надо использовать наруку, именно поэтому моё предложение лучше, чем предложение слать подряд две команды старого типа с ipv4 и ipv6. Я немного дополнил свой второй пост снизу, привел все плюсы и минусы решений, у варианта с отсылкой двух команд старого типа вообще нет плюсов. |
|
|
5.2.2012, 16:22
Сообщение
#53
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Вот из-за того, что ты постоянно изменяешь свои посты никто не может уследить за твоими правками. Сегодня одно написано, завтра уже другое!
А читают все только не прочитанные посты (новые). Действительно, зачем читать то, что уже читал. |
|
|
5.2.2012, 16:30
Сообщение
#54
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Я только дописал снизу сравнение, для тех, кто первый раз зашел в тему и не понимает в чем спор. Остальное в посте я не менял.
|
|
|
5.2.2012, 16:38
Сообщение
#55
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Ты изобрёл свой велосипед. Этот велосипед уже изобретён и называется ADC протокол.
Вместо того чтобы адаптировать NMDC хаб на работу с каким-то расширением, лучше адаптировать работу хаба на одновременное взаимодействие по двум протокола NMDC и ADC. Получится тоже самое. То есть, хочешь ipv6 - переходи на ADC! Нужно продвигать новый протокол, а не продолжать накручивать что-то на старый. |
|
|
5.2.2012, 16:53
Сообщение
#56
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Мне не нравится ADC, я хочу продолжать накручивать старый
Тем более добавление 3-х команд - это не накрутка, это однократное, необходимое и малюсенькое дополнение А расписал всё так подробно, потому что меня воротит от черезчур кратких описаний, в которых постоянно нужно что-то догадывать. Например такое отвратительное описание у протокола ADC. А текст моего дополнения охватывает абсолютно все аспекты и ни у кого при его чтении не возникнет вопросов, там нет неоднозначностей. Можно подождать пару неделек, а потом устроить голосование, стоит ли вообще делать поддержку ipv6 или нет, и если да, то по какому варианту. |
|
|
5.2.2012, 17:09
Сообщение
#57
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
По мне так в документации ADC протокола всё понятно описано. Что именно тебе там не нравится?
Ты лучше бы поговорил с разработчиками клиентов, что они об этом думают? |
|
|
5.2.2012, 18:18
Сообщение
#58
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Ну например что
hash() - это обычный TTH Цитата 39-символьный PID декодируется в 24 байта двоичных данных (алгоритмом Base32). затем считаем TTH, как если бы эти 24 байта были записаны в файл. Не нашел я этого, спасибо AMD, что подсказал. Потом я присоединяюсь к хабу - и вижу в CDM отлидчике параметры, которые в протоколе вообще не описаны. И таких неописанных параметров очень много. Приходится гадать какой отвечает за сжатие, какой за еще что-то... Насчет разработчиков клиентов, Павел Пименов молчит, а другим нужно переводить, у меня время будет только на следующих выходных.. |
|
|
5.2.2012, 19:01
Сообщение
#59
|
|
RusHub team lead Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз |
Так это наверное расширения протокола:
Всё отлично описано. |
|
|
5.2.2012, 21:07
Сообщение
#60
|
|
Участник Группа: Пользователи Сообщений: 49 Регистрация: 3.2.2012 Пользователь №: 10 254 Спасибо сказали: 1 раз |
Не нашел описания ключей в INF: AP, FS, KP
А также не нашел ключа, определяющего режим клиента (пассив/актив) и не нашел ключа, определяющего DHT порт. US максимальная скорость закачки (байт/сек), а DS максимальная скорость скачки (байт/сек) - не определено относительно кого? Самого пользователя о котором информация или относительно других пользователей? Не понял почему в INF отсылаются только UDP порты, почему нет TCP???? Ведь если всего лишь отослать TCP порты в INF, можно сразу исключить команду RCM! И при необходимости клиенты могли бы сразу соединялись с нужными им клиентоми, без отсылки команы RCM хабу. У хаба и так других дел полно... Про \s \n и т.д. я вообще молчу, этот мега костыль сразу бросается в глаза. Протокол построен неидеально и явно не продуман до конца... не понимаю, вроде там написано куча народа собралась для его разработки... как вообще такое могло получиться? Надеюсь в следующих версиях введут TCP порты в INF... Цитата Так это наверное расширения протокола: Да, часть есть там... |
|
|
5.2.2012, 21:42
Сообщение
#61
|
|
Начинающий Группа: Пользователи Сообщений: 28 Регистрация: 3.7.2009 Пользователь №: 3 768 Спасибо сказали: 2 раза |
Не нашел описания ключей в INF: AP, FS, KP FS - число свободных слотов. описано в change log для DC++ 0.781 KP - AP - дополнение к VE. раньше было - VE="Flylink r501", а теперь AP=FlyLink, VE=r501. для порядка разделили. по пол-ву байт небольшая разница А также не нашел ключа, определяющего режим клиента (пассив/актив) для пассива I4=0.0.0.0, т.е. внешний IP-адрес не существует и не нашел ключа, определяющего DHT порт разумеется, хаб не знает о DHT Не понял почему в INF отсылаются только UDP порты, почему нет TCP???? Ведь если всего лишь отослать TCP порты в INF, можно сразу исключить команду RCM! И при необходимости клиенты могли бы сразу соединялись с нужными им клиентоми, без отсылки команы RCM хабу. У хаба и так других дел полно... tcp-порт динамический для возможности работы с Socks5. хаб фильтрует все коннекты для обеспечения господства админов (типа, если ты плохой, в наказание качать на этом хабе ничего не сможешь) Про \s \n и т.д. я вообще молчу, этот мега костыль сразу бросается в глаза. Протокол построен неидеально и явно не продуман до конца... не понимаю, вроде там написано куча народа собралась для его разработки... как вообще такое могло получиться? в NMDC тоже есть escape-символы, экранирующие | $ & и прочие служебные. в ADC экранируется только \s \n + принудительная поддержка Unicode - тоже огромный шаг вперёд. US максимальная скорость закачки (байт/сек), а DS максимальная скорость скачки (байт/сек) - не определено относительно кого? Самого пользователя о котором информация или относительно других пользователей? DS пишет сам юзер. например, я указал свою скорость инета (по тарифу) - 40 мегабит. в DS передаётся DS5000000 (5 МБ/с). US совпадает с DS но если выставлен лимитер на up или down, в этих свойствах появляется информация из лимитера, тогда DS и US могут различаться. |
|
|
Похожие темы
|
Сейчас: 23.12.2024, 9:41 |