I4/I6 should be broadcasted regardless of TCP4/TCP6

In ADC, it’s possible for clients to announce from which IP they’re connecting. This IP is later usually used to identify what address to connect to if they accept incoming TCP connections. That is, when you want to connect to someone, you announce ‘I4’ (for IPv4; I6 for IPv6) and send a “connect to me” message, or CTM. You also announce TCP4 or TCP6 in the feature field for others.

In ADC (in NMDC as well, really), there are two types of users; those who accept incoming TCP connections and those that do not. The former is usually called ‘active’ and the latter ‘passive’. Active users can connect to other active users. Active users can connect to passive users. Passive users can connect to active users (by a ‘reverse’ CTM message). Passive users can’t connect to other passive users (I’m going to purposefully ignore NAT traversal since it allows passive to passive connections, but it isn’t useful in this discussion).

The reverse CTM for passive to active connections work by a simple mechanism. The passive user says to the active user “RCM”, reverse connect to me. The active user will then proceed to connect to the passive user, and the downloading will commense.

Active clients are basically required to signal their address in the I4/I6 field (that is simply the nature of the field), whereas passive users are not required (but keep reading).

So far so good, nothing bad has happened.

Now, imagine the case where an active user will want to connect to another active user. They both signal I4 (I’ll use it for simplicity sakes, but it applies to I6 as well). The downloader signal address 1.1.1.1, the uploader signals 2.2.2.2. The downloader send to the uploader “connect to me”. The uploader connects through 2.2.2.2.2 to 1.1.1.1, and the communication continues. Everything’s all right for now.

Imagine instead that the downloader is a passive user. The passive user will say to the active user ‘send a connect to me so I can connect to you’. The active user will say ‘connect to 1.1.1.1’, which the passive user connects to. However, the connection can come from anywhere, and not necessarily from the IP the passive user connected to the hub with! That is because the active user does not have any knowledge from which IP the passive user should connect from.

(Now, obviously, there will be a token sent which the passive user will need to verify, but the problem of connection-point do not go away.)

So solve the problem, passive clients should publish I4/I6 regardless of whether they support TCP4/TCP6 or not. If you look at the specification, TCP4/TCP6 require I4/I6 but not the other way around, so this change (i.e. ‘everyone should send ‘I4/I6’) should not have any effect on existing implementations.

Do note that the hub can of course send I4/I6, regardless of whether the client sends it or not.

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

What should money be spent on?

I have recently been thinking about how different software projects make money, specifically those aimed for file sharing, as DC is. Some projects have ads, banners etc, but what interested me the most was what the money was actually spent on. I couldn’t find any solid information on what the authors of e.g. different BitTorrent clients spend money on, and I began thinking about a parallell with DC and an old blog post, that I think is still quite valid; Is Money Useless to Open Source Projects?

I started a discussion in the development hubs, and the following is what people suggested when I asked “What would you spend money on?”

  • Domains
  • Web hotels; allowing use of HTTPS (among other things)
  • Code signing (via Comodo, VeriSign etc)
  • Dedicated servers for hubs
  • All of these things aren’t specifically costly per se, so it’s not important what they actually cost. Also, I think it is important to note that a question in the form of “what do we need” (or, rather, “what could we spend money on”) rather than “how much do we got” is more just, since the former doesn’t fluctuate as much.

    I have also thought about shelving out money to developers and contributors, but most DC contributors have never had a monetary incentive and probably won’t be any more influenced to contribute if they received X for doing Y. Also, any type of system where developer A gets money when developer B doesn’t get money will be hard to establish. That leads to me to think that paying any contributor is less valuable than spending money on ‘fixed’ items, specifically items that require less and less intervention than had any contributor set them up.

    So, this brings me to the question I asked previously; what should money be spent on? I want you to ignore how the money would arise (people donating money, selling merchendise, ads etc), so just pretend that the money is there already.

    (Do note that my question isn’t specifically pertaining to DC++ or ADCH++ or to specific software. As long as it’s associated with DC…)

    Prototype of JaDiCe, the next DC++

    Hi!

    The DC++ team is pleased to announce that DC++, originally coded in C++ (an old language that doesn’t even provide any garbage collection), is now being rewritten in Java, a far more performant language.

    This will possibly allow cross-platform distributions in the future and will improve the overall aspect and response time of the program.

    To celebrate the beginning of the rewrite, DC++ is now being renamed to JaDiCe. This new name conveys the awesomeness of Java (“Ja”) while keeping the “D” and “C” (for Direct Connect) letters around.

    An early prototype of JaDiCe has just been completed; you can download it by following the link below (don’t worry, it won’t touch any file nor registry entry).
    Stand-alone exe file
    Stand-alone exe file in a zip archive
    Source code

    We hope you are as thrilled as we are about this fantastic switch to Java and look forward to reading your feedback about the JaDiCe prototype!

    Why DC++ 0.674 is Insecure

    Update 2017-10-21: Invalid ADC commands sent via UDP will crash the app, which DC++ 0.867 fixes, adds one more way to crash DC++ 0.674.

    Update 2017-08-02: somehow, six (6) years later, this remains an issue. In that time, the actively developed DC++ and DC++-based clients one might try have become DC++ itself, ApexDC, AirDC++, and EiskaltDC++.

    Furthermore, How to crash DC++ 0.674 describes more specifically how to remotely crash DC++ 0.674. It is strongly advised to update to a current version of an actively developed client.

    Original post follows.

    DC++ 0.674 remains surprisingly popular. However:

    These reasons all apply to any vaguely modern client older than DC++ 0.707 (and the last three to clients through 0.75), actually, but 0.674 seems to have kept the most users of those old versions so I target it specifically. Instead, it’s much safer to use a currently-maintained client; if one prefers a pre-DC++ 0.7xx style GUI, one might look at StrongDC++ or any of its descendants.

    DC++ 0.782

    A new and important service release of DC++ is released today. It does not bring any new functions this time, instead, it fixes two severe and many less problematic but still annoying issues.

    First of all, DC++ 0.782 fixes a massively reported startup crash on Windows 7. This is the most urgent fix as this problem makes DC++ unusable for some users. While it’s not exactly confirmed the problem more likely hits those who are already upgraded to Windows 7 SP1.

    A long standing crash and memory leak problem is also fixed which caused DC++ to crash after several hours of running in specific hubs/scenarios.

    Some less important but still welcomed fixes have also been applied as follows:

    • Prevented a remote crash which could be triggered via malformed user commands from a hub
    • The favorite hub window correctly obeys the color settings again
    • A stricter failure check of the default MiniUPnP interface makes the success rate of the automatic connection type detection even higher
    • Fixed a long standing hang on exit problem under WINE

    The complete changelog for 0.782 shows you all the changes in detail. Immediate upgrade is recommended for everyone, especially for those who experience crashes or running DC++ on Windows 7.

    DC++ 0.781

    Just a day after the release of DC++ 0.780, a new version with a couple of quick fixes is out. A compatibility issue with non-DC++ based clients in ADC hubs and a stability problem in shut down process of the client are the reasons of this fast update. Upgrade is recommended for everyone who are already using 0.780…

    DC++ 0.780

    As a result of a half year long of constant development, a new version of DC++ has just released. This time the development was mainly focused to improve the user experience, provide better look and feel and to make DC++ easier to use for newbies and non-techicals. The changelog for version 0.780 counts no less than 72 changes, most of them are improvements but as usual the new version brings a few bug fixes and patched security vulnerabilities as well.

    Let’s see a few areas with the most important changes in detail:

    General GUI changes

    • The tab bar’s look is changed yet again with fundamental changes this time. There are plenty of new configurable options in the Appearence/Tabs pane in the settings. Under Windows Vista & 7 the new tabs  look similar to some web browsers tabs by default. For those who don’t have middle button in their mouse  from now the active tabs add a red “X” icon for closing.
    • The new version introduces plenty of new and revisited icons for the toolbar, the folder treeviews and the menus. The user iconset is completly revisited as well with nice looking icons for different type of users and icon modifiers representing different user states.
    • DC++ supports taskbar thumbnails and “Aero Peek” live previews on Windows 7 from now
    • To make the favorite hub groups function’s usage easier we added a menu to add selected hubs to a certain group in one go
    • Some other parts of the GUI was slightly modified as well, mostly according to the call for a modernized DC++ GUI.
    • The DC++ GUI become DPI-aware. It means that fonts and dialogs respect any  DPI setting in the display properties of the opereating  system or in the video driver.

    Improvements in the file list window

    The new release brings a few internal and GUI improvements regarding the filelist browser window. They are as follows

    • Instead the long time existed one way forward search, its possible to search backwards in the filelist window as well. The speed of search between hits is improved due to an internal change which fixed the problem of longer and longer search times for subsequent hits in large filelists.
    • Searches now always start from the current selection. That means you can move the selection anywhere in the directories pane allowing to skip some hits manually and continue the search from the selected location.
    • The whole search function moved to a toggleable search bar. It shows only when you need it, when you press the Find button…
    • Entered search keywords for filelist searches are globally kept, the same way as Search windows do for a long time
    • The filelist window introduces a visual representation of a long standing but little known function called bookmarks (or better visited places). Previously it was available through obscure hot keys only, now we have a nice blue left-right arrow icon pair for moving the filelist selection backwards or forward through the previously selected (visited) folders in the filelist. Above these we have an up arrow icon for easily move the selection up one level in the directory folder tree. The visited places in the filelist are also shown in a long path dropdown above the files pane. You can quick access any formerly visited folder by selecting it from the dropdown.

    Easier connectivity setup

    Nowadays computer users expect that a software should be usable to its primary purpose with its default settings and should be up and working after a few absolutely required data (eg. username, passwords, etc…) is specified. This wasn’t the case with DC++ until now, as in most cases the successful usage of DC++ required a change in the default incoming connection settings. A change of a setting that most users have no or limited knowledge of  what to do with. In fact this sole problem caused plenty of users to turn away from the DC network in the last years.

    All recent SOHO NAT devices definitely have UPnP these days and most have NAT-traversal feature as well. This makes possible to create an automaic connection type detection algorythm that decides the best available type using some basic information.

    DC++ 0.780 introduces such a detection function and its enabled by default. If you upgrade it will be enabled only if you used passive mode before. We hope this function will provide seamless run and better connectivity for the majority of the users running DC++.

    Details, usage and possible cases that may keep the function from working are available in the built-in help.  The structure of the help documentation regarding connection setup is also changed, there’s an individual FAQ for those who still want to use the manual way for setting up connectivity in DC++.

    Having the funcion above, getting started with DC++ should be very easy in most cases, so we also introduced a very short quick rundown tutorial for newbies in the DC++ home page.

    Improvements regarding the window manager

    Since the release of  window manager function in version 0.760 we received some complaints about problems of the windows’ restoration at startup of DC++. The problem narrowed down to the case when large number of hubs and (especially) filelist windows are opened when the user closes DC++. The restoration of these large number of windows could cause minutes long freezes at startup in slow computers.

    The large number of connecting hubs problem was solved by introducing a Close all the opened hubs option in the Window menu. A new way of opening filelists in the background should solve the second issue as from now filelists are processed only when their tab is clicked by the user. This provides seamless start of the program even there are plenty of large filelists to be restored at start.

    The new window manager also restores the last window selection so from now you can really continue using DC++ exactly from where you were in the last session.

    Security and bug fixes

    • The new version fixes security holes in OpenSSL and bzip2 libraries.
    • For more protection of unknown vulnerabilities DC++ forces to use DEP from now regardless of the operating system settings (but only when your CPU supports it).
    • DC++ now prevents from the world famous current directory Windows DLL injection vulnerability, too.
    • A blacklist (or whitelist?) of rogue hub-lists is maintained and users warned if they load hublists from domains/sites knowingly went to suspicious owners’ hands.
    • Fixed the instant share after download function yet again, now it works well if the download target is on a different drive than the temporary folder
    • Readded the CRC check of downloaded data using .sfv files function which hasn’t worked for a long time (since version 0.700)

    This new version of DC++ brings some fixes and improvements of a few ADC functions and extensions as well. These changes are marked with [ADC] in the complete changelog, which you can browse for every single changes of DC++ 0.780.

    As usual, if no major problems found, DC++ 0.780 goes stable within a couple of weeks.

    All posts in one big page

    I’ve put (nearly) all posts on this blog in a ‘Post list‘ page. All posts (except minor “version X is out” and those that are immediately insignificant at this time) should be there, but if not, make a comment.

    If someone can be bothered to write a description for each post, feel free…

    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 :)

    ADC Extensions – 1.0.6

    A new version is out of ADC Extensions that bring much to ADC. Have a look at http://adc.sourceforge.net/versions/ADC-EXT-1.0.6.html.

    The list;
    •Added KEYP extension for providing certificate substitution protection in ADCS.
    •Added note to signal DFAV.
    •Added SUDP extension for encryption of UDP traffic.
    •Added TYPE extension for chat state notifications.
    •Added FEED extension for RSS feeds.
    •Added SEGA extension for grouping of file extensions in SCH.
    •Added failover hub addresses to the hub’s INF.
    •Added free slots to the client’s INF.
    •Added ADCS extension for encryption in ADC.

    Most of these extensions are people familiar with. I think one or two of them deserve their own posts, so a detailed description of each item will have to wait for another day.

    Design a site like this with WordPress.com
    Get started