stringtranslate.com

Прямое подключение (протокол)

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

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

История

NeoModus была основана как компания, финансируемая рекламным ПО «Direct Connect» Джоном Хессом в ноябре 1999 года, когда он учился в старшей школе. [1]

Первый сторонний клиент назывался «DClite», который никогда полностью не поддерживал аспекты обмена файлами протокола. Hess выпустил новую версию Direct Connect, требующую простой ключ шифрования для инициирования соединения, блокируя сторонних клиентов. Ключ шифрования был взломан, и автор DClite выпустил новую версию DClite, совместимую с новым программным обеспечением от NeoModus. Некоторое время спустя DClite был переписан как Open Direct Connect с целью иметь пользовательский интерфейс MDI и использовать подключаемые модули для протоколов обмена файлами (похожих на MLDonkey ). Open Direct Connect также не имел полной поддержки всех аспектов обмена файлами протокола, но порт на Java имел. Позже другие клиенты, такие как DCTC (Direct Connect Text Client) и 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 referer отсутствует.

Хабы могут отправлять пользовательские команды клиентам. Эти команды являются только командами сырого протокола и используются в основном для упрощения определенной задачи. Например, хаб не может отправить пользовательскую команду, которая заставит браузер по умолчанию посетить веб-сайт. Однако он может добавить команду "+rules" (где "+" указывает хабу, что это команда - это может отличаться) для отображения правил хаба.

Одноранговая часть протокола основана на концепции «слотов» (аналогично количеству открытых позиций для работы). Эти слоты обозначают количество людей, которым разрешено скачивать у пользователя в любой момент времени, и контролируются клиентом.

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

Для передачи загрузок и подключения к концентратору требуется протокол TCP , тогда как для активного поиска используется протокол UDP .

Пользователь может находиться в двух режимах: «активном» или «пассивном». Клиенты, использующие активный режим, могут загружать данные от любого пользователя сети, в то время как клиенты, использующие пассивный режим, могут загружать данные только от активных пользователей. В NeoModus Direct Connect пользователи пассивного режима получают результаты поиска других пользователей пассивного режима, но сам пользователь не сможет ничего загрузить. В DC++ пользователи не получат эти результаты поиска. В NeoModus Direct Connect всем пользователям будет отправлено не более пяти результатов поиска на запрос. Если пользователь выполнил поиск, DC++ ответит десятью результатами поиска, когда пользователь находится в активном режиме, и пятью, когда пользователь находится в пассивном режиме. Пассивные клиенты будут отправлять результаты поиска через концентратор, в то время как активные клиенты будут получать результаты напрямую.

Разделителями протокола являются "$", "|" и U+0020 ПРОБЕЛ  . Протокол имеет для них (и нескольких других) escape-последовательность , и большинство программ правильно используют их в последовательности входа (Lock to Key). По какой-то причине эта escape-последовательность была проигнорирована разработчиками DC++, и они используют эквивалент HTML, если эти символы должны быть видны пользователю.

Продолжается интерес к таким функциям, как рейтинги и языковые пакеты. Авторы DC++ также предложили полную замену протокола Direct Connect, названную ADC, или неофициально Advanced Direct Connect. ADC использует ту же топологию сети , концепции и терминологию, что и исходный протокол. [7]

Одним из примеров дополнительной функции протокола, по сравнению с исходным протоколом, является трансляция Tiger-Tree Hashing общих файлов (TTH). Преимущества этого включают проверку того, что файл загружен правильно, и возможность находить файлы независимо от их имен.

Прямое подключение используется для DDoS-атак

Поскольку протокол позволяет концентраторам перенаправлять пользователей на другие концентраторы , вредоносные концентраторы перенаправляли пользователей в места, отличные от реальных концентраторов Direct Connect, что фактически приводило к атаке Distributed Denial of Service . Концентраторы могут изменять IP в клиентских соединениях, указывая на потенциальную жертву. [8] [9] [10]

Уязвимость CTM появилась в 2006–2007 годах, в этот период вся сеть Direct Connect пострадала от DDoS-атак. [11] [12] Эта ситуация побудила разработчиков более серьезно отнестись к вопросам безопасности. [13]

По состоянию на февраль 2009 г. [14] [15] [16] [17] [12] было предложено расширение для клиентов , позволяющее атакуемой стороне узнать концентратор, отправляющий подключающихся пользователей.

Фонд сети прямого подключения

Фонд сети прямого подключения (DCNF) — некоммерческая организация, зарегистрированная в Швеции, целью которой является улучшение сети постоянного тока путем улучшения программного обеспечения, протоколов и других услуг в сети. [18]

Статьи и доклады

DCNF ведет список статей, документов и другой документации, которая относится к DC. [19]

Смотрите также

Ссылки

  1. ^ Аннали Ньюиц (июль 2001 г.). «Обмен данными». Metro, еженедельная газета Кремниевой долины . Metro Publishing Inc. Архивировано из оригинала 21.01.2021 . Получено 16.10.2006 .
  2. ^ Архив DCDev Архивировано 2016-12-20 на Wayback Machine
  3. ^ Фредрик Ульнер (апрель 2007 г.). «Оценки команд и пропускной способности в NMDC». DC++: Just These Guys, Ya Know?. Архивировано из оригинала 2007-10-16 . Получено 2007-07-27 .
  4. ^ "Протокол NMDC". Nmdc.sourceforge.net . Архивировано из оригинала 2017-02-10 . Получено 2016-12-04 .
  5. ^ "Токены CTM в ADC (или почему протокол NMDC ужасен, часть 2)". DC++: Just These Guys, Ya Know?. Август 2007. Архивировано из оригинала 2007-10-15 . Получено 2007-10-07 .
  6. ↑ Тодд Педерзани (июнь 2006 г.). «Filtering Redux». DC++: Just These Guys, Ya Know?. Архивировано из оригинала 2007-10-15 . Получено 2007-08-31 .
  7. ^ Яцек Сиека и Фредрик Ульнер (январь 2019 г.). «Протокол ADC». DCNF. Архивировано из оригинала 2020-12-01 . Получено 2020-12-21 .
  8. ^ Пол Соп (май 2007 г.). "Prolexic Distributed Denial of Service Attack Alert". Prolexic Technologies Inc. Prolexic Technologies Inc. Архивировано из оригинала 2007-08-03 . Получено 2007-08-22 .
  9. ^ Роберт Лемос (май 2007 г.). «Пир-ту-пир сети кооптированы для DOS-атак». SecurityFocus. Архивировано из оригинала 2015-09-24 . Получено 2007-08-22 .
  10. ^ Фредрик Ульнер (май 2007 г.). «Отрицание распределенных атак». DC++: Just These Guys, Ya Know?. Архивировано из оригинала 2016-03-15 . Получено 2007-08-22 .
  11. ^ Ульнер, Фредерик (17.01.2008). «Освещение в прессе относительно использования DC в качестве инструмента DDoS». DC++: Just These Guys, Ya Know?. Архивировано из оригинала 23.09.2016 . Получено 19.05.2017 .
  12. ^ Фредрик Ульнер (2011-07-20). «Давно потерянный ответ относительно использования DC в качестве инструмента DDoS». DC++: Just These Guys, Ya Know?. Архивировано из оригинала 2011-09-08 . Получено 2011-07-20 .
  13. ^ Фуртунã, Адриан (июль 2008 г.). "DC++ и DDoS-атаки" (PDF) . Архивировано (PDF) из оригинала 2016-11-09 . Получено 2017-05-19 .
  14. ^ Ян Видар Крей (февраль 2009 г.). "Расширение рефералов". Страница DC++ Launchpad. Архивировано из оригинала 2011-08-12 . Получено 2009-02-11 .
  15. ^ Ян Видар Крей (февраль 2009 г.). "Расширение рефералов на вики ADCPortal". ADCPortal.com. Архивировано из оригинала 2011-07-07 . Получено 2009-02-11 .
  16. ↑ Eugen Hristev (февраль 2009 г.). «DC++ указывает на поврежденное». DC++: Just These Guys, Ya Know?. Архивировано из оригинала 2009-03-09 . Получено 2009-02-11 .
  17. ^ Toast (январь 2009 г.). "CTM Review и ошибки прошлого". ADCPortal. Архивировано из оригинала 2011-07-07 . Получено 2009-01-27 .
  18. ^ "DCNF - Direct Connect Network Foundation". Архивировано из оригинала 2016-01-25 . Получено 2016-01-07 .
  19. ^ Фонд Direct Connect Network: Документы и ресурсы, заархивированные 2016-12-20 на Wayback Machine

Внешние ссылки