Прямое подключение (протокол)
Часть серии о |
Обмен файлами |
---|
Direct Connect ( DC ) — это одноранговый протокол обмена файлами . Клиенты Direct Connect подключаются к центральному концентратору и могут загружать файлы напрямую друг от друга. Advanced Direct Connect можно считать протоколом-преемником.
Хабы содержат список клиентов или пользователей, подключенных к ним. Пользователи могут искать файлы и скачивать их из других клиентов, а также общаться в чате с другими пользователями.
История
[ редактировать ]как компания, финансируемая рекламным ПО Direct Connect. NeoModus была основана Джоном Хессом в ноябре 1999 года, когда он учился в старшей школе, [ 1 ]
Первый сторонний клиент назывался «DClite», который никогда полностью не поддерживал аспекты протокола совместного использования файлов. Hess выпустил новую версию Direct Connect, требующую простой ключ шифрования для инициации соединения и блокирующую сторонние клиенты. Ключ шифрования был взломан, и автор DClite выпустил новую версию DClite, совместимую с новым программным обеспечением от NeoModus. Некоторое время спустя DClite был переписан как Open Direct Connect с целью иметь пользовательский интерфейс MDI и использовать плагины для протоколов обмена файлами (аналогично MLDonkey ). Open Direct Connect также не имел полной поддержки всех аспектов протокола совместного использования файлов, однако порт на Java имел ее. Позже другие клиенты, такие как DCTC (текстовый клиент Direct Connect) и DC++ стали популярными .
Архив DCDev [ 2 ] содержит обсуждения изменений протокола для развития DC в 2003–2005 годах.
Протокол
[ редактировать ]Протокол Direct Connect представляет собой текстовый компьютерный протокол, в котором команды и их информация передаются в виде открытого текста, без шифрования в оригинальном программном обеспечении NeoModus ( шифрование доступно как расширение протокола). Клиенты подключаются к центральному серверу, действующему как «концентратор». Этот концентратор обеспечивает обнаружение контента и позволяет клиентам согласовывать прямые соединения между собой для передачи контента. Поскольку этот центральный концентратор имеет дело только с метаданными, к нему не предъявляются такие же требования к пропускной способности, как если бы он также обслуживал сам контент; По оценкам, для обработки 1000 пользователей потребуется полоса пропускания около 2,5 Мбит/с. [ 3 ]
Официальной спецификации протокола не существует, а это означает, что каждый клиент и концентратор (кроме исходного клиента и концентратора NeoModus) был вынужден реконструировать информацию. Таким образом, любая спецификация протокола, на которую может ссылаться эта статья, скорее всего, является неточной и/или неполной. [ 4 ]
Клиент-серверный аспект протокола (а также клиент-клиент, где один клиент действует как «сервер») предусматривает, что сервер отвечает первым при установлении соединения. концентратора Например, когда клиент подключается к сокету , концентратор первым отвечает клиенту.
В протоколе отсутствует указанная кодировка символов по умолчанию для клиентов или концентраторов. Исходный клиент и концентратор используют кодировку ASCII вместо кодировки операционной системы . Это позволяет перейти на UTF-8 кодировку в более новом программном обеспечении.
Порт 411 является портом по умолчанию для концентраторов, а порт 412 — для соединений клиент-клиент. Если какой-либо из этих портов уже используется, номер порта увеличивается до тех пор, пока не будет найден номер свободного порта для использования. Например, если используются 411, 412 и 413, то будет использоваться порт 414.
Адреса концентраторов имеют следующий вид: dchub://example.com[:411], где 411 — необязательный порт.
Глобальной схемы идентификации не существует; вместо этого пользователи идентифицируются по своему псевдониму на основе каждого концентратора.
Входящий запрос на соединение клиент-клиент не может быть связан с реальным соединением. [ 5 ]
Результат поиска не может быть связан с конкретным поиском. [ 6 ]
Возможность выгнать или переместить (перенаправить) пользователя в другой хаб поддерживается протоколом. Если пользователя выгнали, хаб не обязан сообщать этому пользователю конкретную причину, и нет никаких ограничений на то, куда можно перенаправить пользователя. Однако, если другой клиент, обладающий властью, приказывает хабу отключиться, этот клиент может перед этим отправить уведомление. Перенаправление пользователя должно сопровождаться причиной. не существует Эквивалента HTTP-реферера .
Концентраторы могут отправлять пользовательские команды клиентам. Эти команды представляют собой необработанные команды протокола и используются в основном для упрощения конкретной задачи. Например, хаб не может отправить пользовательскую команду, которая запустит браузер по умолчанию для посещения веб-сайта. Однако он может добавить команду «+rules» (где «+» указывает концентратору, что это команда — это может отличаться) для отображения правил концентратора.
Одноранговая часть протокола основана на концепции «слотов» (аналогично количеству открытых вакансий для вакансии). Эти слоты обозначают количество людей, которым разрешено загружать файлы у пользователя в любой момент времени и которые контролируются клиентом.
В соединениях клиент-клиент стороны генерируют случайное число, чтобы определить, кому следует разрешить загрузку первым, и побеждает клиент с большим числом.
Для транспортировки загрузок и подключения к хабу требуется TCP , а для активного поиска используется UDP .
Существует два типа режимов, в которых может находиться пользователь: «активный» или «пассивный». Клиенты, использующие активный режим, могут загружать данные от любого другого пользователя в сети, тогда как клиенты, использующие пассивный режим, могут загружать данные только от активных пользователей. В NeoModus Direct Connect пользователи пассивного режима получают результаты поиска других пользователей пассивного режима, но пользователь не сможет ничего скачать. В DC++ пользователи не будут получать эти результаты поиска. В NeoModus Direct Connect всем пользователям будет отправлено не более пяти результатов поиска по каждому запросу. Если пользователь выполнил поиск, DC++ ответит десятью результатами поиска, когда пользователь находится в активном режиме, и пятью, когда пользователь находится в пассивном режиме. Пассивные клиенты будут отправлять результаты поиска через хаб, а активные клиенты будут получать результаты напрямую.
протокола Разделителями являются «$», «|» и U+0020 ПРОСТРАНСТВО . Протокол имеет для них (и некоторых других) escape-последовательность , и большинство программ правильно используют их при входе в систему. (Привязка к ключу). По какой-то причине эту escape-последовательность разработчики DC++ проигнорировали и используют HTML- эквивалент, если эти символы должны быть просмотрены пользователем.
Постоянный интерес существует к таким функциям, как рейтинги и языковые пакеты. Авторы DC++ также предложили полную замену протокола Direct Connect под названием ADC, или неофициально, Advanced Direct Connect. ADC использует ту же топологию сети , концепции и терминологию, что и исходный протокол. [ 7 ]
Одним из примеров дополнительной функции протокола по сравнению с исходным протоколом является широковещательная передача Tiger-Tree хеширования общих файлов (TTH). Преимущества этого включают проверку правильности загрузки файла и возможность поиска файлов независимо от их имен.
Direct Connect используется для DDoS-атак
[ редактировать ]Поскольку протокол позволяет концентраторам перенаправлять пользователей на другие концентраторы , вредоносные концентраторы перенаправляют пользователей в места, отличные от реальных концентраторов Direct Connect, что фактически вызывает распределенную атаку типа «отказ в обслуживании» . Концентраторы могут изменять IP-адрес в клиентских соединениях, указывая на потенциальную жертву. [ 8 ] [ 9 ] [ 10 ]
Эксплойт CTM появился в 2006–2007 годах, когда вся сеть Direct Connect пострадала от DDoS-атак. [ 11 ] [ 12 ] Ситуация побудила разработчиков более серьёзно отнестись к вопросам безопасности. [ 13 ]
По состоянию на февраль 2009 г. [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 12 ] было предложено расширение для клиентов , чтобы атакуемая сторона могла узнать хаб, отправляющий подключающихся пользователей.
Фонд сети Direct Connect
[ редактировать ]Фонд Direct Connect Network Foundation (DCNF) — это некоммерческая организация, зарегистрированная в Швеции, целью которой является улучшение сети постоянного тока путем улучшения программного обеспечения, протоколов и других услуг в сети. [ 18 ]
Статьи и статьи
[ редактировать ]DCNF ведет список статей, документов и другой документации, относящейся к DC. [ 19 ]
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Аннали Ньюитц (июль 2001 г.). «Обмен данными» . Метро, еженедельная газета Кремниевой долины . Metro Publishing Inc. Архивировано из оригинала 21 января 2021 г. Проверено 16 октября 2006 г.
- ^ Архив DCDev. Архивировано 20 декабря 2016 г. на Wayback Machine.
- ^ Фредрик Ульнер (апрель 2007 г.). «Оценки команд и пропускной способности в NMDC» . DC++: Только эти парни, понимаешь? Архивировано из оригинала 16 октября 2007 г. Проверено 27 июля 2007 г.
- ^ «Протокол NMDC» . Nmdc.sourceforge.net . Архивировано из оригинала 10 февраля 2017 г. Проверено 4 декабря 2016 г.
- ^ «Токены CTM в ADC (или чем ужасен протокол NMDC, часть 2)» . DC++: Только эти парни, понимаешь? Август 2007 г. Архивировано из оригинала 15 октября 2007 г. Проверено 7 октября 2007 г.
- ^ Тодд Педерзани (июнь 2006 г.). «Фильтрация Redux» . DC++: Только эти парни, понимаешь? Архивировано из оригинала 15 октября 2007 г. Проверено 31 августа 2007 г.
- ^ Яцек Сиека и Фредрик Ульнер (январь 2019 г.). «Протокол АЦП» . ДКНФ. Архивировано из оригинала 01 декабря 2020 г. Проверено 21 декабря 2020 г.
- ^ Пол Соп (май 2007 г.). «Пролексическое распределенное оповещение об атаке типа «отказ в обслуживании»» . Пролексик Технологии Инк . Prolexic Technologies Inc. Архивировано из оригинала 3 августа 2007 г. Проверено 22 августа 2007 г.
- ^ Роберт Лемос (май 2007 г.). «Одноранговые сети, используемые для DOS-атак» . БезопасностьФокус. Архивировано из оригинала 24 сентября 2015 г. Проверено 22 августа 2007 г.
- ^ Фредрик Ульнер (май 2007 г.). «Отрицание распределенных атак» . DC++: Только эти парни, понимаешь? Архивировано из оригинала 15 марта 2016 г. Проверено 22 августа 2007 г.
- ^ Ульнер, Фредерик (17 января 2008 г.). «Сообщение в прессе об использовании DC в качестве инструмента DDoS» . DC++: Только эти парни, понимаешь? Архивировано из оригинала 23 сентября 2016 г. Проверено 19 мая 2017 г.
- ^ Перейти обратно: а б Фредрик Ульнер (20 июля 2011 г.). «Давно не было ответа на использование DC в качестве инструмента DDoS» . DC++: Только эти парни, понимаешь? Архивировано из оригинала 8 сентября 2011 г. Проверено 20 июля 2011 г.
- ^ Фуртуна, Адриан (июль 2008 г.). «DC++ и DDoS-атаки» (PDF) . Архивировано (PDF) из оригинала 9 ноября 2016 г. Проверено 19 мая 2017 г.
- ^ Ян Видар Крей (февраль 2009 г.). «Реферальное расширение» . Страница запуска DC++. Архивировано из оригинала 12 августа 2011 г. Проверено 11 февраля 2009 г.
- ^ Ян Видар Крей (февраль 2009 г.). «Реферальное расширение на вики ADCPortal» . ADCPortal.com. Архивировано из оригинала 7 июля 2011 г. Проверено 11 февраля 2009 г.
- ^ Евгений Христов (февраль 2009 г.). «DC++ указывает на испорченное» . DC++: Только эти парни, понимаешь? Архивировано из оригинала 9 марта 2009 г. Проверено 11 февраля 2009 г.
- ^ Тост (январь 2009 г.). «Обзор СТМ и ошибки прошлого» . ADCПортал. Архивировано из оригинала 7 июля 2011 г. Проверено 27 января 2009 г.
- ^ «DCNF — Фонд сети прямого подключения» . Архивировано из оригинала 25 января 2016 г. Проверено 7 января 2016 г.
- ^ Фонд Direct Connect Network: документы и ресурсы, заархивированные 20 декабря 2016 г. в Wayback Machine.