Progress bars with Wine

July 17, 2007 by Leave a comment

If you’re running some Linux as your kernel and using one of the many distributions out there, you can of course use DC, too. There’s a couple of clients out there, and one is even based on DC++; LinuxDC++. (While the name may suggest that it’s Linux-only, it “should” be able to be used on other *nix systems, too.)

LinuxDC++ use DC++’s core, though with a different GUI than in DC++. If you don’t like LinuxDC++’s GUI, and none of the other clients are easily available or you just don’t like them, you can actually run DC++. With Wine, an “emulator” (yes; I know what the name mean), you are able to use DC++ with little to no problem.

This post isn’t going to be a guide, but a “quick notice” concerning DC++ and Wine. (Yeah, I know, this has become rather lengthy. Anyway…)

When you are using DC++ through Wine, you will sometimes encounter crashes. What we’ve found out is that it’s caused by the progress bars in the transfer view. You know, the little green and red bars (if you haven’t changed the colors…) that you see when you download and upload?

So, to fix this, go into Settings, Advanced and de-select the option “Show progress bars for transfers”.

(This tip is the only thing we’ve found out that really seperate DC++ on Windows and DC++ through Wine. If you find out other things that that’s causing a crash in [specifically] Wine, let us know.)

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

Filed under Documentation, General

Your Direct Connect client has supplied an invalid SR

July 12, 2007 by Leave a comment

This post is a copy from the YnHub forum, courtesy of Todi, where the “”Your Direct Connect client has supplied an invalid SR” message is explained.

When does this bug occur? When you have multiple nicknames. I’ll explain: Your client sometimes send out a protocol message called an “SR”. This is a search result sent to a passive user, in response to that users search. When YnHub recieves this, it checks that the nickname you are reporting in the SR is the same as the one you are logged into the hub as. This is done to stop evil clients from pretending they are someone else, and returning search results in their name.

However, when doing this check, YnHub is case sensitive. That means that you can’t say your nick is “myNICK” when you log into the hub, and then say it is “MYnick” when you return the SR. Technically these are the same nicks, but the casing is different and that is not allowed by YnHub.

Normally you would never have this problem. If you tell your client that your nick is “myNICK”, then it should always use that when it’s communicating with the hub. Unfortunately, in older DC++ versions, this was not entirely true.

If you logged into a hub once using “myNICK”, logged out, and then changed your nick to “MYnick”, DC++ would tell the hub when you logged in the next time that you were now “MYnick”. However, due to a bug, when sending an SR, the client would still think you were called “myNICK”. I.e the original nickname. This would cause YnHub to disconnect you whenever your client tried to respond to a passive search matching something in your share.

In later versions of DC++ (I do not know exactly which version. 0.674 has the bug, 0.698 does not) this bug has been fixed, and the odds that you would run into this problem has been more or less eliminated.

(I don’t either know in which version of DC++ this was fixed.)

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

Filed under Documentation, General, NMDC

Timing the search reply

July 10, 2007 by Leave a comment

When you are searching, your client send out a request and the other clients in the hub replies (if there’s anything to reply). As you’ve noticed, the time for reply #1 and reply #20 can differ.

When people see the time difference, they feel the need for a “reply time column” in the search window. Basically, the column would display the amount of time it took for your client to recieve the reply. (This is commonly named “network latency” or “ping time”.)

The idea is that the reply time would reflect on the users’ own network speeds. The sooner the reply, the faster the peer. What most people don’t know is that this would be completely pointless and wrong. Why? Because the way the reply time is calculated;

Latency is directly related to the physical distance that data travels. Thus the time taken for a packet to travel from a computer server in Europe to a client in the same region is likely to be shorter than a the time to travel from Europe to the Americas or Asia.

Adding the column isn’t going to magically allow you to see who is the faster source. It will only add a false sense of speed. (Yes, one might say this, too, about the “connection type”.)

(No, this has nothing to do with ADC or NMDC.)

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

Filed under Documentation, General

Why the NMDC protocol is terrible

July 6, 2007 by 5 Comments

I don’t like the NMDC protocol. I’m sure you’ve noticed that by now. So, in this post I intend to “document” the things that make people shrug when they think of the protocol NMDC. Note that what I’m about to say has no direct correlation to ADC, or that I’m implying that the issues I speak of are somehow fixed.

Now go read the previous sentence again before I begin.

* There is absolutely no protocol specification. Developers need to guess what everyone is sending, because we have no actual way of knowing which implemented solution is the best.
* The protocol was written to support a (relatively small) proprietary client and hub system. Thus, it has both remnants from a time when Jonathan Hess (the author of NMDC) wanted to exclude third-party hubs and clients and when the network was very small, compared to now.
* The lack of a native queing system. In NMDC, when one try to download, one must have the good luck of trying to connect while the other party has a slot open. Since there’s no queing system, everyone is up for grabs; And the people that have been waiting the longest may wait even longer.
* When trying to download from someone, both parties negotiate a “download number”. The one that has the highest number is allowed to download. This mean that if two people are trying to connect to each other, the one with the “cheating client that always claim a very high value” will get to download first.
* While this may seem pety and a non-issue… There are actual commands in the protocol that are spelled incorrectly. Sure, semantic, but still. Darn ugly.
* No native text encoding is enforced on clients.
* There is no security in terms of TLS or similar. (Valknut is the only client I know which has had semi-security in this department. But I haven’t seen anything that resembles a ‘specification’ concerning the extended TLS/SSL functionality.)
* File names is still a central part of file sharing, while this is utterly flawed, which we’ve seen with TTH.
* As the original client didn’t allow for multiple hubs, or the fact that the system wasn’t intended for third-party applications, the tag has been forced upon our description.
* The utter and complete lack of point concerning Locks and Keys in NMDC. It’s a security prevention that prevents nothing at this point. (And also, the fact that certain commands are quite pointless to begin with.)
* No global (or quasi-global) user identification. Everyone is identified by their nicks.
* There is no way to tell one search from another.
* If a client developer want to add a new feature/command to the protocol, other hubs and clients will need to change to support it (or even allow the client to function at all.)

These are the things that spring to mind right now. Anything else that’s just plain awful that I didn’t mentioned?

(In NMDC, the connecting party doesn’t speak first, which I find a little odd. However, it’s nothing I consider “bad”. It’s just odd for me since I’m so used to ADC.)

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

Filed under General, NMDC

The haunting 0.402 connection bug

June 13, 2007 by 6 Comments

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!”

Filed under General, Security

Keeping me alive

June 4, 2007 by Leave a comment

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!”

Filed under ADC, General, NMDC

Future DC seek secure and nice hash for identification

June 3, 2007 by Leave a comment

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!

Filed under General, Security

Rollback and advanced resume

May 25, 2007 by Leave a comment

File rollback and advanced resume are the two file integrity checking mechanisms used by DC++ such that one can stop and resume a download whilst ensuring it remains intact, especially allowing for switching between different sources. DC++ versions through 0.699 rely by default upon file rollback as a download resume integrity-checking mechanism; the currently developing version, by contrast, uses exclusively advanced resuming.

File rollback, having originated prior to TTH, assumes little about the relationship between two putatively equivalent sources. Instead, when resuming a file, it examines the last $ROLLBACK_WINDOW bytes of the already downloaded file, begins downloading the new segment $ROLLBACK_WINDOW bytes before the ostensible resume position, and declares the files intact and fit for resuming if and only if the remote and local $ROLLBACK_WINDOW-sized buffers exactly match. Otherwise, it declares a rollback inconsistency and ceases resuming.

This has the weaknesses of detecting only errors in the accumulated portion of the file within the usually small rollback window, requiring to compensate extra bandwidth to transfer that overlap window, creating a loophole in the TTH regime allowing the corruption of transferred files. Further, in recent DC++ versions, file rollback has been destructive, truncating a file according to the rollback window size provided a detected inconsistency. This process repeats up to every couple of minutes, as often as DC++ retries and gets a remote slot; this results in a trade-off between large rollback windows capable of detecting more transfer corruption and a greater risk of losing what progress one’s client has achieved.

Advanced resuming resolves all of these issues by relying, rather than on the limited rollback window, upon the entire file as locally downloaded. As such, it could not be primarily utilised until hash-capable clients had reached ubiquity. Advanced resuming a file involves re-hashing the locally held portion of the file being resumed, proceeding until it detects either a hash inconsistency or the exhaustion of the local data; this point it selects as the resume position. Because it only resumes files the root TTH informs it are identical, it needs not concern itself, by contrast with rollback, with cross-checking the local and remote data, saving bandwidth. Finally, unlike rollback-resumed files, subsequent sessions can take advantage of the now-primed TTH checking machinery, so is as secure as downloading a file without resuming.

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

Filed under General

Denying distributed attacks

May 22, 2007 by 1 Comment

The most unfortunate thing about the past, the present and the future, is the ever growing thought of people that are using the Internet (that include DC) to cause havoc.

This havoc could problably most summarized into using distributed denial of service attacks.

You’ve seen it in action; The cause of dcpp.net’s disappearance and Hublist.org’s unresponsiveness during the past year or so.

To tackle the problem, we first need to understand how people are performing them using DC.

It’s quite simple. These people are in control over one or many hubs. They have operator-status, and are able to manipulate two things. First, they can re-direct your client to an address that’s their target. (Redirect to example.com to cause a bunch of users to connect to the server simultaniously.) Secondly, they are manipulatng C-C initations. When you say to someone else that you want to connect to them, you “say” your IP. (You know, the thing that identifies your computer on the Internet?) This IP can be altered by the hub. So you might have the IP “192.168.0.1” and say this, but the hub will change the message so the address is “192.168.0.2”, causing the other client trying to connect to the second address. (Since it believe that’s where you’re at.)

What can we do to prevent this, or at least minor the damage somewhat?

A few versions back, DC++ added a particular clever scheme. If it tries to connect to a hub but fail and it’s the first time DC++ has seen it (that is, during this session), DC++ will cease to re-connect. Only when a successful connect has been made, will DC++ start to re-connect if the connection fail. I urge all client developers to also add this, if you haven’t.

Another type of protection that was added to DC++, was to internally block certain addresses when users tried to connect to them. (Eg dcpp.net and hublist.org.)

A suggestion that was fairly hard pushed by Nev (do I need to say Y[n]Hub?) and Jove (the dude behind Aquila) was to block certain re-directs. These certain re-directs would be identified by looking at the port number that is being used in the re-direct. One of the propositions were that ports like 25, 80 and other known service-ports should be blocked. Another proposition were to completely restrict port numbers below 1024 (as they’re usually restricted/registered to a known service). The entire suggestion was faced with opposition. I didn’t and don’t like the suggestion. But I can understand wanting it. [I have no idea if the suggestion actually went into production in either hub software.]

Unfortunately, we need to come to a grip that no matter how much protection we add to new hubs and clients, there will always be those who are using old versions of their client or hub of choice. Which is exactly how people exploit DC. They are taking advantage of people’s resistance of upgrading.

We could always force people to upgrade, by using DC++’s (now deprecated) BadVersion in version.xml… Or perhaps by other hub operators to block those clients that do not have the above mentioned protected.

Having that said, I think hub list operators are the ones with much power. They are able to filter what hub are going to be displayed in the list. With information on who are running malicious hubs, the hub list operators can simply filter away the hub. This will lower the rouge people’s leverage.

Sure, one could build a database over “safe and good hubs” (or something similar to the information for browsers concerning phising sites), but I think it’ll be expensive and difficult to build.

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

Filed under General, Security

Decentralizing the centralized network

May 22, 2007 by 5 Comments

The centralized nature of DC is quite apparent. A client connects to a hub, which in turn is used as the central point for all communication, except the raw file transfers. Also, clients connect to hub lists that are also, essentially, a central point for all communication. (Well, one only access the site and download a file.)

What can we do, then?

A solution for this problem would be to have multiple hubs acting as one entity. Something similar to IRC, that is. There are already ways to do this, have a look at Hublink for NMDC and the “IHUB” initiative started by qhub.

We need to consider what the clients are capable of. During file transfer information exchange, one party is considered as “hub” and the other as “client”. This mean that there’s an abstract thought of thinking of clients as hubs. So, if clients may act as a hub, in some sort of limited sense, how can the clients act (more) as a hub?

The most obvious instance for me is “private messages”. That is, a PM in NMDC and ADC (BASE, at least) is routed through the hub. This even mean that the hub can manipulate the message (or simply avoid sending it). There is a solution to this though, and that would be to connect to the other party (as one would do when trying to download a file) and avoid having the messages being routed through the hub. (This can easily be achieved through ADC.)

Further, in ADC, one might send a private message to an entire group. We can use this to our advantage yet again by having a member of the group acting as the “hub”, so all messages are routed through that client. (Yes, I’m aware that there might be a problem if everyone is in passive mode…)

In a secure environment, perhaps even allowing certain clients act as a hub; that is, something similar as “hub link”, but for certain trusted clients only. (QuickDC apparantly is able to switch between being a real hub and true client.)

An important instance, which possibly have gotten the most attention the past year or so, is the hub list situation. Take down the address of a hub list, and you cause havoc.

DC++ formed a solution for this by caching the hub lists it has been able to download. This mean that we only “need” to access a list once, to have a semi-useful list. But how can we take it further? A solution that has been discussed is to use a service similar to Coral, where the actual file would be cached on the net.

Another solution would be to use invent a new command (a new INF-parameter in ADC would suffice, I think), where we’d say “Hey. This hub list address doesn’t work anymore. People, send me a new one!” (Eg, “NHhttp://www.example.com/hublist.xml” where the address would be considered as “this hub list doesn’t work”.) The clients could even send a hub list (or using some other command) when connecting to the hub, meaning “I got this or these list(s)”. The hub would then respond with “Oh, I got these ones”, where the addresses would be all of the hub lists the hub has gathered from the clients.

Another possiblity would be for clients and hubs to agree on another extension, where one requests the actual hub list file and the other party sends the file. Of course, a hub list that is only in circulation and never re-downloaded will be outdated in a while. So, we obviously need to download the hub list for ourselves, at intervals. However, this interval can, with mentioned techniques, be much greater than the situation we have now.

Are there other ways you can think of where we can decentralize DC?

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

Filed under General

← Older posts

Newer posts →

Design a site like this with WordPress.com
Get started