Direct connect is a peer-to-peer file

Direct connect is a peer-to-peer file-sharing protocol. Direct connect clients connect to a central hub and can
download files directly from one another.
Hubs feature a list of clients or users connected to them. Users can search for files and download them from
other clients, as well as chat with other users.
History
NeoModus was started by Jonathan Hess in November, 1999 as a company funded by the adware "Direct
Connect" while he was in high school. The first third-party client was called "DClite", which never fully
supported the file sharing aspects of the protocol. Hess released a new version of Direct Connect, requiring a
simple encryption key to initiate a connection, locking out third-party clients. The key was cracked, and the
author of DClite released a new version of DClite compatible with the new software from NeoModus. Some
time after, DClite was rewritten as Open Direct Connect with goals of having an MDI user interface and using
plug-ins for file sharing protocols (similar to MLDonkey). Open Direct Connect also did not complete support
for the full file sharing aspects of the protocol, but a port to Java did. Some time later, other clients such as
DCTC (Direct Connect Text Client) and DC++ started popping up.
Protocol
The Direct connect protocol is a text-computer based protocol, where commands and their information is sent in
clear text, without encryption. As clients connect to a central source of distribution (the hub) of information, the
hub is required to have a substantial amount of upload bandwidth available.
There is no official specification of the protocol. This means that every client and hub besides the original
NeoModus client and hub have been forced to reverse engineer the information. As such, any protocol
specification this article may reference is likely either inaccurate and/or incomplete.
The protocol does not require a character encoding or font for clients or hubs.
Port 411 is the default port for hubs, and 412 for client-to-client connections. If any of these ports are already in
use, the next port is used. For example, if 411, 412 and 413 is 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; users are identified with their nick-name 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.
Supported by the protocol is the ability to kick or move (redirect) a user to another hub. If a user is kicked, the
hub isn't required to tell the specific reason as to why the user was kicked.
Hubs may send out user commands to clients. This command is only raw protocol commands, and is 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 '+' indicate 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 around 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 one time.
These slots are controlled by the client.
Downloads are transported using TCP. Active searches use UDP. The connection to the hub is with TCP.
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. Clients using passive mode users can only download from active
users. Passive clients will be sent search results through the hub, while active clients will receive the results
directly.
The authors of DC++ have been actively working on a complete replacement of the Direct connect protocol
called Advanced Direct Connect.
One example of an added feature to the protocol, in compared to 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 independent of their names.
Hubs
Direct connect hubs are central servers to which clients connect, thus the networks are not as de-centralized as
Gnutella or FastTrack. Hubs provide information about the clients, as well as file searching and chat
capabilities. File transfers are done directly between clients, in true peer-to-peer fashion.
Hubs often have special areas of interest. Many have requirements on the total size of the files that their
members share (share size), and restrictions on the content and quality of shares. A hub can have any arbitrary
rule. Hubs can allow users to register and provide user authentication. It should be noted that the authentication
is also in clear text. The hub may choose certain individuals as operators (similar to IRC operators).
Перевод:
Direct connect это пиринговый (от англ. peer-to-peer, P2P — один на один, с глазу на глаз) протокол
передачи данных. Клиенты Direct connect соединяются с центральным хабом и могут скачивать файлы
непосредственно от друг друга.
Хабы показывают список клиентов или пользователей, связанных с ними. Пользователи могут искать
файлы и скачивать их с других клиентов, так же как болтать с другими пользователями.
История
NeoModus была основана Джонатаном Хессом (Jonathan Hess) в ноябре 1999 г. как компания,
зарабатывавшая на adware-программе «Direct Connect», в то время как он был в средней школе. Первым
сторонним клиентом стал «DClite», который никогда полностью не поддерживал протокол. Hess
выпустил новую версию Direct Connect требовавшую простой ключ шифрования для инициализации
подключения, блокирующий сторонние клиенты. Вскоре, код DClite был переписан, и программа стала
называться как Open Direct Connect. Кроме всего прочего, её пользовательский интерфейс стал
многодокументным (MDI), и появилась возможность использовать плагины для файлообменных
протоколов (как в MLDonkey). У Open Direct Connect также не было полной поддержки протокола, но
он был портирован на Java. Немногим позже, начали появляться и другие клиенты: DCTC (Direct
Connect Text Client), DC++ и др.
Протокол
Протокол Direct connect это протокол, основанный на текстовом компьютерном протоколе, где команды
и их информация посылаются в ясном тексте, без шифрования. Поскольку клиенты соединяются с
центральным источником распределения (хаб) информации, хабу необходимо иметь доступ к
существенному каналу загрузки.
Нет никакой официальной спецификации протокола. Это означает, что каждый клиент и хаб кроме
оригинальных клиентов NeoModus и хабов были вынуждены ретранслировать информацию. Также,
любая спецификация протокола, на которую может сослаться эта статья, может быть неточной и/или
неполной.
Протокол не требует кодирования символов или шрифта для клиентов или хабов.
Порт 411 является портом по умолчанию для хабов, и 412 для связи клиента с клиентом. Если любой из
этих портов уже используется, то используется следующий порт. Например, если 411, 412 и 413 будут
заняты, то будет использоваться порт 414.
Адреса хабов выглядят так: dchub://example.com [:411], где 411 дополнительный порт.
Нет никакой глобальной схемы идентификации; пользователи идентифицируются по их прозвищем на
основе от хаба-к-хабу.
Поступающий запрос о связи клиент-клиент не может быть связан с фактической связью.
Результат поиска не может быть связан со специфическим поиском.
Протокол поддерживает способность пнуть или переместить (переадресовывают) пользователя на
другой хаб. Если пользователя пинают, хаб не обязан говорить определенную причину относительно
того, почему пользователя пнули.
Хабы могут посылать пользовательские команды клиентам. Эти команды - только сырые команды
протокола, и главным образом созданы для того, чтобы сделать специфическую задачу проще.
Например, хаб не может послать пользовательскую команду, которая вызовет браузер по умолчанию,
чтобы посетить вебсайт. Однако можно добавить команду "+rules" (где '+' указывают хабу, что это команда – она может быть различной), чтобы показать правила хаба.
Пиринговая часть протокола базируется вокруг понятия "слоты" (подобно числу открытых положений
для работы). Эти слоты обозначают число людей, которым позволяют загрузить от пользователя в
любой момент. Этими слотами управляет клиент.
Скачивания передаются, используя TCP. Активный поиск использует UDP. Связь с хабом через TCP.
Есть два режима, в которых может быть пользователь, это "активный" или "пассивный" режим.
Клиенты, использующие активный режим, могут скачивать с кого - либо в сети. Клиенты,
использующие пассивный режим пользователя, могут скачивать только с активных пользователей.
Пассивные клиенты получают результаты поиска через хаб, в то время как активные клиенты получат
результаты напрямую.
Авторы DC ++ активно работают над полной заменой протоколу Direct connect под названием Advanced
Direct Connect.
Одним из примеров добавленной особенности к протоколу, по сравнению с оригинальным протоколом,
является передача хешированного дерева расшареных файлов (TTH). Преимущества его заключаются в
подтверждении, что файл загружен правильно, и способности найти файлы независимо от их названий.
Хабы
Хабы Direct connect – это центральные серверы, с которыми клиенты соединяются, таким образом, сети
столь не децентрализованы как Gnutella или FastTrack. Хабы предоставляют информацию о клиентах,
так же как поиск файла и возможность чата. Передачи файла происходят непосредственно между
клиентами, в истинном понимании пиринговых правил.
Хабы часто имеют специальные области интереса. У многих есть требования к общему размеру файлов
их участников (размер шары), и ограничения на содержание и качество шары. У хабов может быть
любое произвольное правило. Хабы могут позволить пользователям регистрироваться и обеспечивать
авторизацию пользователя. Нужно отметить, что авторизация проходит также в ясном тексте. Хаб
может выбрать определенных людей в качестве операторов (подобно операторам IRC).