The target of a path

November 25, 2006 by Leave a comment

The FAQ on “could not open target file: …” explain why one would get the message. However, you may experience this message even if your paths are set up correctly. You can actually experience this with Windows Explorer, although in a (visually) different manner.

When DC++ download a file, effectively creating the file on your system, DC++ ask Windows “hey, I want you to create the file named ‘this’ and create it ‘here’, and I’ll stream the information to the file.” The problem is that the way DC++ ask Windows to create the file.

Windows’ basic “go and create the file“-function restricts the amount of characters a path can consist of. Specifically, 259 characters (“c:/” is included in that). Unfortunately, this is the function DC++ use. This means that you can only create folders and files of a specified length. If you attempt to download a file that will break the 259 character limit, DC++ will tell you so. Well, specifically, Windows does. DC++ just shows it to you in a presentable manner.

So, what can be done? You can attempt to hack Queue.xml by using “\\?\C:\” instead of plain “C:\”, but I’m not sure how well it will work.

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

Filed under Documentation, General

Pop quiz: Search magically work

November 23, 2006 by 2 Comments

DC++ has a lot of features and it’s quite difficult to list them all. But we try to, through the changelog, FAQ, help file, wiki, forum and this blog. However, it is often the case that when we do list a feature, it is lost in other pieces of text.

One of these features, is a feature that is explained in the changelog and can be found in the FAQ.

But instead of me explaining the feature, I thought we’d have yet another pop quiz.

User A and B are on the hub AHUB. The hub is designed to on and off queue messages*. Especially searches. The hub queues searches by 10 and THEN send out the search queries so users can respond. This means that until 10 searches has been carried out, the 9 searches (before the 10th) are in limbo. The ‘on and off’ switch is that when 100 searches are done (10 blocks) the message queue is disabled for 100 searches and then turns the message queue back on. And so on and so on.
User A tells B to search for AFILE. User B try to, but nothing happens. He closes the search window, and try to search again. Nothing again. He does this 8 or 9 times, but to no result. He closes the search window, and tells A that he doesn’t get anything. User A try to search and he is perfectly able to find it. “Huh? How can you find the file and I can’t?” User B tries again to search and nothing shows up (AHUB’s switch is set to OFF at this very moment, mind you). He thinks “perhaps there’s something wrong with my connection. I’ll wait a while”. After 10 minutes, user B tries to search again, and then is able to find the file in question.

Note that there were/are no problems in regards with active/passive.

Also, A, B, and the person with AFILE are all using the latest DC++.

Here is the question: Why was user B unable to find the file (especially when the switch was off) and why did it ‘magically’ work after 10 minutes?

As a small side question, which is ‘more troublesome’ to answer; Was AHUB a NMDC hub or a ADC hub, or does it not matter?

(I realize that it may be difficult to wrap your head around today’s pop quiz but when you know the answer, you hopefully will understand the reason for the complex scenario.)

* I have no idea if this would be a good or bad strategy.

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

Filed under Documentation, General, NMDC

Happy birthday!

November 17, 2006 by 1 Comment

It is, as of now*, exactly 5 (five) years since DC++ was released to the world! Happy birthday DC++!

A lot has happened during the course of these years. The things I remember clearly are;

  • When the DC++-tag was introduced. The massive shouting in hubs about a new and ‘weird’ client, reporting all kinds of crazy stuff!
  • When there was an obvious usage of DC++ vs the NMDC client – around (DC++) 0.181 or something like that, I think?
  • When DC++ restricted the amount of users you could kick in one sweep. (It was 20 or something like that.)
  • Running the NMDC client to “see how it was waaaaaaay back”. Wow, it was awful compared to DC++.
  • When DC++ displayed non-operators with keys all of a sudden.
  • The IP showing in transfer view. *Wow*. Just… *Wow*. (And you know, in upcoming versions, the IP for others will be visible in the hub window too.)
  • The sudden and non-obvious disappearance of Neo-modus.com (or whatever the link was) and DC++’s “triumph”.
  • The appearance of a few mods having segmented downloading.
  • TTH! Oh, my god! TTH! One could actually disable it once… Heh.
  • When ADC was introduced in 0.402.
  • MiB vs MB etc…
  • I begun work on DC++.
  • The new icon for DC++.
  • Help file… Now, go read it. Pronto!
  • Default hub list set to the ADC hub list.
  • When DC++ chose to not download (or even display) non-TTH files.

What are your memories for the past years?

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

* It is now exactly 2006-11-17 20:38 for the blog at least. It’s on UTC-4.

Filed under General

We can always hope…

October 21, 2006 by 2 Comments

In my last post, I talked about how you added a feature to the protocol and how you signal that you support it. However, you may have gotten the impression that you have to signal that you support something, but this is not true. Even if you support a particular feature, you don’t actually have to signal it.

Let me take an example. In NMDC, there is a distinction (well, not in the protocol, but by the hubs and clients) between “hub topic” and “hub description”. The hub description is used for when a hublist checks you hub, and then displays that description on their website or something. But “topic” is the name of the hub smashed together with the topic, separated with a “-“. (Yes, this is very ugly.) In ADC, there is also no way of saying “this is the topic”. However, due to ADC’s easily extensible interface, it is possible to have the hub send a parameter that isn’t in the base protocol, and one we don’t actually need to advertise we know (before we send it).

There are two possible things the hub can send, depending on whom should get it. Let us think about who would want a topic vs description. 1) the users in the hub or 2) a hublist bot.

To have 1), one would need to change all clients to accept a new parameter. Eg, “TP” (“ToPic”). The hub will then send NIthisismyname DEthis_description_should_be_used_for_hublists TPthis_is_some_random_topic. And if the clients doesn’t understand TP, then they’ll simply ignore it and use the DE-parameter as a topic. This solution’s main problem is that so many clients “need” to change its behaviour and accept TP. This is where 2) is better.

To have 2), one would “only” need to change all hublist bots. Eg, “HD” (“Hublist description”). The hub will then send, instead of TP as in the previous example, but HDsome_description_for_the_hublist. This solution is somewhat better then 1) because there aren’t that many hublist bots that need to be changed. (Heck, at the time of writing, I only know of one hublist bot for the ADC protocol anyway.)

However, the point here is that the hub/client doesn’t need to advertise it supports TP or HD (or any other command or parameter). The client/hub can just send the information, and hope (yes, hope) the other end understand it.

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

Filed under ADC, Documentation, General, Source code

SUP? I’m good, I have ADC, Ya Know?

October 20, 2006 by 3 Comments

One of the most interesting features in ADC is the ability to signal that the client or hub support some feature, and that others can take advantage of that. This is not all too different from NMDC’s (hacked) $Supports. In fact, they represent the same thing; The ability to support a particular feature. These features should only be things that are being transmitted between clients and/or to the hub, since it’s no use signaling that you have the ability to have a Notepad built in the client.

There are three ways a client will signal it supports something.
1) To the hub (usually/probably in the initial connection state). Here, hubs may (should) decide to allow clients that support a particular feature the hub owner(s) would want users to have. The hub may restrict clients if the clients signal they support a particular feature, or if they lack the support of another. It’s all very “hey, I support this and that. May I enter?” If the hub sees the clients supporting a feature the hub doesn’t know about, it can/should let the clients through. With ‘should’ in that sentence, the clients have the ability to be up to date with features, while the hub could be extremely old and without any piece of knowledge about the new features. In NMDC, hubs and clients need to be updated when one either are updated with a new feature.
This part is signaled as HSUP ADfeaturename ADanotherfeature. All clients and hubs must support BASE, which is the ADC draft. Every feature must be 4 characters, and all upper case.
2) To all clients, in a broadcast manor (usually/probably in the connection stage). This is signaled in the INF, where you send BINF SUfeature, otherfeature,nfeature. (B == broadcast) As far as I know, there is no way to signal to specifically add or remove a feature in this way, so the client probably need to send the entire feature list. Again, this must be 4 characters and all upper case.
3) To specific client (usually in the connecting stage for a download). Here, you can send the SUP list or the INF list, which ever you find appropriate.

Sometimes, the user (or client) may want to say “hey, I don’t want to support/use this feature anymore, so don’t query me about it”. A simple checkbox in the client/hub can suffice for the meaning of “enable/disable this feature”. This is an interesting feature (in ADC) that NMDC doesn’t. NMDC has no way of saying (while connected to the hub) that the client doesn’t want to support a particular feature. But in ADC, the client can signal that it doesn’t want to support something any time it want to. (Whether the hub will approve of removing a that feature is something else. It may get you kicked out of the hub.)
Clients (and hubs) can signal that it has stopped supporting a feature by using HSUP RMremovethisfeature.

So, let us create a feature, and see what we need to do. Say we want a way to tell people when (you’re) searching that you also want to receive back the entered e-mail the other user got. (Why? Well, I don’t know…)
Now, let us call it SINF (“search inf”), where we have also abstracted it so much that one should be able to “want” anything from the INF. Eg, the client version or the e-mail. So we signal SUP ADSINF (for the hub), and then INF SUSINF (for the clients). Now, we also say that everyone that is able to send the request, should also be able to send the result back. (So we don’t have to come up with another command. Now, whenever we send a search we also signal “EM1”, meaning “give me the information in EM. (EM == e-mail). The other clients that support the SINF feature, will then send back “EMthis.is.my@email.com”. What is particularly interesting here is that the hub doesn’t have to send the EM1 to every client in the hub. The hub can keep a list of everyone that support SINF, and only forward that part to those clients. There’s no reason a client should get EM1 if it doesn’t even comprehend what that means. A little more hub work == less bandwidth cost for many. (The client, if it see something it doesn’t know, will anyway only discard it.)

There aren’t any particular restriction when signaling. You have to make sure the extension and/or command name is unique, since otherwise it could lead to clashes. And of course that everything transmitted in ADC (command names etc) are always in upper case. Beyond that, what restricts the programmer is the amount of combinations for feature name (A-Z, 0-9) and the programmer’s imagination.

(Yes, I know, I used lower case for the above features, but it didn’t look so nice with upper case, and the blog is weird when it comes to certain brackets…)

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

Filed under ADC, General, Source code

Visual Studio 2005

October 19, 2006 by 2 Comments

As of the next release of DC++, the project files will be incompatible with Visual Studio 2003 (see: svn 677). For many developers, myself included, this means an upgrade. Previously, Microsoft published Visual C++ .NET [2002] and Visual C++ .NET 2003, which were priced at around $100, and would compile DC++ just fine. For their “2005” product line, they dropped the standalone C++ environment, leaving me in a bind. It turns out that owners of Visual C++ .NET 2002/2003 are qualified to purchase the Visual Studio Standard 2005 upgrade, which retails for $200. I just ordered received my copy and if this post isn’t updated, you can safely assume it works for compiling DC++.

The Visual Studio Express 2005 package is free, but it doesn’t include ATL. The above is the least expensive way to compile DC++, really.

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

Filed under General, Source code

The case of the missing Pi

October 12, 2006 by Leave a comment

As ADC natively require UTF-8, “all” text should be viewable. Swedish, Russian, Greek or Chinese, everything should look fine.

However, since a couple of versions back, I have not been able to see certain characters, which should be perfectly viewable in ADC and DC++. (Eg, pi (Π) or psi (Ψ).)

To start with my hunt, I looked at my Ubuntu box, where I have LinuxDC++ installed. As LinuxDC++ use DC++’s core, it could point in a correct direction as to why I didn’t see certain characters. I was able to see them perfectly fine in LinuxDC++, but I wasn’t completely confident that there was a problem in DC++ itself because of one major reason: LinuxDC++’s core is based of DC++ 0.691. Although it’s a fairly new version, it is still “old enough” to not have this particular bug.

Next, I fired up Elise, and it showed the same as LinuxDC++; all text completely visible. Although Elise is written in Java and is totally independent from DC++, it gave me a vital clue; ADCH++ wasn’t doing anything it shouldn’t.

I then proceeded and downloaded DC++ from the SVN, and compiled first in Debug and later in Release mode. The reason I did this: I needed to make sure I can at all see those characters in both modes, because there might have been some trouble with a debug version (provide more information and can break at specific places at will [crash and burn is good]) versus a release version.

Before I proceed, I should mention that I don’t have any “special encoding charset” or anything similar installed on my XP-machine, and it was possible that that was the problem. (My Ubuntu-box of course has a different setup, and Java isn’t “run in Windows” in the same sense.)

As I fired up the Debug version, in a folder which had no previous files from DC++, I experienced no trouble whatsoever with writing and reading above characters. “Ok. It’s viewable in DC++, at least. Let me see in Release.” To my surprise, here again were no difficulties.

At this point I knew the “special encoding charset” wasn’t necessary, as it worked for a freshly compiled version of DC++, both in debug and release mode. So, where could the problem be? Well, the only place where DC++ store anything about its settings is in dcplusplus.xml. I swapped the file with a clean one (untouched and without my own changes to it). “Yes! I got characters!”

While there are a bunch of settings in DC++, there are few that deal with how DC++ look and the characters that are being displayed. In Appearance there is an option to set Language file, and in Colors and Sounds, there are a four options that involve the appearance of DC++. I decided to rule certain features out; The Language file option doesn’t handle text coming from hubs, it only handles with text that is in actual DC++; Select Window Color, since it’s just color; The Uploads and Downloads options fall in the previous color category as well. So, what’s left? Well, Select Text Style. I remember having set the text style to MS Sans Serif. (This is not the same thing as Microsoft Sans Serif.) I changed the type to Microsoft Sans Serif (works with others as well, I suppose), and restarted DC++. Afterwards, I was perfectly able to see all those crazy characters in DC++!

So if you are in an ADC hub and see weird characters (that you can assume is not actual characters) (“Ctrl+Backspace” is the common characters one see if one doesn’t see the correct ones) it is not the fault of DC++ (well, perhaps, but still) but the text style you’ve chosen.

So, MS Sans Serif did it in the Colors and Sounds page with a text style.

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

Filed under ADC, General

Approaching 0.7…

October 10, 2006 by 7 Comments

And the versions keep pouring in… Today it is 0.698 that has been released.

 0.698 contain a vital fix for a security issue, where a remote client could crash you, without you knowing or could do anything about it.

We are approaching a ‘Stable’ release, but remember; a new version become ‘Stable’ only when there have been enough testing on it, so tell everyone about the release and test the shit out of it!

Filed under General, Security

“Why is DC++ trying to send email?”

October 9, 2006 by 1 Comment

“… or connect to FTP, or telnet, or DNS or …”

This is a question that comes up regularly on the support forum and the short answer is: It isn’t.

The slightly longer answer is that this message is being produced by a software firewall which is misinterpreting what DC++ is doing, in a naive (one might even say stupid) manner.

The even longer answer requires a bit of knowledge about “How Things Work”.

Firstly, two pieces of information regarding setup:

Secondly, how a download (in Active mode) proceeds:

  • You want to download a file from me, so you tell me this.
  • I tell you to connect to my listening port.
  • You connect to my listening port and after some handshaking, the download begins.

Seems fairly straightforward, right? Well the problem comes with the listening port I choose. This can be any number between 1 and 65535. In fact, I can pick a port that is commonly used by another network service such as port 25 (SMTP) which is used for sending email.

When you connect to my listening port to start off the download, your firewall notices the activity on port 25 and springs into action. It thinks you are making a connection to an SMTP server to send mail, so in a Clippy-esque fashion, it says to you “It looks like you’re trying to send email! Would you like me to allow that?”

If the firewall were to look at what was being transmitted, it would clearly see that it has nothing to do with email. But it blindly works based solely on the port number and throws up a spurious warning message.

So in conclusion, take what your firewall tells you with a pinch of salt.

Filed under General

Download to default download

October 9, 2006 by 1 Comment

Something I use frequently and I’m sure many others do as well, is the ‘Download to’ option one can find in the right click menu when you click on a file in a file list or the search window.

There exist a similar window in most other applications as well, all varying the default folder. That is, the folder that will show up first when you click on “Download to”.

In most applications, the default is My computer. However, in DC++ it is the default download directory.

‘Why?’ you ask? Ah, excellent question my dear Just These Guys, Ya Know?-reader. You see, this is not a technical restriction. It is very much an intended feature and it’s quite an old feature. And the feature is soon pushing 5 years… It was added to DC++ 0.13, which was released 2002-01-19. Ah, the good ol’ times…

Filed under General

← Older posts

Newer posts →

Design a site like this with WordPress.com
Get started