ADC and NMDC

[FlipFlop™]

ADC History
ADC development started in 2003, back then it was named DCTNG which evolved to ADC in 2004.
ADC has quite a few advantages over the NMDC protocol: it has better security (encrypted passwords), unique client identification, has full UTF-8 support and is easier to extend without breaking backwards compatibility (within the ADC protocol only). The idea was that ADC would eventually replace NMDC.

The first complete ADC Base: ADC 1.0 was released in december 2007.
Now, over 3 years after it's first mature 1.0 version release, when looking at for example =1]dchublist.com, it looks like about 300 unique users worldwide are using ADC. These are the users in public hubs, ofcourse it's possible that there are thousands of ADC users in private hubs... but I doubt that.

Why does it fail to become mainstream?
The major reason for this is the fact that it's totaly incompatible with NMDC. Instead of improving NMDC, a completely new protocol was chosen to replace it. Ofcourse it's possible to create and use a new protocol even without the user noticing a difference as long as both hub and client can autodetect and handle the new protocol.

Then why hasn't ADC gained any more terrain?
Because ADC hasn't been implemented to run instead of NMDC without the user noticing it!
One of the major mistakes in implementing the ADC protocol in clients has been the use of a mandatory new prefix for connecting to a normal ADC hub: adc://
Without using this prefix the client will assume it's an NMDC hub and will fail to connect to a hub running ADC protocol. This mandatory prefix means that every single user in the hub has to manually change the address in his Favorite Hubs to use 'adc://someaddress:port' if a hubowner would decide to switch to ADC. To make things worse the default port 411 is dropped as well, so even if a hub is running on port 411 you still need to add the port to the address in Favorite Hubs. Any hubowner can tell you that broadcasting an address change in a public hub hardly has any effect, but even if an optimistic 90 percent of users would change it, would any hubowner want to lose even 10% of it's users?
Losing any users because of these address-requirements only is unacceptable and unnecessary. It's actually quite retarded that the user should have to worry about using the right prefix, it's like having to use flash:// instead of http:// if you want to connect to a website containing flash elements. Who cares what protocol is used, if you're using the right program and connect to a valid address and port, stuff should work.

Possible solution
One major obstacle, the adc:// issue as described above can be handled by the client without a real change of protocol.
Clients simply have to autodetect the used protocol, this is fairly easy because if a client connects to a NMDC hub, a $Lock is sent by the hub. The client could allow a waittime of 1 or 2 seconds to receive a $Lock and if no $Lock was received: assume ADC protocol and start the ADC handshake. This way a client connecting to an ADC hub with 'dchub://someaddress:port' will still login. Unfortunately this option was discarded by ADC developers some time ago. To still maintain protocol-integrity, the specific adc:// and nmdc:// URI's could be set to not use autodetection, but it's essential that for a non-protocol specific address, like somehub.no-ip.org or dchub://somehub.no-ip.org autodetection will be used.

Other options
Considering the time that has passed since ADC was first introduced, and the fact that it's userbase is still only a very small fraction of the total DC users, I think there's enough reason to consider extending NMDC. So the FlexHub-team will be actively developing and implementing new NMDC commands/features.

Extending NMDC
The first example of this is the implementation of a new $FailOver command which allows the same functionality as the FO field in ADC INF: it sends failover/backup addresses to the client, the client will store these addresses at the very least for the favorite hubs. If the hub goes offline, then the client will try to connect to the first failover address, then the second etc.
This means that clients supporting this command will simply connect to another address if the original address goes offline for some reason (server failure, ddos, power outage etc.). Check the thread in NMDC Extensions for more info/discussion on this feature.

Client developers are invited to implement these new NMDC features, any suggestions for other new features (both ADC / NMDC) can be posted in the Protocol Talk board.

Proposals: http://www.flexhub.org/forum/index.php?board=17.0

Edited 2011/05/13: added some specifics regarding protocol autodetection