WikiSort.ru - Не сортированное

Advanced Direct Connect (ADC) — протокол для пиринговых сетей, основанный на протоколе Direct Connect (DC). ADC-клиенты подключаются к центральному серверу и обмениваются файлами напрямую между участниками сети.

Эту статью следует викифицировать. Пожалуйста, оформите её согласно правилам оформления статей.

История создания

Протокол ADC был создан как логическое развитие протокола Direct Connect c целью устранения его недостатков. Инициатором создания нового протокола стали Jacek Sieka в сотрудничестве с Jan Vidar Krey’s DCTNG был подготовлены черновики стандарта. Первая версия протокола появилась в 2004 году, а первый официальный релиз состоялся 1 декабря 2007 года. 2 декабря 2007 года вышла финальная версия протокола ADC 1.0^[1].

В версии 1.0 реализованы (описаны) следующие функции:

• разные шары для каждого хаба (также поддерживается некоторыми клиентами и в NMDC);
• реальная идентификация каждого пользователя (на практике идентификатор легко сменить, так как он генерируется по mac адресу);
• изменение псевдонима пользователя без необходимости переподключения (весьма сомнительное преимущество);
• непосредственный поиск между клиентами (на 18 февраля 2012 ни в одном DC клиенте не реализован);
• улучшенная вместимость хаба (Однако она меньше, чем на NMDC хабах, так как объём исходящего трафика ADC хаба увеличился за счёт экранирования часто встречающихся символов, передачи идентификаторов CID, SID, специфичной структуры команд, каждый блок разделён пробелом и сопровождается 2-х байтовым заголовком, а также множества параметров дополнений);
• передача, защищённая паролем (Tiger Hash) (при включении сильно нагружается процессор, поэтому на практике не используется);
• кодировка UTF-8 (поддерживается также и NMDC протоколом).
• поддержка работы по протоколу IPv6 (расширение для NMDC реализовано в хабе PtokaX и клиенте CzDC).

Недостатки протокола ADC 1.0.1

• экранирование часто встречающихся символов (например символа пробела), увеличивающее трафик.
• количество разделителей по сравнению с протоколом NMDC уменьшено, но не сведено к одному, что необходимо для максимально простой обработки команд.
• лимит пользователей одного хаба — 1 048 575 пользователей (ограничение 20 битного SID’а). Данное ограничение не обойти, поэтому ADC строго фиксирован в плане масштабирования.
• из-за непродуманной системы Feature broadcast клиенты часто вынуждены отправлять несколько команд подряд. Пример — пассивный пользователь с поддержкой Nat-Traversal:

FSCH AAER +TCP4-NAT0 TO4172403789 ANdvdrip

FSCH AAER +NAT0 TO4172403789 ANdvdrip

В первом случае пользователь отправляет запрос всем активным пользователям, во втором всем пассивным, поддерживающим Nat Traversal. Эти запросы нельзя совместить в один, так как поддержка/неподдержка всех перечисленных команд обязательна. Для простой интерплетации между ними можно поставить логическое «и». Возможности указать «или» в протоколе не предусмотрено. Большинство хабов не пропускают вторую команду из-за лимита на количество запросов в единицу времени, и пользователи получают неполные списки ответов. Хабы, пропускающие два идущих подряд поисковых запроса, увеличивают свой трафик вдвое.

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

Это увеличивает частоту пересылок команд и исходящий трафик хабов, что является не необходимым, и даже излишним. В протоколе предусмотрен прямой поиск между клиентами минуя хаб, однако на практике он не был реализован и не поддерживается ни одним клиентом.

• протокол является полностью текстовым, что делает его наглядным для разработчиков (без преобразования), однако увеличивает трафик и вычислительную нагрузку в несколько раз. В протоколе в бинарной форме можно было бы передавать все числа, ключи команд, ключи параметров, ip адреса, порты, tth хеши, SID, CID, PID, и другие данные. Бинарные протоколы обладают существенным преимуществом, в них данные передаются и принимаются без преобразований, в той форме, в которой они хранятся у клиентов и хабов в памяти. Эта значит, что если бы использовался бинарный протокол, при получении очередной команды клиент или хаб могли бы просто скопировать участки команды в соответствующие участки памяти и сразу начать работать с ними(прим. вообще-то так делать все равно нельзя иначе будет дыра в безпасности. так что довольно длительную верификацию все равно делать надо). Одновременно с этим данные в бинарной форме максимально компактны, поэтому в бинарных протоколах не используется повышающее нагрузку на процессор сжатие. Разработчики не смогли обосновать данный выбор, однако для рядовых пользователей и держателей хабов эффективность протокола гораздо предпочтительнее наглядности.
  Частично проблема трафика текстового протокола решена zlib сжатием тел команд, которое также присутствует и в протоколе NMDC. Однако оно ещё больше увеличивает вычислительную нагрузку, так как помимо преобразования типов данных необходимо также производить распаковку и запаковку конечных команд. В протоколе NMDC из-за большой вычислительной нагрузки сжатие получается использовать только на небольших хабах.
• проверка CID’а пользователей, для которой необходимо вычислять хеш от PID’a, также увеличивает вычислительную нагрузку на хабы.

На практике протокол ADC показал гораздо большую гибкость, нежели чем NMDC, однако сильно усугубил проблемы масштабируемости (большого объёма трафика, излишней централизованности и большой вычислительной нагрузки, главным образом на хабы). С уверенностью можно сказать, что протокол ADC не годится для организации глобальных DC хабов и объективно обладает весьма сомнительными преимуществами над протоколом NMDC. Из-за данных качеств среди разработчиков остаётся неопределённость в вопросе необходимости перехода с протокола NMDC на протокол ADC. Администраторы хабов в свою очередь не торопятся переводить свои хабы на данный протокол, ожидая следующей версии, или даже нового протокола, в котором поправят недостатки текущего и, вероятно, сделают бинарным.

Дальнейшая разработка протокола ADC

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

Серверное ПО

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
123 uhub      15   0  5984 4636 1044 S  0.0  0.9   4:08.93 uhub

Клиентское ПО

• AirDC++
• ApexDC++
• FlylinkDC++
• DC++
• RSX++
• StrongDC++
• LinuxDC++
• EiskaltDC++

Примечания

Ссылки

• The ADC Project
• ADC Protocol  (англ.)
• Протокол ADC (перевод Setuper)  (рус.)
• ADC Extensions