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 Neo-Modus software (encryption is available as protocol
extension). 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 Neo-modus 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 in client-client, where one acts as "server")
aspect of the protocol stipulates that the server speak first when a
connection has been made. For example, when a client connect to a
hub's socket, the hub is first to talk to the client.
The protocol
don't have specified default character encoding for clients or hubs.
In original client and hub is use Ascii encoding of Operating system.
This allow to move 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 is already in use, the next higher port is
used. 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; 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.
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 give the
user a specific reason and there is no restriction on where a user
might be redirected. 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
one time. These slots are controlled by the client.
In
client-to-client connections, the parties negotiate a random number
to see who should be allowed to download first. The client with the
highest 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. 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, while 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, or 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 ' ' (space). 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.
However, 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 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.







0 comentarios:
Publicar un comentario