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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

FS - число свободных слотов. описано в change log для DC++ 0.781
KP - http://forums.apexdc.net/topic/3075-keyp-k...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 могут различаться.

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

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

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

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


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


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

минусы есть, в сравнении с тем, что я предлагал на предыдущей странице
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 будет узнавать второй адрес и не блокировать его

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

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

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

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



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



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

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

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

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

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

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

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

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

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


http://xkcd.com/927/
;)

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

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

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

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

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


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

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

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

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

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