Протокол файлообмена Direct Connect: история и особенности

Введение

Протокол компьютерной сети для обмена файлами

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

История

NeoModus была основана как компания, финансируемая рекламным ПО "Direct Connect" Джоном Хессом в ноябре 1999 года, когда он учился в старшей школе. Первый сторонний клиент назывался "DClite", который не обеспечивал полной поддержки функций обмена файлами протокола. Хесс выпустил новую версию Direct Connect, требующую простого ключа шифрования для установления соединения, что блокировало сторонние клиенты. Ключ шифрования был взломан, и автор DClite выпустил новую версию DClite, совместимую с новым программным обеспечением от NeoModus. Позже DClite был переписан как Open Direct Connect с целью использования MDI-пользовательского интерфейса и плагинов для протоколов обмена файлами (аналогично MLDonkey). Open Direct Connect также не поддерживал все функции обмена файлами протокола, однако это удалось реализовать в порте на Java. Впоследствии стали популярны другие клиенты, такие как DCTC (Direct Connect Text Client) и DC++. Архив DCDev содержит обсуждения изменений протокола, касающихся разработки DC в период с 2003 по 2005 год.

Протокол

Протокол Direct Connect — это текстовый компьютерный протокол, в котором команды и их данные передаются в открытом виде, без шифрования в оригинальном программном обеспечении NeoModus (шифрование доступно как расширение протокола). Поскольку клиенты подключаются к центральному источнику распространения информации (хабу), хабу требуется значительный объем доступной пропускной способности для загрузки. Официальной спецификации протокола не существует, что означает, что каждый клиент и хаб (за исключением оригинального клиента и хаба NeoModus) был вынужден проводить обратную разработку информации. Таким образом, любая спецификация протокола, на которую может ссылаться эта статья, скорее всего, будет неточной и/или неполной. Клиент-серверная (а также клиент-клиентная, где один клиент выступает в роли "сервера") архитектура протокола предусматривает, что сервер отвечает первым при установлении соединения. Например, когда клиент подключается к сокету хаба, первым отвечает хаб. В протоколе не определена кодировка символов по умолчанию для клиентов или хабов. Оригинальный клиент и хаб используют кодировку ASCII вместо кодировки операционной системы, что позволяет перейти на кодировку UTF-8 в более новом программном обеспечении. Порт 411 является портом по умолчанию для хабов, а 412 — для клиент-клиентных соединений. Если один из этих портов уже занят, номер порта увеличивается до тех пор, пока не будет найден свободный порт. Например, если заняты порты 411, 412 и 413, будет использоваться порт 414. Адреса хабов имеют следующий формат: dchub://example.com[:411], где 411 — необязательный номер порта. Глобальной схемы идентификации не существует; вместо этого пользователи идентифицируются по никнейму на каждом хабе отдельно. Входящий запрос на клиент-клиентное соединение нельзя связать с фактическим соединением, а результат поиска — с конкретным запросом. Протокол поддерживает возможность удаления или перемещения (перенаправления) пользователя на другой хаб. Если пользователя удалили, хаб не обязан указывать конкретную причину, и нет ограничений на то, куда его можно перенаправить. Однако, если другой клиент с правами администратора дает команду хабу на удаление, этот клиент может отправить уведомление перед этим. Перенаправление пользователя должно сопровождаться указанием причины. Эквивалента HTTP-реферера в протоколе нет. Хабы могут отправлять команды клиентам, которые являются лишь необработанными протокольными командами и используются в основном для упрощения определенных задач. Например, хаб не может отправить команду, которая откроет веб-сайт в браузере по умолчанию, но может добавить команду "+rules" (где "+" указывает хабу, что это команда — это может варьироваться), чтобы отобразить правила хаба. Одноранговая часть протокола основана на концепции "слотов" (аналогично количеству открытых вакансий). Слоты определяют количество пользователей, которым разрешено одновременно скачивать данные у одного пользователя, и контролируются клиентом. В клиент-клиентных соединениях стороны генерируют случайное число, чтобы определить, кому разрешить начать скачивание первым, и клиент с большим числом выигрывает. Для передачи загрузок и подключения к хабу требуется TCP, а для активных поисков — UDP. Пользователь может находиться в одном из двух режимов: "активном" или "пассивном". Клиенты в активном режиме могут скачивать данные у любого пользователя в сети, а клиенты в пассивном режиме — только у активных пользователей. В NeoModus Direct Connect пользователи в пассивном режиме получают результаты поиска других пользователей в пассивном режиме, но не могут ничего скачивать. В DC++ пользователи в пассивном режиме не получают эти результаты поиска. В NeoModus Direct Connect всем пользователям отправляется не более пяти результатов поиска на запрос. Если пользователь выполнил поиск, DC++ ответит десятью результатами поиска в активном режиме и пятью — в пассивном. Пассивные клиенты получают результаты поиска через хаб, а активные — напрямую. Разделителями протокола являются "$", "|", и протокол имеет для них (и некоторых других) управляющие последовательности, и большинство программ используют их правильно в последовательности входа (Lock to Key). По какой-то причине эта управляющая последовательность игнорировалась разработчиками DC++ и они используют HTML-эквивалент, если эти символы должны быть отображены пользователю. Сохраняется интерес к таким функциям, как рейтинги и языковые пакеты. Авторы DC++ также предложили полную замену протокола Direct Connect под названием ADC, или неофициально Advanced Direct Connect. ADC использует ту же сетевую топологию, концепции и терминологию, что и оригинальный протокол. Одним из примеров добавленной функции протокола по сравнению с оригинальным является трансляция хеша Tiger Tree (TTH) общих файлов. Преимущества этого включают проверку правильности загрузки файла и возможность поиска файлов независимо от их имен.

The Direct Connect protocol is a text based computer protocol, in which commands and their information are sent in clear text, without encryption in original NeoModus software (encryption is available as a protocol extension). As clients connect to a central source of distribution (the hub) of information, the hub requires a substantial amount of upload bandwidth available. There is no official specification of the protocol, meaning that every client and hub (besides the original NeoModus client and hub) has been forced to reverse engineer the information. As such, any protocol specification this article may reference is likely inaccurate and/or incomplete. The client server (as well as client client, where one client acts as "server") aspect of the protocol stipulates that the server respond first when a connection is being made. For example, when a client connects to a hub's socket, the hub is first to respond to the client. The protocol lacks a specified default character encoding for clients or hubs. The original client and hub use ASCII encoding instead of that of the Operating system. This allows migration to UTF 8 encoding in newer software. Port 411 is the default port for hubs, and 412 for client to client connections. If either of these ports are already in use, the port number is incremented until the number of a free port is found for use. For example, if 411, 412 and 413 are in use, then port 414 will be used. Hub addresses are in the following form: dchub://example. com[:411], where 411 is an optional port. There is no global identification scheme; instead, users are identified with their nickname on a hub to hub basis. An incoming request for a client client connection cannot be linked with an actual connection. A search result cannot be linked with a particular search. The ability to kick or move (redirect) a user to another hub is supported by the protocol. If a user is kicked, the hub is not required to give that user a specific reason, and there is no restriction on where a user can be redirected to. However, if another client in power instructs the hub to kick, that client may send out a notification message before doing so. Redirecting a user must be accompanied by a reason. There is no HTTP referer equivalent. Hubs may send out user commands to clients. These commands are only raw protocol commands and are used mostly for making a particular task simpler. For example, the hub cannot send a user command that will trigger the default browser to visit a website. It can, however, add the command "+rules" (where '+' indicates to the hub that it's a command this may vary) to display the hub's rules. The peer to peer part of the protocol is based on a concept of "slots" (similar to number of open positions for a job). These slots denote the number of people that are allowed to download from a user at any given time and are controlled by the client. In client to client connections, the parties generate a random number to see who should be allowed to download first, and the client with the greater number wins. Transporting downloads and connecting to the hub requires TCP, while active searches use UDP. There are two kinds of modes a user can be in: either "active" or "passive" mode. Clients using active mode can download from anyone else on the network, while clients using passive mode users can only download from active users. In NeoModus Direct Connect, passive mode users receive other passive mode users' search results, but the user will not be able to download anything. In DC++, users will not receive those search results. In NeoModus Direct Connect, all users will be sent at most five search results per query. If a user has searched, DC++ will respond with ten search results when the user is in active mode and five when the user is in passive mode. Passive clients will be sent search results through the hub, while active clients will receive the results directly. Protocol delimiters are "$", "|", and Protocol have for them (and few others) escape sequence and most software use them correctly in login
(Lock to Key) sequence. For some reason that escape sequence was ignored by DC++ developers and they use HTML equivalent if these characters are to be viewed by the user. Continued interest exists in features such as ratings and language packs. The authors of DC++ also proposed a complete replacement of the Direct Connect protocol called ADC, or unofficially, Advanced Direct Connect. ADC uses the same network topology, concepts, and terminology as the original protocol. One example of an added feature to the protocol, in comparison with the original protocol, is the broadcasting of Tiger Tree Hashing of shared files (TTH). The advantages of this include verifying that a file is downloaded correctly, and the ability to find files independently of their names.

Direct Connect используется для DDoS-атак

Поскольку протокол позволяет хабам перенаправлять пользователей на другие хабы, злоумышленнические хабы перенаправляли пользователей не на настоящие хабы Direct Connect, фактически вызывая распределённую атаку типа «отказ в обслуживании». Хабы могут изменять IP-адреса в соединениях между клиентами, указывая на потенциальную жертву. Эксплойт CTM был обнаружен в 2006–2007 годах, в этот период вся сеть Direct Connect подвергалась DDoS-атакам. Начиная с февраля 2009 года, для клиентов было предложено расширение, позволяющее стороне, подвергшейся атаке, определить хаб, отправляющий подключающихся пользователей.

Фонд сети Direct Connect

Фонд Direct Connect Network (DCNF) — некоммерческая организация, зарегистрированная в Швеции, которая стремится улучшить сеть Direct Connect, совершенствуя программное обеспечение, протоколы и другие сетевые сервисы.

Статьи и бумаги

DCNF ведет список статей, научных работ и другой документации, касающейся DC.