The haunting 0.402 connection bug

When a version of DC++ is in development state, there’s a handfull of people who run and try the version. It’s a handfull since you need to compile it yourself, requiring some knowledge…

Unfortunately, we have no test-suit that automatically perform the tests for us, so we have to do tests rather random and arbitrarily. If I’ve sent in a patch, I usually test the functionality of the patch (first of course before sending, but always after it’s merged) I’ve previously submitted.

Another functionality that I always test, almost mechanically, regardless if I’ve sent a patch or if that particular feature/code has specifically been touched, is the ability to connect to the same version of DC++. (That is, I use two instances of DC++.)

As you might know by now, current DC++ doesn’t support some older versions of DC++. This is of course intentional, and isn’t considered a bug. Sometimes, the development version drops support for versions it should support, such as the latest released version.

And sometimes, just sometimes, the development version drops support for itself.

Let me take you back to version 0.402… New code base and ADC’s first day light. It was quite a stable version, as you might have noticed with 0.403. Though, 0.403 was a little better than 0.402, and I’ll tell you why…

It was during my initial experience as a DC developer; I found DCDev Public. Though, much of a “developer” I wasn’t. Anyway, one of the little restrictions was the (lack of) ability to connect to other people in the hub. (Which is still true, in its current incarnation.) However, there were some that could connect to others, and that were the operators. One of the little nice touches with DCH++. (I have no idea if other hubs have this functionality, but I’m sure they do.)

Well, as I wasn’t an operator back then, and I didn’t to much “testing” myself (I don’t think I had even managed to compile DC++ at that point), I couldn’t try out the development version until it was released.

When it did, I recieved a notification from SourceForge, which you can still sign up to today, and downloaded and fired up DC++. And of course connected to the dev hub.

And minutes after I had started DC++, I started crashing. Firing up and *bam*, a crash. However, I tracked the problem to the dev hub. “Huh? How could I crash for just being in the hub?” Well, as the operators could download and I could share (well, duh!), one of them decided to check out my share. It was TheParanoidOne, and he was running the same version as myself; 0.402…Well, after some more investigation (and of course more crashing), I was able to conclude with TPO that it was infact him that crashed me. Weirdly enough, one could connect to older versions just fine. DC++ just was able to remotely crash other users running the same version.

Any way, 0.403 was quickly released later that day, with a “100% CPU fix”… I didn’t really see 100% CPU, but whatever stops me crashing, right?

And that is the story of the connectivity bug that has haunted me for years.

Do you perform any weird tests?

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

Keeping me alive

Every once in a while, my connection to the Internet goes down, or the connection to a hub does. I’m sure it has happened to you, too.

When either of those things happen, DC++ notice the connection has been cut, display the error message and tries to reconnect. And if your connection is up again, you’ll connect just fine.

If you are using a version of DC++ below 0.699 in a ADC hub, and the connection drops you will most sulely not even notice it before you actively attempt to do something in the hub.

This is because DC++ is sending a “keep-alive” command every once in a while. Mind you, this type of thing also exist in the NMDC part of DC++.

What are these types of commands? Well, basically it is the smallest amount of command you’re allowed to send in respective protocol. In NMDC, it is simply a “|” and in ADC it’s a ‘\n’. These are the minimum you can send. How DC++ or any other client figures out that the connection has broken isn’t really important. (There’s not really any code in eg Elise concerning it. Java, as I’m sure other socket implementations in other languages, handles it for you rather nicely.) (There’s probably some TCP reply if the connection isn’t dropped, but I can’t that for sure.)

Why do we “need” to send this? Well, it’s because if nothing has been sent during a particular (timeout) window, the connection is dropped. You can probably set your TCP timeout session window, though. The client will then try and compensate for not getting any information by sending the minimal command and seeing if the connection is broken.

On a busy hub, a keep-alive is rather pointless, as I’m sure you can see.

Mind you, it is not only the client that can implement a keep-alive, the hub can, too.

In any case, this is quite an important thing to implement in a client, so all you client developers should know about it. (And, I guess, hub developers and owners, too, since “you are going to get some traffic that are just keep-alives”.)

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

Future DC seek secure and nice hash for identification

By now, you’ve probably not missed that we’re using T(iger)T(ree)H(ashes). Using a hash is incredibly much more useful than going by file name (and size).

While hashes has gotten its fair share of admirers, it sure has gotten its fair share of people who are dismayed about them. The reason I most see is that the people are complaining about the “long” hash time.

I doubt anyone can make your drive go faster to hash faster, but there are other things we can do.

TTHs are getting deeper and deeper buried in DC++, ADC and the entire network that is DC. There is a large problem with this situation, I’m afraid.

The problem is that algorithms like TTH are constantly under attack by cryptographers. These are people who are trying to find out a way to create the ultimate and unbreakable hash, by also trying to destroy current ones.

This mean that there’s a possibilty that Tiger tree hashes are enheritly “broken”. This in turn would mean that malicious people would try and infect the network with incorrect TTHs, and causing quite a nuisance for a lot of people.

There’s a… well, sort of… solution. The solution would be to use multiple hashes. Different algorithms, that is, that are different enough from TTH, but similar enough that the idea is to uniquely identify a file.

A known scheme for indexing files in a hub, would be to use a bloom filter. For this scheme to work nicely would be to use multiple hash algorithms – at the same time. This might be quite expensive, for both hubs and clients. (If not in term of bandwidth, then in terms of CPU usage.)

Another intresting scheme would be to use SET, though I don’t know how easy it would be to use it in DC. As far as I know, it’s also relatively new, so it might be dangerous to jump on the band wagon just yet.

In any case, I think we need to focus attention on the fact that Tiger Tree possibly won’t always be secure enough to use. Before people start writing client and hubs, one must consider that TTH won’t always be used.

As a sidenote to, DC++ will have a hard to adjusting if another algorithm is to be used, but I guess we’ll have to worry about it then, unless someone now write a patch to abstract it away.

Dont forget that you can make topic suggestions for blog posts in our Blog Topic Suggestion Box!