ADC: The run down

I previously wrote an extensive post about NMDC. Since we’re moving away from NMDC to ADC, I guess a post about ADC is in order. If I don’t explicitly say that something is different from NMDC, assume that the ADC way is the same as the NMDC way.

While a final version (that is, “1.0”) doesn’t exist, the current draft is mostly what will be in the finalized version. The first draft of ADC saw day light on the 3rd of December 2003. ADC was spawned from ideas from another replacement draft; DCTNG. The draft mentions ADC to stand for “Advanced DC”, though it isn’t official. (I always thought of ADC as a recursive acronym; ADC Direct Connect, but maybe that’s just me.)

As a network, ADC work the same as NMDC does; with hubs and clients, where the hub is a central part. Everything is routed through the hub, except the actual file transfers. However, a client could claim (to the hub) that it wants to download from another client, the hub allows it, and instead of trying to get a file, the client will start sending other messages (such as chat). Truely private chat.

Contrary to NMDC, the one that does the connecting, speaks first. That is, eg when connecting to a hub, the hub will wait, after establishing a connection socket, for the client to say “hello. I want to come in”.

In ADC, there are two key characters. The first is a space, used as a delimiter inside commands and a “newline” character to denote the end of a command. There’s no starting character. Whatever that come after the newline character is considered to be a totally new command.

Commands are constructed in multiple ways. In all of these ways, an initial four characters (well, five with a space) are required. These character say (1) how the message should be routed or used (“type”) and (2) what the message is about (“action”). When a client recieve a command, it shouldn’t actually even look at the type to determine what it should do. As I said, there’s multiple ways to create commands, but you’ll need some more info on ADC.

In ADC, when the client connects to a hub, the hub will assign the client a unique ID for that particular hub. This unique ID is very important since the client will need it to interact with the hub. (This is called a ‘SID’.)

Also, beyond a unique ID per hub, ADC require that all users in DC have a unique ID for the entire network. That is, I should be able to say “hey, that user is the same user as that one”. This unique ID is broadcasted to everyone in the hubs (well, doesn’t have to, but most likely will in most hubs) a user frequent. (This is the ‘CID’, which you can visibly see in DC++…) Further, so users aren’t allowed to spoof someone else’s CID, they need to provide another special unique ID (‘PID’) to hubs. The hub will then verify that there’s a match, and let the client to continue. You can spot a security issue here; users need to trust hubs, that they don’t give out the PID to others.

Let us continue. Each action, have a set of parameters that are allowed and/or have to be used. These parameters can either be mandatory or voluntary. If the parameter is voluntary, it is required that it is preceded by an two-character identifier. If the paramter is mandatory, there shouldn’t be an identifer.

Moving on… There are three types of commands. Since the initial bit is always mandatory, I’ll leave it out from these examples. (1) Only the parameters of the action are present. (2) The SID for whom it is from, followed by the parameters. (3) The SID for whom it is from, followed by a SID for who it for (“send this to person x only”), followed by the parameters.

In ADC, all commands are uppercase characters and case-sensitive. Voluntary parameters have no particular order; one can send them however they want.

Something else that is interesting in ADC, which NMDC doesn’t do, is that if a parameter need to have a space in it (like a description for a user), the space is replaced by “\s”. “\n” to display a real new line and “\\” to display the character \.

One of the most interesting aspects of ADC for developers is the ability to create extensions, without trouble. If a client or hub doesn’t understand something, it just ignores it (well, there’s always a possibility of kicking/disconnecting).

Let us get away from this somewhat boring info… In NMDC is a hub assumed to be running at port 411 and file transfers on 412. However, this assumption is not allowed in ADC; Addresses must be explicit in the usage of port.

Contrary to NMDC, chat is rather easy in ADC. In ADC, all chat is assumed to be in UTF-8, meaning that everyone should be able to see everything. Also, there’s no such thing as the “highest number wins”, in transfers.

As NMDC has a protocol specifier (dchub://), ADC has one, too. It is “adc://”. In the future, you may see “adcs://” do denote that the hub is using TLS.

Rather obvious but… ADC natively require the usage of TTH…

I’ve spoken much about ADC, so make sure you read all of the other posts on it as well.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”