History
ADC was created to allow an extensible protocol and to address some shortcomings of the Direct Connect protocol. It was initiated by Jacek Sieka, under the influence of Jan Vidar Krey's DCTNG draft.[2] The first revision of ADC came in 2004 and the first official version in 2007-12-01.
Design and features
ADC is structured around clients that connect to a central hub, where the clients (users) can chat and download files from other clients (users). The hub provides routing between clients for chat, searches and requests for connections. The actual file transfers are between clients.
The protocol itself is split in two parts: a base protocol that every client and hub respectively must follow and extensions that are optional. The protocols allow signalling of protocol features (such as bloom filters), and messages can be constructed to only be routed to those who support that particular feature.
Each hub has their own rules and are commonly governed by hub operators.[3] Hubs may define different capabilities for hub operators. The hubs themselves do not regulate discussion and files, but the hub operators. The hub regulate minimum share and maximum amount of simultaneous hubs; things that are sent by the client, rather than the user.
Lists of hubs [4] exist where a hub's name, description, address and rules are specified. With the hub list, users can choose hubs that are similar according to the user's liking of discussion topics and files.
The peer-to-peer part of the protocol is based on a concept of "slots" [5] (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 time. The slots are controlled by the user of respective client.
ADC require that all text must be sent in UTF-8, which means that users with different system encoding (say, Russian and Chinese) are able to chat with respective native characters.
The protocol natively supports IPv6.
There are two modes a user can be in: "active" or "passive". Clients in active mode can download from anyone else on the network. 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. An active searcher will receive (at most) 10 results per user and a passive searcher will receive (at most) 5 results per user. NAT traversal exist as a protocol extension,[6] which allow passive users to connect to other passive users.
The base protocol does not require encryption, but extensions exist to provide encryption with TLS.[7]
Files in client connections are identified by their hash, most commonly the Tiger Tree Hash. The hash algorithm is negotiated with the hub and used throughout the client-hub session, as well as subsequent client-client connections.
Protocol
The ADC protocol is a text-based protocol, where commands and their information are sent in clear text, except during password negotiation. The client-server (as well as client-client, where one acts as a "server") aspect of the protocol stipulates that the client speak first when a connection has been made. For example, when a client connects to a hub's socket, the client is the first to talk to the hub.
The protocol requires that all text must be sent as UTF-8 encoded Unicode, normalized in form C.
There are no port defaults, for hubs or clients.
Hub addresses are in the following form: adc://example.com:411, where 411 is the port.
During hub-client protocol information exchange, the client offers a set of hashes it supports. The hub will select one of these hashes, and that hash will be used throughout the hub-client session. If the hub deems that the client doesn't support an (arbitrary) appropriate hash set, an error is raised.
The global identification scheme is based on the hash set producing two end-hashes, where one of them depends on the output of the other. During hub-client information exchange, the client will send these end-hashes, encoded with base32, which the hub will confirm to match. One of these base32 encoded hashes will be further sent to other clients in the network. The global identification scheme is this last string. The client may change its end-hashes on a hub-to-hub basis.
Each user, during a hub session, is assigned a hash that only lasts that particular session. This hash will be used for all client references in that hub. There is no dependency on nicks.
Each client information notification is incrementally sent.
An incoming request for a client-client connection is linked to an actual connection, with the use of a token.
Searches use a token, as well, to identify each result of a search.
There is no out-of-the-box ability for a client to kick or redirect another client from a hub. The hub, however, can kick and redirect arbitrarily. The hub can also require that all other clients in the hub must terminate their transfers with the kicked/redirected client. If a client is redirected to another hub, the redirecting client must use a referrer, similar to the HTTP referrer. The kicked/redirected client is not required to receive a notification message.
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 time. These slots are controlled by the client. Automatic slot allocation is supported by the protocol.
The token in the client-client connection decides who should be allowed to download first.
Downloads are transported using TCP. Searches can be transported using TCP or UDP.
An active client has a listening port for TCP and another for UDP, though the ports don't depend on each other.
Protocol delimiters are '\n' and ' ' (space). The character '\' is used as an escape sequence. Allowed escape sequences are "\n" (new line), "\s" (space) and "\\" (backslash).
The protocol allows for extensions such as compression with bzip2 or encryption with TLS.[8] While the protocol does not mandate that these extensions be implemented, hubs may require them.
About DC and protocols.
Moderator: Demona
3 posts
• Page 1 of 1
-
Admin - Site Admin
- Posts: 249
- Joined: Mon May 25, 2015 11:56 am
- Location: OCALA FL USA
Direct Connect (DC) is a peer-to-peer file sharing protocol. Direct Connect clients connect to a central hub and can download files directly from one another. Advanced Direct Connect can be considered a successor protocol.
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.
Contents
1 History
2 Protocol
3 Hublists
4 Direct Connect used for DDoS attacks
5 Direct Connect Network Foundation
6 Articles and papers
7 See also
8 References
History
NeoModus was started as a company funded by the adware "Direct Connect" by Jon Hess in November, 1999 while he was in high school.[1]
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.
The DCDev archive[2] contains discussions of protocol changes for development of DC in the years 2003–2005.
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.[3]
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.[4]
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.[5]
A search result cannot be linked with a particular search.[6]
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 U+0020 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
dchublist.org Yes Yes Webbased/Regserver Yes Yes Yes Yes
te-home.net/ Yes Yes Webbased Yes No Yes
dchublist.ru Yes No Unknown Unknown No Yes
dchublist.biz/ Yes No Webbased Yes No Yes
ufo-modus.com Yes No Regserver Yes Yes Yes Yes
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.
The CTM Exploit surfaced in 2006–2007, during which period the whole Direct Connect network suffered from DDoS attacks. The situation prompted developers to take security issues more seriously.
As of February 2009, an extension for clients was proposed in order for the attacked party to find out the hub sending the connecting users.
Direct Connect Network Foundation
The Direct Connect Network Foundation (DCNF) is a non-profit organization registered in Sweden that aims to improve the DC network by improving software, protocols and other services in the network.
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.
Contents
1 History
2 Protocol
3 Hublists
4 Direct Connect used for DDoS attacks
5 Direct Connect Network Foundation
6 Articles and papers
7 See also
8 References
History
NeoModus was started as a company funded by the adware "Direct Connect" by Jon Hess in November, 1999 while he was in high school.[1]
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.
The DCDev archive[2] contains discussions of protocol changes for development of DC in the years 2003–2005.
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.[3]
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.[4]
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.[5]
A search result cannot be linked with a particular search.[6]
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 U+0020 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
dchublist.org Yes Yes Webbased/Regserver Yes Yes Yes Yes
te-home.net/ Yes Yes Webbased Yes No Yes
dchublist.ru Yes No Unknown Unknown No Yes
dchublist.biz/ Yes No Webbased Yes No Yes
ufo-modus.com Yes No Regserver Yes Yes Yes Yes
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.
The CTM Exploit surfaced in 2006–2007, during which period the whole Direct Connect network suffered from DDoS attacks. The situation prompted developers to take security issues more seriously.
As of February 2009, an extension for clients was proposed in order for the attacked party to find out the hub sending the connecting users.
Direct Connect Network Foundation
The Direct Connect Network Foundation (DCNF) is a non-profit organization registered in Sweden that aims to improve the DC network by improving software, protocols and other services in the network.
-
Admin - Site Admin
- Posts: 249
- Joined: Mon May 25, 2015 11:56 am
- Location: OCALA FL USA
Please read this post for general ADC protocol draft:
https://forum.dchublist.org/viewtopic.php?f=29&t=196
https://forum.dchublist.org/viewtopic.php?f=29&t=196
-
Admin - Site Admin
- Posts: 249
- Joined: Mon May 25, 2015 11:56 am
- Location: OCALA FL USA
3 posts
• Page 1 of 1