Resurrecting DSC

February 3rd, 2007

We’ve all seen the “<operator> operator kicked user because: reason” in NMDC hubs. One can of course also trigger it without being operator but that isn’t what today’s post is about.

The above text is purely that; Text. It isn’t a command in NMDC to tell the hub to get rid of someone. Instead, there is $Kick. DC++ just send $Kick user|and the kick message above… As the wikipage say, the command is sent to the hub and the hub in turn removes the user.

All this is rather basic and easy to understand. Don’t like a user in a protocol? Invent a command to get rid of them.

As things progressed over the years, ADC came and the command DSC was invented. DSC does the same thing as $Kick, besides giving some more info in one command, and that is notifying the hub that it should remove a user. And oh, DSC is also used to redirect people.

Meanwhile, an extension to ADC, User command was thought out. The extension is basically what we see today; The hub send some hub-specific commands that (basically) end up as a right-click command. (You of course have to have “Accept custom user commands from hub” enabled.)

At this point, you may wonder what DSC and user commands have to do with each other, and begin to remiss that 0.698 feature a change; that DSC has been removed.

Yes, the changelog for DC++ is not lying. DSC has been removed, though the ADC draft hasn’t been updated (yet). ‘Why?’ you might wonder. Well, it has to do with an assumption (though it will in most cases be true, it won’t always). In essence, ADC hubs and clients are assumed to support user commands, where the actual “kick/redirect feature” will exist.

This has several befinits; Hubs are in control over who have the kick/redirect feature (built in otherwise in DC++ if you’re an operator [NMDC atleast]), hubs are also in control over where the user can see the kick/redirect feature, clients doesn’t need to specifically add the kick/redirect feature (less code, less bugs, less clutter) and more importantly; Client and hub developers need to pay less attention to writing a basic hub.  The lack of DSC ’significally’ decreases code (mostly for hub developers, but still).

However, this of course have several downsides; Hub developers have to make an agreement on how the kick/redirect text is supposed to look like (otherwise, users would probably be confused if they see 15 different ways of kicking in 15 hubs) and it increases the level of difficulty if one want a basic hub with also kicking/redirecting capabilities (of course, one can just do the “+kick” approach). (Don’t be afraid, though, since we can always resurrect DSC.)

Don’t forget that you can make suggestions in our suggestion box.

Debug NMDC!

February 1st, 2007

In a previous post, I talked about how you enable ADC debug messages (and allows them to basically flood you in a busy hub). Since there aren’t many ADC hubs around and you might have found a problem in NMDC hubs, that option won’t do you any good. Unfortunately, there is no “easy” option to do in NMDC hubs, like the ADC option.

However, there is something you can do. First, compile DC++ in Debug mode. Then open up NmdcHub.cpp and locate the function “NmdcHub::onLine(const string& aLine)”. In it, place the line “dcdebug(”Debug line: “, aLine.c_str());” in the beginning. This way, you will display every line that is sent to you, in raw NMDC. And of course when you then run DC++ in debug mode, look in Visual Studio for the output.

The beauty of this is that you aren’t confined in NmdcHub.cpp or AdcHub.cpp. You can use this anywhere you want in the DC++ source. (Look for the #define to see how it’s implemented.) Just replace “aLine” with the appropriate line you want to see debugged.

 Don’t forget that you can make suggestions to topics in our Suggestion Box.

The parts of a hub list

January 17th, 2007

In DC today, a hub list is a vital part of the infrastructure. We all experienced it very well when Hublist.org (one of DC++’s default hub lists) went down.

A hub list consist of primarily two things. The actual hub list, a file, and a hub list bot (or crawler).

The former is what you insert in DC++, that DC++ download and display to you. The latter is something you as a user (of a client) never see. You might see the latter if you are running a hub.

The file is the actual hub list. It contain all the information you need; Hub addresses, hub names, requirements , rating, etc. The file can be distributed in two ways. (1) The file is sent clearly and DC++ (and other clients) start to parse it immediately. (2) The file is sent compressed. This technique is also used for the file lists. This means that the file being sent is smaller than the actual hub list. You have probably experienced it in other places, eg .zip or .rar. Having the hub list be compressed mean that whoever distributes the file and you will have to download/upload less information. If you see .bz2, the hub list is compressed. When DC++ see this, it decompresses the file and continues parsing the hub list, as in (1).

The actual hub list is of either DcLst style or XML. The former has been deemed deprecated by DC++ ( as of 0.696.). The file extensions for the two styles are .config respectively .xml. The difference between the two is very simple: You cannot change the formatting of a DcLst. It means that if someone want to add a field, eg rating, it is pointless since the clients can’t parse them. The XML allow hub list administrators to add and remove fields at their will, and client implementators can choose to display them or not. According to the DC++ wiki, the only available information in a DcLst is name, address, description and user count. If you look at a hub list supplied in DC++, you will probably notice more fields.

The second major thing a hub list need is a bot. This is essentially a normal client (like DC++) that is specialized in hub lists. The client, or bot, will connect to a hub, say “hello, I am a hub list bot. I just want to get some hub information. Bye.” The bot then proceed to process the information and (presumably) generate an appropriate hub list file. The file is then distributed by whatever means.

As a user of a hub list, you will most certainly never see this. However, most hub owners might. Most hub softwares out there today allow a hub owner to register with the hub list distributor and say “Hello. Can you please add my hub to your list”, and the crawling begin. (One might argue that registration is the third vital part of hub lists.)

Forum on hiatus

January 16th, 2007

The forums are on hiatus for now.  Anyone visiting the site has noticed its lackluster (understatement) response time.  Although the response time is largely due to attacks targeting dcpp.net or the machine it is hosted on, some of the legitimately generated load is from the forum.  I’ve taken it down to be kinder to our host.  I’d like to apologize to the end users looking to get support who are inconvenienced by this action.  If you’re one of them, please make sure you check out the FAQs.

Once upon a time there was a notification

December 21st, 2006

Once upon a time there was a notification and it caused hubs to be ‘flooded’ by DC++…

When you are changing your slots, or share, or… anything that is contained in a $MyINFO, DC++ will send a new $MyINFO, indicating a change of your client information.

This notification means that every hub you are on will recieve an abitrary amount of data. If people are sending this information only once in a while, like every hour or so, the hub will no problem with the bandwidth being used.

Mostly, this isn’t a problem. Joining/parting of hubs is done seldom on a regular basis. Slot changes follow in the same scheme since there isn’t much point in constantly changing your slots, unless you need to obey hub rules about hub/slot count, which is rather bound to joining and parting a hub. The automatic refresh in DC++ will (as default) kick in every hour, so that obey rather nicely with our “like every hour so” scheme. Plus, how often do you sit and press ‘Ctrl+E’ to refresh the share?

However, as someone may note by now, my assertions of the refresh timing are just that; Assertions. Meaning that (1) the “auto refresh” value is configurable and (2) someone might want to refresh their share often when a friend is after some specific set of files.

When a refresh is initiated in DC++, DC++ will go through the folders that are shared and see if some file is added or removed and then act upon it. Then DC++ will, if anything in the share changed, notify the hubs by sending a notification, as I said above.

If we apply this to our hourly notification, this isn’t a problem. However, if we apply it to a low value for “auto refresh” and/or a frequent manual refresh triggering, we got ourselves a problem.

Like, if you have automatic refresh set to ‘2′, DC++ will refresh the share every two minutes, and assuming that you have a constantly changing share, DC++ will send a notification every two minutes to every hub. Many hub owners probably say now “hell no. I’m going to complain!”. Well, don’t. You see, it used to be like that. And may I assure you, there were complaints.

Instead, a new scheme for notifications in DC++ was written, explicitly focusing on the share.

This new scheme meant that DC++ will keep track of when it sent the last notification. Since DC++ keep track of when the last notification was sent, it can choose to not send a $MyINFo if the last one was too close to the current one. This time can be found in the creation of $MyINFO in DC++, and it is 15 minutes (give or take a few seconds, depeding on some internal function stuff).

In essence, this is how DC++ decide if it should send a notification;
myinfo = everything about $MyINFO that DC++ is to send out, except the share
myinfo_share = the share info
if the last myinfo is different from the current myinfo; send the $MyINFO, or
if the last myinfo_share is different from the current myinfo_share and it has elapsed 15 minutes; send the $MyINFO
Note that this means that the 15 minute barrier does not apply if eg the slots change.

Also, note that this type of ‘cleverness’ by DC++, concerning the share, does not apply to ADC hubs; Only NMDC are affected by this.

Before someone comment “so does this mean that people can’t see my newly added files, if I refresh more often than 15 minutes apart?” No, it does not. This have no effect on your file list generation. It is only the notification for hubs (in other words, the hub window’s user list).

Don’t forget that you can make suggestions in our suggestion box.

DC++ like Visual Studio with a Service Pack

December 21st, 2006

When work on 0.699 begun, it was noted that it will require Visual Studio 2005 (or ‘8′) to be able to be compiled. When the DC++ version was complete, service pack one for Visual Studio had been released, and it is now a requirement for DC++’s entire feature set. DC++ will still be able to be compiled without the SP, but you will most likely encounter some warnings and weird crashes if you aren’t.

Don’t forget that you can make suggestions to topics in our Suggestion Box.

Debug ADC!

December 20th, 2006

If you’re wondering about how raw ADC messages look like in action, you should definitely enable AdcDebug.

Since most users don’t need or would want to see an option that could do that, there is no graphical way of doing it. Instead, you must add the following line to DCPlusPlus.xml;

<AdcDebug type=”int”>1</AdcDebug>

… where the ‘1′ indicate that you do want to see raw ADC messages and ‘0′ would indicate that you don’t want to see them.

Be warned; If you enter a busy hub, DC++ will ‘flood’ you with text, possibly causing DC++ to freeze. If you intend to use the information, I suggest you enable logging and use the log file to go over the info.

Don’t forget that you can make suggestions to topics in our Suggestion Box.

Cache it!

December 20th, 2006

Once in a while, there come a release which contain a little bit of everything. And 0.699 is such a release.

The new version mean a major difference for developers, as Todd mentioned.

A lot of people have flamed us for not including more hub lists (even though it takes, what, a minute [at most] to search the intarweb and replace them?), but there are now two more included lists. The hub list you download is now cached, which means that it’ll be stored on your computer and re-used next time you use public hubs (unless you explicitly tell DC++ to re-download it). This will mean that hub lists will take fewer hits and users of DC++ will always have a (or atleast one) hub list as a backup.

Beond caching the hub list, some other “security” things have been worked out. The most interesting is the fact that DC++ will now check if it ever was connected to a hub before it will auto connect to that hub. 

If you were around the time when cologic (the BCDC++ author) added user’s IP in the transfer view (around .307, I think), I think you’ll love/hate him even more. The reason? Well, he has now added user’s IPs in the hub frame! Note that all hubs don’t automagically send everyone’s IP, so don’t assume it’s broken because it may be blank on the hubs you frequent.

And oh… If you are writing FAQs on each settings window in DC++, you’ll have to change some of them; There’s a new page; ‘Tabs’.

All in all, I suggest you download this new version.

Don’t forget that you can make suggestions to topics in our Suggestion Box.

Client Information And You: The Stats

December 18th, 2006

Today, I’ll show you some stats on $MyINFO vs INF. Statistics are always hard to accurately create. Usually, they flat out lie or are over exaggerated. But I’ll do my best anyway…

The following is a structure over $MyINFO and INF. The $MyINFO example is what I gathered from the Wiki. The INF example is a direct copy of what is being sent when I took a fresh copy of DC++. Notice that I’ve used a minimum amount of information in both client informations.

ADC’s INF is first;
BINF M36B IDLI4ATHPD5P7NNWKI3RHMS5QFUXFCRKDTXXXCLHI NInick DEdesc SL1 SS0 SF0 EMemail HN1 HR0 HO0 VE++\s0.699 US5242 I41.1.1.1 U41 SUTCP4,UDP4\n
That is 143 characters, or 143 byte sent to each client in the hub. You may notice that the IP is there, and as well a UDP port. The third “word” (IDLI4A…) is (disregard the ID, since it’s the identifier) the CID. Now, you need to put on 42 characters to count on the instream for the hub (the PID is sent to the hub, it’s 39 characters, plus two for the identifier and one for separator [space]). This means that there’s 185 bytes in per user, and 143 out per user.

Let us take a look at NMDC’s $MyINFO;
$MyINFO $All nick desc <++ V:0.699,M:A,H:1/0/0, S:1>$ $DSL1$email$0$|
That conclude to 69 characters, or bytes. Wow. That’s a major difference, isn’t it? (I don’t know enough about NMDC to accurately say if this is the same in the instream for the hub as the outstream. Sorry. And oh, I’m not entirely sure the $MyINFO examples are exactly correct. It doesn’t really matter. Read on.)

Alright, but let us now consider this: Users don’t just idle in the hub. They interact with the hub. They change share and slots. Let us now consider the case of when a client change slots from ‘1′ to ‘2′.

$MyINFO $All nick desc <++ V:0.699,M:A,H:1/0/0, S:2>$ $DSL1$email$0$| — 69 byte
vs
BINF M36B SL2\n — 14 byte
Now we are getting a totally different picture.

Alright, after someone has logged in and sent a slot change;
NMDC: 138
ADC: 157 (199 - the first value is counting with 143, second with 185.)

Let us change our share from 0 files and 0 B share, to 1 byte and 1 file.

$MyINFO $All nick desc <++ V:0.699,M:A,H:1/0/0, S:2>$ $DSL1$email$1$| — 69 byte
vs
BINF M36B SS1 SF1\n — 18 byte

And the score now is… NMDC is 207, and ADC is 175 (217). I hope you can see the picture. NMDC scale very linear, at a “constant” rate of 69 bytes. As you can see, ADC will use less bandwidth than NMDC after the (”or around there”) forth client information broadcast. (Consider eg that DC++ has a automatic refresh that is triggered every 60 minutes [default], and if the share change “rapidly”, ADC gain some bandwidth in comparison to NDMC after the forth hour.)

Don’t forget that you can make suggestions in our suggestion box.

Client Information And You: The Information.

December 18th, 2006

If you’ve been reading this blog, you probably have seen me mention that one of ADC’s strengths is its extensibility. And the client information, INF, is not an exception.

The INF consist of two parts, an identifier and its data. This is a major change in regards with $MyINFO; The INF doesn’t have a pre-defined structure on how things are to be sent, and one can just send information if he or she pleases. (Bear in mind that the hub might disconnect you if you do.)

The INF in ADC add a lot of information that $MyINFO doesn’t; Global client identification, more specific transfer information and UDP port are among the new information that can now be sent. Ah, and also, the hi-jacking of the description, for the tag, isn’t an issue anymore since there are specific identifiers designed for all of the parts in the tag.

Something that hub developers may like, is the fact that there is no requirement to forward any part of the INF. Every client is required to work without any field. (Though, nick might be advisible. ;) ) Also, the hub have the power to require certain INF identifiers (and act upon it if the client doesn’t provide them).

Something that is a nice feature for hub owners is that everything is sent in a incremental way. This means that you only send those parts that actually changed. Say, if only your share changed, there is really no need to advertise what your nick is (since it didn’t change).

Unfortunately, the initial INF is very large compared to $MyINFO. This is what DC++ sends (note that not all clients do/will behave this way); PID and CID combination (CID is the global client identifier, and PID is a verification the CID is correct), IP-address (if you’ve entered it in settings), UDP port (same as previous), amount of files you are sharing and how much it is in bytes, version of DC++ (”DC++ 0.698″ eg), slots, e-mail, nick, description and how many hubs you are “normal”, registered and operator in. (There is a few more, but the list kept growing so I stopped.)

I’m sure all of you are now looking also at the draft, and noticing that the identifiers are only two characters. This is correct, and means that there is a restriction on how many different combinations there are. (I think the allowed characters are A-Z and 0-9, but I’m not sure. [I’m probably wrong, but it’s around that ball park.])

Alright, this concluses this edition of Client Information And You. Since I’m sure a lot are interested in some stats, I had next planned Client Information And You: The stats.

Don’t forget that you can make suggestions in our suggestion box.