Advanced Direct Connect
From Wikipedia, the free encyclopedia
Advanced Direct Connect (ADC) is a peer-to-peer file-sharing protocol, based on the topology of the Direct Connect (DC) protocol. ADC clients connect to a central hub and can download files directly from one user to 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.
[edit] History
ADC was created to allow an extensible protocol and to address some shortcomings of the DC protocol. It was initiated by Jacek Sieka, under the influence of Jan Vidar Krey's DCTNG draft. The first revision of ADC came in 2004 and the first official version in 2007-12-01.
[edit] Protocol
The ADC protocol is a text-based protocol, where commands and their information is sent in clear text, except during password negotiation. The client-server (as well in client-client, where one act as "server") aspect of the protocol stipulates that the client speak first when a connection has been made. For example, when a client connect to a hub's socket, the client is first to talk to the hub.
The protocol require that all text must be sent as UTF-8 encoded Unicode, normalized in form C.
There are no port default, 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 offer a set of hashes it support. The hub will select one of these hashes, and that hash will be used throughout the hub-client session. If the hub deem 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 depend 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 last 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 with an actual connection, with the use of a token.
Searches use a token, as well, to identify each result with a search.
There is no out-of-the-box ability for one 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 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. Automatic slot allocation is supported by the protocol.
The token in the client-client connection decide who should be allowed to download first.
Downloads are transported using TCP. Searches can be transported using TCP or UDP.
There are two kinds of modes a user can be in. Either in active or in passive mode. Clients using 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.
An active client have a listening port for TCP respectively 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 allow extensions in the protocol, for such as compression with bzip2 or encryption with TLS. While it is not mandated by the protocol that these extensions are implemented, hubs can require them.
