Advanced Direct Connect | это... Что такое Advanced Direct Connect? (original) (raw)
Advanced Direct Connect (ADC) — протокол для пиринговых сетей, основанный на протоколе Direct Connect (DC). ADC-клиенты подключаются к центральному серверу и обмениваются файлами напрямую между участниками сети.
Содержание
- 1 История создания
- 2 Недостатки протокола ADC 1.0.1
- 3 Дальнейшая разработка протокола ADC
- 4 Серверное ПО
- 5 Клиентское ПО
- 6 Примечания
- 7 Ссылки
История создания
Протокол 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 также разрабатывается дополнение для его частичной поддержки, но на момент 18 февраля 2012 не существует рабочих хабов и клиентов)
Недостатки протокола 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 года. Последнее дополнение для протокола было опубликовано в ноябре 2012 года (версия 1.0.7). Протокол активно развивается и разработчики стараются устранить имеющиеся недостатки. Официальных заявлений об окончании разработки протокола не поступало, однако уже сейчас многие клиенты поддерживают это протокол, что может свидетельствовать о скорой замене NMDC.
Серверное ПО
ADCH++
ADCH++ — это хаб для сетей, использующих ADC-протокол. Он работает на Windows / Unix платформах, поддерживает скрипты lua и python, а также плагины, написанные на С++. Начиная с версии 2.5.2 добавлена поддержка выполнения плагинов от PtokaX
Для хаба активно разрабатывается графический интерфейс в проекте ADCH++ GUI.
Сайт проекта ADCH++ GUI в данное время не актуален((
DSHub
DSHub написан на кроссплатформенном языке программирования Java (требуется JRE 1.6 и новее). Может управляться через консоль на сервере, графический интерфейс, чат ADC клиента. Имеется возможность осуществлять фильтрацию чата\личных сообщений\поиска через механизм chatcontrol с использованием regex правил. Хаб находится в активной разработке. На данный момент ПО хаба достаточно стабильно и подходит для организации хабов до 1000 пользователей (на лето 2008 г.). Имеется интерфейс для расширений на языках Java и python. В январе 2009 года автор приостановил работу над данным хабом.
luadch
luadch — ADC-хаб, написанный на C, C++, Lua и функционирует в операционных системах MinGW/MSYS/NT/2000/XP и Linux/BSD/UNIX-like. Для сценариев используется язык Lua, что позволяет легко вносить дополнительный функционал. Имеются небольшие проблемы со стабильностью (в версии 0.08). Подходит для организации хабов до 1000 пользователей и выше.
µHub
µHub (micro-Hub) — ADC хаб написанный на C под лицензией GPLv3. Работает в операционных системах Linux, Windows, BSD и других. Имеет только базовый функционал для p2p. Крайне нетребователен к ресурсам — при 350 пользователях занимает в памяти несколько десятков килобайт ОЗУ. Возможна работа на устройствах поддерживающих ПО OpenWRT. Начиная с версии 0.3.2 поддерживает шифрование server-client, так называемую ADCS-mode. Начиная с версии 0.4.0 введена система плагинов с простым API и добавлены некоторые особо востребованные плагины. Тестовый хаб автора: adcs://adc.extatic.org:1511
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
Инструкция по настройке и запуску | Быстрый запуск в Ubuntu | Пакеты для Debian и Ubuntu
EADC
EADC-hub (Erlang ADC) — ADC-хаб, написанный на Erlang. Реализация ADC не является полной, есть команды чата и поддержка плагинов (на языке Erlang). Компиляция возможна на всех платформах, поддерживаемых Erlang, включая Windows, Linux, Mac OS X. (К сожалению, автор ещё не добавил существующий код расчета TIGER на Erlang в свой проект, и программа до сих пор используется библиотеку, написанную на C). Возможности языка Erlang позволяют хабу иметь свойства, подобные Ejabberd, в частности кластеризацию и обновление кода без остановки сервера.
StarLet ADC
StarLet ADC Hub — ПО ADC хаба под OpenVMS соответствие со спецификацией ADC 1.0, написан на C с использованием средств OpenVMS, что обуславливает высокую нагрузочную способность хаба, а также надёжность функционирования, в настоящий момент находится в разработке. Тестовая P2P-сеть, поддерживаемая StarLet ADC Хаб-ом — доступна по ссылке [adc://adc.deltatel.ru:412] (Nick/Username и пароль может быть любым и непустым). StarLet ADC — доступен в исходных текстах.
Одной из отличительных возможностей Хаб-а является «виртуальная P2P-сеть», что позволяет строить P2P-сети на одной платформе (OpenVMS Cluster) для различных групп пользователей.
Рабочий каталог проекта StarLet ADC
Клиентское ПО
- AirDC++
- ApexDC++
- FlylinkDC++
- DC++
- RSX++
- StrongDC++
- LinuxDC++
- EiskaltDC++
Примечания
Ссылки
- The ADC Project
- ADC Protocol (англ.)
- Протокол ADC (перевод Setuper) (рус.)
- ADC Extensions