Old DC++ forums restored

DC++ used to have a forum where people would receive help, give suggestions on improvements and discuss protocol features. This forum migrated from SourceForge to the domain dcpp.net (now defunct, don’t use it). The entire site was then attacked and the forum was put offline. This was in 2007, and no forum has yet replaced the old DC++ forum as a whole.

The DCBase.org project is put in place to harmonize different content for Direct Connect. As such, the project host the DCBase forum (previously ADCPortal) where today’s discussions for (primarily but not exclusively) ADC development lies. However, it is also important to look in the past and what has been done and the discussions that were held then. As such, the old DC++ forum is now restored. This forum is now set up similar to the old forum, and the database is migrated as such. The entire forum is locked down (until someone want DC++ to regain that as a forum) so you can’t post anything.

I will probably create posts in the future where the old forum is referenced (in particular NMDC and ADC development and protocol discussions).

If anyone else have a forum, wiki or site that is now defunct, let me know. It is important that the content that we once produced isn’t completely lost.

A Decade of TTH: Its Selection and Uncertain Future

NMDC and ADC rely on the Tiger Tree Hash to identify files. DC requires a cryptographic hash function to avoid the previous morass of pervasive similar, but not identical, files. A bare cryptographic hash primitive such as SHA-1 did not suffice because not only did the files need identification as a whole but in separate parts, allowing reliable resuming and multi-source downloading, and per-segment integrity verification (RevConnect unsuccessfully attempted to reliably use multi-source downloading precisely because it could not rely on cryptographic hashes).

Looking for inspiration from other P2P software, I found that BitTorrent used (and uses) piecewise SHA-1 with per-torrent segment sizes. Since the DC share model asks that same hash function work across entire shares, this does not work. eDonkey2000 and eMule, with per-user shares similar to those of DC, resolved this with fixed, 9MB piecewise MD4, but this segment size scaled poorly, ensured that fixing corruption demanded at least 9MB of retransmission, and used the weak and soon-broken MD4. Gnutella, though, had found an elegant, scalable solution in TTH.

This Tiger Tree hash, which I thus copied from Gnutella, scales to both large and small files while depending on what was at the time a secure-looking Tiger hash function. It smoothly, adaptively sizes a hash tree while retaining interoperability between all such sizes of files files on a hub. By 2003, I had released BCDC++ which used TTH. However, the initial version of hash trees implemented by Gnutella and DC used the same hash primitive for leaf and internal tree nodes. This left it open to collisions, fixed by using different leaf and internal hash primitives. Both Gnutella and DC quickly adopted this fix and DC has followed this second version of THEX to specify TTH for the last decade.

Though it has served DC well, TTH might soon need a replacement. The Tiger hash primitive underlying it by now lists as broken due to a combination of a practical 1-bit pseudocollision attack on all rounds, a similarly feasible full collision on all but 5 of its 24 rounds, and full, albeit theoretical, 24-round pre-images (“Advanced Meet-in-the-Middle Preimage Attacks”, 2010, Guo et al). If one can collide or find preimages of Tiger, one can also trivially collide or find preimages of TTH. We are therefore investigating alternative cryptographic hash primitives to which we might transition as Tiger looks increasingly insecure and collision-prone, focusing on SHA-2 and SHA-3.

ADC 1.0.2 released

A new version of the base ADC protocol is now released, version 1.0.2.

The document may look slightly different, especially with the addition of commands in the table of contents. The document itself (its content) is not that much modified (except for state management, see below).

An important part of the document is a new addition, a terminology section where difficult words or phrases are specified. This list is obviously meant to be much more than mere four items but it’s at least a start.

The STA previously didn’t specify who had the responsibility for action when a STA is sent with the severity Fatal (2). This has always been the originator of the message, and this is now explicit.

The state management is re-worded and restructured. All information about state has now been moved to its own section, allowing an implementator a quick and comprehensive overview on the requirements for the state management. Previously, the state management was sprinkled all across the document, making it difficult for a person to properly implement a state machine in their software. This has meant that state management information is now removed from each command (only thing remaining is an explicit note about in which state each command is used). Certain information is also clarified, such as what to call the parties in a client to client connection (“client party” and “server party”) and state transitions.

Version 1.0.1 of ADC was also ambiguous in state management when it came to one important part: who shall send the first INF in a client to client connection. This is important because it has the ramification that it makes multi-share difficult. The current specification is now not ambiguous, and makes the following stance: the first party to send the INF is the connecting party (“client party”). No known implementation suffer from this explicit note, as all manage this scenario just fine. Basically, this change means that multiple shares (per hub) may not be too far off.

The new version also brings in a new time where we can safely and appropriately update the base document. There was an announcement period when the document was going to be released which meant that developers have had time to adjust their software and give feedback in a timely manner.

Propose your ideas

Hi people just wanted to share relevant information regarding ADC Development

We recently updated our mediawiki installation and now that its updated i decided to rewamp the proposal list so that mr. Ullner gets a good tool when looking at extensions to include in the protocol.

Proposed Extensions

The idea is that everyone with an wiki account helps out and adds and removes ideas if they are included or denied entry and we use the protocol idea forum on adcportal as an official place if you wanna add just the spec or a link to the spec thats fine as long as it gets posted there so Ullner doesnt have to chase the idea over the net.

Hope this will improve development and document who did what in the future :)

DSLReports DC FAQ gets updated

The popular Direct Connect FAQ at DSLReports existed and served as a primary source of DC related information and howto’s for a long time. However, some parts of it has become really outdated over the years, but now we can annouce that the complete FAQ list has been updated in the recent weeks.

Dead links and pages about depreciated features are corrected, the related DC++ changelog entries updated, so the currently existing pages should have correct and recent information about DC++ and the whole DC network. Of course the whole FAQ could be improved with new questions and answers but that’s another story…

People now can visit the site and if anything you think is missing or not correct, you can leave feedback on the bottom of every FAQ page. Any corrections or suggestions welcomed…

Documenting ADC

The state of ADC has flourished a bit since I last wrote about it, and there are a couple of things to note.

The basic ADC document is basically untouched since it’s last release at 1.0.1. The major updates have occurred on the extensions side of ADC.

The extensions version is currently as of writing at 1.0.3 as the official version. There is a 1.0.4 brewing but it’s something that will be released later on.

ADC extensions are relatively simple to suggest and I’ll happily add the extension as an official one if it has grown traction by developers and a consensus on the extension specification has been agreed upon. Usually, to suggest an extension, pop in to the forums and specify as thoroughly your extension and what implementations exist. Additionally, it’s possible to go to our developer hub, but you might want to still post in the forums as chat can be cumbersome to reference. Updates to the extensions document are usually grouped in one update, so we don’t have multiple updates on the same document and even the same extension in a relatively short while, causing implementations to be potentially invalid.

There is a started ADC recommendations document, basically aimed at providing guide lines for developers, but it’s hardly complete. The idea is to get more people involved in this document so new developers can benefit from old developers’ wisdom of ADC, quirks in implementations and more.

Do note that I am not the only one with access to the official ADC documents; there are others as well, so you can contact the other members of the ADC project if I’m not available.

ADCH++ 2.4 pushed out

Hi

Well a new version of ADCH++ is out due to the fact that we kinda messed up the 2.3 release so for all of you that are out there running 2.3 update to 2.4 and you will be fine.

We also added documentation from ADCH++ on the website for any developer wanting to help out by making plugins or lua scripts.

http://adchpp.sf.net/doc/

changelog:

• 222. By Pietry
  edited installer, changelog, version
• 221. By poy
  fix command dispatching
• 220. By poy
  fix ban reason
• 219. By poy
  add +topic (and aliases), shortcut to +cfg topic
• 218. By poy
  add history & motd to the default scripts list

ADCH++ (Windows Bin Zip File)

ADCH++ (Windows Installation)

ADCH++ (Source Windows/Linux)

ADCH++ now more then an empty shell

Hey people back again doing a monolog here on the blog this time its about ADCH++ 2.3

We all know that the last release wasn’t a big success but i wanna show of the new features in ADCH++ , it was more then a year ago since we had a release on ADCH++ and much new stuff has been added into it.

So what are the new features:

User Commands, ADCS (preliminary implementation), more scripts for the soft.

There is also a doxygen included in the BZR repo at launchpad for anyone that wants to make a plugin in C++ or make lua scripts or python script all you have to do is download Doxygen to make the documentation we will host the documentation at ADCH++ webspace on Sourceforge also.

I really wanna commend poy for his efforts put into this version of ADCH++ and listening to input and feedback with this version things can only get better in the future of ADCH++

We are still looking for a GUI maker so if your out there and think you got what it takes drop into DCDev Public and talk to us or drop the source of at launchpad.

and we hope that suggestions for ADCH++ will come up at our tracker on Launchpad so we can get your input for what your missing in ADCH++ or possible bugs thats giving your problems.

So people out there give it a go and say what you think about it :)

ADCH++ 2.3 Windows Installer

ADCH++ 2.3 Windows Zip File

ADCH++ 2.3 Source Code (both Windows and Linux)

ADCPortal the frontpage for Advanced Direct Connect

As some of you may know, ADCPortal is for some time a part of DCDev. ADCPortal provides the following for the normal user: latest news about the protocol and all the main software that is available on the market, ideas and comments about the future of the network ( what’s coming up and more ), information about all the protocol features including all the known extensions. One can also register and ask questions or propose his/her own extension.

ADCPortal also provides a full wiki that can be consulted to get all the required information about ADC.

The interested developer also has the opportunity to get in touch with the protocol designers and also people who worked around ADC, or created pieces of software for it.

We strongly encourage everybody interested in ADC to visit ADCPortal in order to get more information. Lately I heard that the main reason people are reticent about ADC is the lack of information. ADCPortal has been around for nearly two years, but people still wouldn’t come and ask. So please, come around, ask whatever question you like, don’t be shy, we will be very happy to answer you. We also hope you will find the site useful and we wait for you to join us.

DC++ pointing out the corrupted

One of the latest enhancements in DC++ is the hub referral on client-client connections, proposed by Jan Vidar Krey. The current bazaar trunk implements this mechanism and the next DC++ version that will be released soon will also have it. The purpose of this extension is to point out the corrupted hub that is sending the current client to a non DC client, with obvious malevolent purpose. This implies that the hub is either using exploitable software, or that it’s intentionally abusing the clients. Either way, the hubowners are solely responsible.

On connecting to the other party, DC++ will also send the hub URL that it used to connect to the hub sending out the CTM message. By packet inspection, an attacked party can figure out which is the corrupted hub (only a pointer is required, such that they have a point of reference ) . Another good part about this extension is that it works on both ADC and NMDC ( some workaround was found for NMDC: adding the url to the PK string since NMDC is not extensible nor flexible in this matter ) , with the least effort from the clients and it does not bother them in any way. A normal client should ignore the specific message ( I don’t find any particular usage for it ).

We strongly recommend all mods to inherit this extension and other clients out there to implement it so the CTM attacks impact on DC software will stop being so great.