DC++ 0.811

A new service release of DC++ is out and marked stable. Along with some small fixes the new version improves on a couple of more important areas.

We received reports that the obligatory share format converison at the first start of DC++ 0.810 may take more time than one would expect, especially in cases when  large number of files shared or had been shared before. During the first startup conversion DC++ 0.810 may look unresponsive; worse is that when the anxious user clicks to the taskbar preview or the DC++ startup logo during the conversion period, it results an immediate “Not responding” message shown by Windows. People might get confused with this so the fix comes with DC++ 0.811 and you will never get those messages again. Also there’s a new graphical progress indicator under the DC++ splash logo so from now users are somewhat better informed about what’s happening at the startup.

Note that the first (and only the first) startup can still take unusually long when you uprgade from version 0.802 or older. Some users with extra large shares reported even 15-20 minutes long startups and that really sounds long. But again, you have to keep in mind that it’s still a lot better option than a complete rehash of your entire share.

The other bigger change in version 0.811 is the switch of the used compiler package. We changed from MinGW to MinGW-w64 for now as some tests done with DC++ built using MinGW-w64 resulted better long time stability under extra heavy load.

Version 0.811 is a stable release and immediate upgrade is recommended.

DC++ 0.810

We’re happy to annouce that a new testing release of DC++ is available from the official download page. Version 0.810 contains numerous fixes and small improvements over the last release but this isn’t going to be a large post with lots of explanations in this case; the changelog items mostly speak for themselves.

I’d like to highlight three improvements that might need more attention:

• The Plugin API has been evolved further but it’s still not reached the stage where the plugin binaries are possible to distibute with the client. They’re still in a testing phase but binaries available from now to those who interested on testing. As long as the the final plugin distribution format is beeing implemented the nightly plugin binary builds are available in a simple .dll format at the Plugins archive of the DCBase Builds server.
  At the time of writing two fully functional and a test plugin are available. The LUA 5.2.1 client side Script Plugin is able to run all BCDC++ client side scripts. The Dev Plugin offers functions like monitoring the protocol talk, follow search requests (former Search Spy function) and more. Make sure you consult the readme file before downloading any revision of any plugins.
  For those who interested in creating plugins the source code,  SDK and Doxygen documentation is still available in the DCPP Plugins SDK repositories (C and C++).

• Fixing of two the two following long standing problems required to change the hash data file format: the case insensitive share format that caused problems on non-Windows clients based on the dcpp library and a bug with merging shares  containing same filenames/folders resulted an inconsistent behaviour.
  Because of these fixes if you upgrade from an eralier release the first start of the client might require a bit more time than usual. An automatic share format conversion will make you wait a bit more, depending on how large your share is.
  The bad news is that the automatic conversion is possible only on Windows Vista and later. Due to lack of extended file handling capabilities of the OS, the entire share needs to be rehashed for XP users.

• The only remarkable and very useful GUI improvement this time is the ability to copy data from every list view to the clipboard. It is possible through the lists’ context menus, using a new ‘Copy’ menu item. You are able to copy the content of one column or the data of all columns in one go.
  There’s also a special new menu item  (called “Copy user information”) for lists containing users; it’s made to easily gather all the available info (not just what’s displayed) about one user or multiple selected users copied to the clipboard.

Things looking good so far; this means that DC++ 0.810 should make stable within days. Upgrade is recommended as always.

DC++ 0.802

A new stability and performance update is available for DC++. The new version brings a nice global performance improvement and a further boost focused on a couple of other areas. It also fixes a severe stability problem as well.

This new version introduces a different global thread mechanism that should make the client faster and able to utilize some features of modern CPUs. The cost is that DC++ requires a P6 (Pentium Pro / AMD K6) or newer processor from now to run. As most of the currently supported operating systems require even newer CPUs, this should not be a problem for the vast majority.

DC++ 0.802 should considerably improve the client’s performance under heavy load as well (e.g. beeing logged on to many hubs with large usercount) and decrease the resource consuption in these cases.

You might already learned that file list loading operations are improved in version 0.801. The good news is that due to further optimization and a caching algorithm you should experience another boost in responsiveness when you open large file lists with DC++ 0.802.

This release also fixes a random crash problem that can produce weird and nonsensical crash reports. Though 0.802 should go stable within a few days, we’d like to ask everyone, users and betatesters, to report crash logs made by version 0.802 only from now.

The detailed changelog is in the repository as usual.

DC++ 0.801

The first stable version of the 0.8x series of DC++ is available to download for a while. We already posted about the largest improvement of the new release that marks a new era for the DC network, a fixed critical security vulnerability as well as about Windows 8 compatibility. Now it’s time to go through the rest of the  improvements and developments that came with DC++ 0.801 by picking the remaining interesting items from the changelog with occasional comments where needed.

GUI improvements

• Revamp favorite hub settings

Various global  settings are now possible to be overridden per favorite hub. Opening the fav hub properties dialog they should be self-explanatory.

• Tweak help tooltips in the settings dialog

Tooltips should not cover any important parts of the dialog anymore.

• Make the menu bar hideable

• Replace the slot up-down control by a context menu

Easier to change the number of upload slots while it causes less strain to hubs and other users.

• Allow Magnet links to be pasted in the “Quick connect” box

Since the torrents network picked up magnet links they become more and more popular. As there is a higher chance  to find magnet links outside the DC network here’s the place where you can directly import them.

• Remember list sorting & splitter positions on various places

Client functionality changes

• Rise the minislot size to 512 KiB

DC++ has limited number of upload transfers at the same time and this is regulated by upload slots (strange that after 10+ years of exitstence of the DC network some people still haven’t realized this: “No slots available” is still often searched within this blog). There are different type of slots and they were already explained in this post. In DC++ 0.800 the default mini slot size rose to 512KB and this will allow users to get small files much sooner than before. The previous default value was chosen long before when Internet connection speeds were much lower. The change is made because nowadays extra transfers of files smaller than 512KiB should not be a burden for the majority of connections. The setting remains configurable (though it’s possible to set a higher value only).

• Upload queue postition (QP) support

QP or ‘Upload Queue Notification’ is a client side mechanism that creates a queue of connecting users on a “first come, first serve” basis when your slots are full. QP works like this (say you only have 1 slot and it is free), users “a”, “b” and “c” connect to you in ascending order user a can begin his/her file transfer immediately. Users b and c are put in a queue 0 and 1 respectively, as soon as user “a” is finished user “b” can start and user “c” then moves up the queue to position 0. Basically all this means to you (the user) is it creates a fair system where everybody gets a slot in the order that they connected so you don’t end up getting bumped whenever a slot becomes free to someone else who can connect faster ( if you go offline you will lose your Queue Position). The actual queue position is indicated in the Status column of the Connections part of the Transfers window. Please note that QP is fully implemented for ADC hubs only.

Bug fixes, stability, performance

• Reduce the resource consumption some when upload slots are full

• Don’t choke on hub addresses with spaces

This problem was already detailed here.

• Fix a mixup between IPs and hostnames leading to wrong search results

Is a problem in NMDC hubs only. Sometimes the search result contains the host name instead of the IP of the responder’s hub address rendering the search result unprocessable by the requesting client. This bug is introduced in DC++ 0.790 thus hits all 0.79x versions.

• Fix glitches with the file list loader; Eliminate GUI freezes when opening large file lists

Various problems fixed while loading large filelists as well as the speed and responsibility of the client is greatly improved while file lists are beeing opened. The next version of DC++ will improve even further in this area.

• Fix buttons not available in user matching settings panel in some cases

• Improve performance when selecting lots of lines in lists

• Greatly improve user command removal time when closing a hub

• Grant extra slot hangs connection in ADC hubs

Was a really old problem, and is fixed at last.

• Fix NAT-PMP renewal

NAT-PNP is still a gray area because not too many router devices feature this protocol yet. Anyone with a NAT-PMP capable router is more than welcomed to help us testing and to polish the support of this nice and simple port mapping protocol in DC++.

• Fix GeoIP & OpenSSL problems with wide character paths

This bug could bother you if the path of your DC++ Certificates folder or the DC++ settings folder itself contains non-latin characters. Users from e.g. Russia, China etc… having non-latin characters in their Windows username could fall into this category. The problem blocked operations associated with these folders, for example the automatic upgrade of GeoIP information.

The list of fixes are large and DC++ 0.801 is already made stable so it is a highly recommended update for everyone. For the complete list of changes please refer to the changelog.

The evolution of connection setup in DC++

You might already know that there was yet another connection setup change in the latest release of DC++. Instead of a simple paragraph of about the current changes I thought I show you the best part of the evolution of DC++ in regard of connection setup.

For a long time the connection setup was the most hated part of DC++ for many people. But with the success of  the Automatic connectivity setup the manual connection setup has become an advanced feature in DC++ by now; in the majority of cases an average user should not modify or even activate them. The layout, labeling and the number of the active mode options are often changed over the history of DC++, especially in last couple of years.

The four available active mode options that has been in DC++ in the recent years are debuted back in DC++ 0.68. That time they were expanded and become more descriptive for the sake of better understanding.  However, manual setup of active mode  still remained a problematic task for many users until the automatic setup function introduced in DC++ 0.780.

The last change in DC++ 0.800 shrinks the number of active mode options from four to three.  As two of the existing manual active mode setup options actually had identical function now they are merged: you should use the same option for direct connection and manually port forwarded active modes from now.

Now here’s some history in pictures. More of them can be found by Google.

This is something from the ancient times. There are even no separate Connections page yet.



This one’s from around cca. version 0.670. Settings moved to a new page but no change in the layout. In active mode DC++ automatically tried UPnP port mapping if the ports were empty and went to passive on mapping failure. UPnP implementations were pretty unreliable that time (both in DC++ and in the routers) so there were many non-working and passive setups. But most people still loved it because it often gave some sort of connectivity without playing with the settings.



The layout we had for many years. Introduced in 0.68 and people really hated it because #1 old settings are not converted on upgrade #2 in most cases it wasn’t worked without touching the settings and it threw various error messages #3 the options and error messages were confusing (eg. most people couldn’t quite understood what “Firewall” means here). This layout lasted until DC++ 0.75.



Here’s the first attempt to have more meaningful options. It is from the era when DC++ started to become a bit more user friendly (version 0.76x). Still no automatic setup.



First incarnation of automatic setup in version 0.78x.  Manual settings are still on the same page and greyed out if autoconfig is selected. The first time DC++ has some indication of what’s happening with the connections so problems were lot easier to solve using the log. DC++ already uses MiniUPnP for port mapping by this time. A lot more successful port mapping attempts, really. It was an overall success throughout the community.

 

This is DC++ 0.79x. Manual config moved to a separate page and you can copy and edit autodetected settings in the manual page. This version introduces NAT-PMP as an alternative way for automatic port mapping. Bind address setting is where it should be at last.

 

…and finally the current relabeled and optimized manual options in 0.800. Mind that while they’re lot more versatile, with the last optimization the current logic of the options are also more simple and a bit similar to the very old format.

Will connection setup evolve more with time in DC++? That I don’t know but I am sure that DC++ already in par with other p2p applications in this regard.

DC++ and Windows 8: a troublesome path

DC++ has a history of problems with various pre-releases of Windows 8 and even with the final RTM version, too. The connection problems existed in DC++ with the preview versions of Win8 had been fortunately fixed by Microsoft in the final edition of Windows 8. However, the RTM release brought another headaches.

Despite the media hype about the Modern (formerly know as Metro) UI and the obsolescence of the Windows desktop interface, Microsoft still seems to be quietly changing (fixing? improving?) the good old Win32 API. The best example is a small late minute change made between the Release Preview and the RTM editions of Win8 – and its trashing effect to DC++. Yeah, I am talking about the startup crash that hits almost all 0.7xx versions of DC++.

The good news is that DC++ 0.800 fixes the crash problem so all early adopters of Windows 8 are now able to run DC++ without problems.  The fact that some older versions of DC++ don’t run on Win8 will even help spreading the newest DC++ faster.

So it seems to be everything’s OK… or not.  Yesterday Microsoft released an uptade for Windows 8 that might bring another suprise. “Windows 8 General Availability Cumulative Update (KB2756872)” is (currently) an optional  performance and reliability improvement pack and the strange thing is that this kind of updates are appeared in form of Service Packs in the past history of Windows. While the update is an obivious sign that even though it is already released Win8 is still not ready, due to its nature this update might cause new problems with any applications already thought to be compatible with Win8 RTM.

There are no known issues for running DC++ in Win8 with KB2756872 installed at the moment, however, it may change. Should you have any problems with DC++ after installing the update, you’re encouraged to report them in the bug tracker.

Yet another remote crash disclosal

As one of the most easily exploitable remote crash in the history of DC++ is explained earlier today, let me reveal an older one that has been kept away from the public so far.

The problem in question is a bug in handling queue items for partial file list requests. Though the bug can be used for a remote crash, it is far not as critical as the one with magnet link formatting. The scenario is pretty well described in the filed bug report which is now also made avaliable to the public.

To summarize: the crash can happen only if the attacker is able to convince the victim to browse his/her filelist. As the attacker’s nick should be changed in the right time for a successful exploit, a malicious partial list item will remain in the queue. The victim should manually delete this unfinished queue item from the download queue for a chance to be crashed. Moreover, as nick changes are allowed only on ADC hubs, this bug is not exploitable on NMDC.

The problem was fixed in DC++ 0.790 and should hit any older versions what is already capable to connect to ADC hubs.

The new series of DC++ come with a plugin interface

As the first DC++ version of the 0.8 series goes stable today, I’d like to present a summary of basic information about its largest improvement: the plugin API.

The most important thing is that this feature marks a new era of DC++ in terms of customizability. In the last 10 years DC++ users have constantly come up with ideas to implement various options and features into DC++ and most of these were denied or put on hold forever – mostly because those features were thought to not be attractive to all or majority of the users. With the new plugin API, many of these features can be realized in a form of a separate plugin. Even rarely used existing features can be moved into plugins (first example of this is the Search Spy function which was moved to the Dev plugin). This keeps the client code clean and optimized to the most fequent usage scenarios.

But the list of general advantages of the plugin interface is not over yet. The additional benefits were already discussed and published here when the plugin API was in an early stage.

So what you have here is a quick Q&A about the most important information about this new feature; hopefully one of the actual developers of the API will come up with more detailed techincal information soon (and thanks iceman50 for helping me out with a few answers to the following questions).

Q: Is this plugin interface planned and made from scratch or maybe some previous versions/implementations are already released in some clients?

A: The current API was based off of the original implementation from ApexDC++. The original design is from Twinks plugin API in PhantomDC++ and the current API is what evolved from the ApexDC++ API.

Q: Is the current API compatible with any old plugins made for previous APIs?

A: No. The API has a versioning system that clearly defines what plugins can be used in a certain impementation of the API.

Q: Has the current state (version) of the API already been released in any client?

A: Yes. In ApexDC++ and DiCe++.

Q: Are there any plugins available to use?

A: Yes, though only a few yet. They can be built from the DC++ repository or downloaded from the DCBase builds archive. Update: as of 2012.11.15 C and C++ plugins have their own SDK and repository at https://code.launchpad.net/dcpp-plugin-sdk-c and https://code.launchpad.net/dcpp-plugin-sdk-cpp respectively. The repositories also contain the source code of the existing example plugins. Note that plugins built from the SDK are not compatible with the current DC++ release (0.802). For those plugins to properly run you need the latest nightly build of DC++.

Q: What about the LUA scripting plugin availabe in the DC++ repository? Is it the one that’s been in BCDC++ for a while? Is this plugin compatible with the client side LUA scripts already available for BCDC++?

A: Yes, the LUA 5.2.1 client side script plugin works with all BCDC++ scripts in their Bzr repository.

Q: I want to make plugins for DC++. Is there any documentation to start with?

A: There’s no documentation yet, but DC++ the repository contains a self-explanatory example plugin what you can use for a start. Update: use the links to the SDKs above to get example source codes.

Q: Will this plugin API be frozen for a while or it’ll be developed further?

A: The API will certainly change with time. Most likely the next improvement will be a binary format change; the plugin .dll planned to be packed in to an archive with an accompanying .xml file containing the plugin version and other information. You can expect further changes coming as well.

Specified class – we’ve found it

It is a quite embarassing situation for a developer if users keep coming up with bugs producing pointless error messages without any good reason and without any obivous way to reproduce. So in this case you’re at a complete loss.

That’s just had been happening to us since the release of DC++ 0.791 as several people reported that they get the infamous ‘Specified class not found’ error message printed to the main chat when they tried to connect to specific hubs. This one is actually a socket error message and it can sign some host resolving problems. But those addresses that reportedly gave this message for the users have always worked for us.

We had a suspicion that this problem has to do with the new IPv6 code but it wasn’t the case afterall. Today it turned out that the problem is because of the new address parser that was improved to support IPv6 addresses. It does support them well but it apparently also became slightly more strict and doesn’t love whitespaces anymore…

So people out there, if you get this message connecting your favorite hub, go the properties of that favorite hub and check the beginning and the end of the hub address so it does not contain any spaces… It’s often happens that if you copy/paste the address from another application it contains spaces which – especially if it is at the end – is really hard to spot.

Adding spaces to the hub address box will of course be prevented in the next version as well as existing saved addresses with whitespaces in them will be correctly handled…  amen.

DC++ 0.799

A new bugfix release of DC++ is out today, this time it’s really meant to be the next stable one. Along with two important stability fixes and another fix for a problem with locales the changes include only small fixes, improvements and library updates. If you’re already using 0.797 then it’s worth to head over the download page and get the update right away.

If everything goes well this new release will be marked stable within a few days.