DirectConnect/fr: Difference between revisions
(Created page with "'''A TRADUIRE''' '''Direct Connect''' (DC) is a peer-to-peer file sharing protocol. Direct Connect clients connect to a central node (networkin...") |
No edit summary |
||
Line 1: | Line 1: | ||
''' | {{Languages|DirectConnect}} | ||
'''Présentation''' | |||
'''Direct Connect''' (DC) est un [http://fr.wikipedia.org/wiki/Protocole_de_communication protocole] de [http://fr.wikipedia.org/wiki/Partage_de_fichiers_en_pair_%C3%A0_pair partage de fichiers en pair-à-pair]. Le réseau se base sur une multitude de serveurs, intitulés les Hubs, auxquels les clients se connectent. Tout un chacun peut héberger un Hub (en français : concentrateur), ce qui a mené le réseau à une notoriété rapide. Les Hubs hébergent entre 2 et plusieurs centaines d'utilisateurs. Le nombre de clients par Hub dépasse rarement la dizaine de milliers. | |||
'' | ==Histoire== | ||
Le protocole est conçu à l'origine par l'entreprise [http://en.wikipedia.org/wiki/NeoModus_Direct_Connect Neo-Modus], en même temps que le logiciel qui allait l'utiliser. NeoModus a été fondée en novembre 1999 par Jonathan Hess, financé dans ses débuts par l'[http://fr.wikipedia.org/wiki/Publiciel adware] "Direct Connect". | |||
"NeoModus Direct Connect" était une axée sur une communauté type "réseau et client". La capacité de chatter était un élément central du client ainsi les utilisateurs pouvaient exercer une gestion directe du réseau et les fichiers qu'ils partageaient. | |||
==History== | ==History== | ||
'''A TRADUIRE''' | |||
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 encryption 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 the purpose of having an [[Multiple_document_interface|MDI user interface]] and using plug-ins for file sharing protocols (similar to [[MLDonkey]]). Open Direct Connect also did not have complete support for the full file sharing aspects of the protocol, but a port to [[Java (software platform)|Java]], however, did. Later on, other clients such as DCTC (Direct Connect Text Client) and [[DC++]] became popular. | 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 encryption 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 the purpose of having an [[Multiple_document_interface|MDI user interface]] and using plug-ins for file sharing protocols (similar to [[MLDonkey]]). Open Direct Connect also did not have complete support for the full file sharing aspects of the protocol, but a port to [[Java (software platform)|Java]], however, did. Later on, other clients such as DCTC (Direct Connect Text Client) and [[DC++]] became popular. |
Revision as of 12:53, 1 April 2014
Languages: |
English • Deutsch • Español • Français • עברית • Italiano • Nederlands • Polski • Português • Русский • 中文(繁體) | e |
Présentation
Direct Connect (DC) est un protocole de partage de fichiers en pair-à-pair. Le réseau se base sur une multitude de serveurs, intitulés les Hubs, auxquels les clients se connectent. Tout un chacun peut héberger un Hub (en français : concentrateur), ce qui a mené le réseau à une notoriété rapide. Les Hubs hébergent entre 2 et plusieurs centaines d'utilisateurs. Le nombre de clients par Hub dépasse rarement la dizaine de milliers.
Histoire
Le protocole est conçu à l'origine par l'entreprise Neo-Modus, en même temps que le logiciel qui allait l'utiliser. NeoModus a été fondée en novembre 1999 par Jonathan Hess, financé dans ses débuts par l'adware "Direct Connect".
"NeoModus Direct Connect" était une axée sur une communauté type "réseau et client". La capacité de chatter était un élément central du client ainsi les utilisateurs pouvaient exercer une gestion directe du réseau et les fichiers qu'ils partageaient.
History
A TRADUIRE
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 encryption 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 the purpose of having an MDI user interface and using plug-ins for file sharing protocols (similar to MLDonkey). Open Direct Connect also did not have complete support for the full file sharing aspects of the protocol, but a port to Java, however, did. Later on, other clients such as DCTC (Direct Connect Text Client) and DC++ became popular.
Protocol
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.<ref>Template:Cite web</ref>
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.Template:Citation needed
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.<ref>Template:Cite web</ref>
A search result cannot be linked with a particular search.<ref>Template:Cite web</ref>
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 ' ' (  (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.
Hublists
Name | NMDC |
ADC |
Registration |
CTM Detection |
Active |
---|---|---|---|---|---|
ufo-modus.com | Yes
|
No | Regserver | Yes
|
Yes
|
dchublist.com/ | Yes
|
Yes
|
Webbased | Yes
|
Yes
|
openhublist.org | Yes
|
Yes
|
Webbased | Yes
|
No |
publichublist.nl | Yes
|
No | Regserver | Template:Unknown | No |
hublist.org.nz | Yes
|
Yes
|
Webbased | Template:Unknown | Yes
|
dchublist.ru | Yes
|
No | Template:Unknown | Template:Unknown | Yes
|
qsdchublist.com | Yes
|
No | Webbased | Yes
|
Yes
|
Name | NMDC |
ADC |
Registration |
CTM Detection |
Active |
Direct Connect used for DDoS attacks
As the protocol allows hubs to redirect users to other hubs, malicious hubs have redirected users to places other than real Direct Connect hubs, effectively causing a Distributed Denial of Service attack. The hubs may alter the IP in client to client connections, pointing to a potential victim.<ref>Template:Cite web</ref><ref>Template:Cite web</ref><ref>Template:Cite web</ref>
The CTM Exploit surfaced in 2006–2007, during which period the whole Direct Connect network suffered from DDoS attacks.Template:Citation needed The situation prompted developers to take security issues more seriously.Template:Citation needed
As of February 2009,<ref>Template:Cite web</ref><ref>Template:Cite web</ref> <ref>Template:Cite web</ref><ref>Template:Cite web</ref><ref>Template:Cite web</ref> an extension for clients was proposed in order for the attacked party to find out the hub sending the connecting users.
Source : http://en.wikipedia.org/wiki/Direct_Connect_(file_sharing)