ADC draft information

April 10, 2007 by

Today’s post is going to be about ADC and the spec.

As ADC isn’t complete, there will be some small variations between revisions. One of the problems with the revisions, is that sometimes Jacek intend to remove or add something, and developers need to adjust accordingly when that revision is out. It would be better if people would know what would change, so they could do their work in time.

This post intend to document the differences Jacek has announced are going to happen with the draft. I’m going to try and keep this post clear and current, and I’ll update the post (remove items from the list) once a new revision is out (that takes care of what I’ve mentioned).

Have a look here for the list.

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

Filed under ADC, Documentation, General

Waiting Users and an upload queue

April 4, 2007 by Leave a comment

One of the windows that DC++ have is the Waiting Users window. This window, as the name suggests, will display those users who are waiting for a slot from you.

DC++ know what file and who it is requesting it. When someone request a file and you don’t have a slot open, your client will then respond with a “No slots available.” As DC++ (and other clients) don’t request the exact same file over and over, but try the entire download list, you will see a growing number of files in the window from the same user.

The important thing that the window do represent vs what the window do not represent, is that it only displays the requested files by others. Meaning, this isn’t a upload queue. The person at the top of the list won’t get a slot sooner than someone in the middle or at the bottom. You see, there’s no upload queue at all in DC++. Whoever try and download a file while you have a slot open will get the slot. This is why some clients cheat, by “hammering”, i.e. trying to get a slot constantly, increasing their chances that they’ll get one.

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

Filed under Documentation, General

Why do I have an upload that keep saying “Connecting…”?

April 4, 2007 by 1 Comment

At the version 0.696, support for the old NMDC-style file lists, .dclst, was dropped. This meant that you wouldn’t be able to download from users who serve these lists. If you try, you’ll recieve the error message “Remote client doesn’t support…”. This message isn’t something that these old clients say to you (no, we’re not psychic), it is something your client say internally.

When a client that doesn’t support the new, and improved, XML file lists, request the .dclst, DC++ will say back “Error. No such file.” When DC++ try and download a file, even if there’s an error, it will continue to try over and over again. (This mean that these users need to find a different source or upgrade their client.) The reason people keep popping up in “Connecting…”, is because after your and the other person’s client has started communicating (saying “hello, I want to download a file”), DC++ will display anything after as an “upload”. This includes when you say “no such file” or “no slots available”. (You will not see the latter upload very long since DC++ [on the other end] will wait a while before trying to grab a file again.)

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

Filed under Documentation, General

Interface change in upcoming versions

April 3, 2007 by 3 Comments

A very large change in upcoming versions of DC++ is that the interface will change. Hopefully, the interface change will be transparent for users, and only be noticeable for developers.

So, what is changing? Well, the intent is to remove all of the WTL code, the code that handles the interface, and translate it to Smartwin code. The code is similar, but not exactly the same. This translation process will take quite a while, so you need to have patience.

The fact that DC++ is going to use Smartwin, instead of WTL, will mean that we will get rid of the dependancy for Visual Studio. DC++ will still be able to be compiled with VS, but you aren’t required to have it to compile DC++. From now on, one can compile DC++ with mingw. All in all, DC++ will be able to be compiled with completely free (of charge) tools. (Read compile.txt for specific instructions.)

No, Smartwin does not mean that one can natively run DC++ on Linux or Macintosh. Luckily, there’s projects like LinuxDC++ and MultiDC++, for respectively system.

If you are interested in translating the code in DC++, everything in “#ifdef PORT_ME” (and the corresponding “#endif”) is the old code that need to be translated.

If you have no idea what I’m talking about, let me put it this way; Every window in DC++ need to be re-written “from scratch”. (No, this does not mean that entire DC++ need to be re-written.)

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

Filed under General, Source code

The future of DC++

April 1, 2007 by 3 Comments

For the past weeks, there have been extensive talks on the future of DC++. The specific topic of the discussions was spawned by a company that contacted Jacek and Todd. The company wanted to add official support for DC++. Support in the form of donations and various hardware solutions.

Last night, the company and Jacek signed a contract. The contract will come into action in mid-May of this year.

“What company?” you may ask. Well, it is actually IFPI. Yeah, you may think we’re nuts, but I promise this will be a great solution. I can’t share the official contract, but I can tell you about some stuff that will happen.

Some of the new stuff we will be getting:

  • A distributed network for our website so we’ll never have to worry about it going down.
  • A dedicated server for the DC development hub.
  • New machines to use for the further development of DC++.
  • A chunk-load of money.
  • Special I-love-IFPI mouse pads. (They’re really nifty.)

This will also bring some new features to DC++:

  • New and improved file sharing filtering.
  • New and improved search filtering.
  • New and improved download filtering.
  • We will of course redirect version.xml to our new distributed network.
  • New rating system were hubs, among others, will get notified what you’re downloading and uploading to and from whom.

And much more.

Brace yourself, because DC++ will be better than ever!

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

Filed under General

Detecting your hub software

March 25, 2007 by Leave a comment

There exist many hubs for NMDC, and for ADC. Although the amount of hubs supporting the former is greater, the latter is increasing.

As hubs get developed, they are intended for an audience, and the hub developer will try to market the software so more people will use the hub.

One of the market tricks hub developers use is that they will broadcast what the hub is called, when your client connect to the hub. You’ve seen it; “This hub is using DCH++” or some other type of message.

Though, the target audience is not just the normal users of the hub. It is also a hub list. The hub list can then, through either a website or the actual hub list file, broadcast what hub is being used. This is great advertisement, as the hub developer don’t need to do any active marketing.

However, the hub list isn’t composed of some guy in a basement manually typing the hub software used. Hub lists use programs to determine the hub software. This mean that the program need to look at a specific pattern to identify a hub.

When a client connects to a hub, the hub will broadcast the software. As we have two different protocols, we have two different methods of doing so. In NMDC, the hub list will check the $Lock the hub send. Respectively in ADC, the hub list will look at the VE parameter in the INF.

To do this effectively, Gadget (one of the people behind Hublist.org) published Visual Basic code to be able to parse the information in the lock, so it’s NMDC. But it shouldn’t be very difficult for you to replace the “$Lock” stuff with “VE” or some such. In the code, regular expressions are used, so you need to find the corresponding function in your language to do the same thing.

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

Filed under Documentation, General, NMDC, Source code

Command extension

March 17, 2007 by Leave a comment

If you have ever been looking at some documentation or discussion about NMDC, you probably have noticed that it’s not extensible (or at least easily).

But why isn’t it?

First of all, you have to understand that the protocol Jonathan Hess originally wrote wasn’t intended for third parties. There were no one that were supposed to look at the code or the traffic and say “hey! Shouldn’t we add this feature?”

With that in mind, let us get down to the technical stuff. When you send a command in NMDC, the other side “know” how to parse it because there have been discussion how commands are supposed to look like. Well, not really a discussion. More like “NMDC did it like that and we shouldn’t break backwards compatibility because we’d be breaking a lot of clients and hubs.” So, when a client or hub see information in a command it doesn’t understand, it will ignore the entire command or, hopefully though not likely, the bad part. The problem with this is that there’s no, and haven’t been any (as far as I know), discussion concerning extending certain commands. (Though, there’s eg $Supports which have been agreed, or forced by arne, to use certain rules when being extended.)

So, when you add something in NMDC, you will need to enforce and/or notify that change to other clients and hubs, since they will most likely break with your change. If you add something in ADC, you will not break clients or hubs since there’s a native requirement for receipents to handle unknown data. (However, of course, you will need to have the other clients and hubs understand your command if you intend for them to use it, too. You will never get away from this.)

Filed under ADC, General, NMDC

Search the active ADC and the passive NMDC protocol

March 17, 2007 by 2 Comments

One of the big culprits in DC traffic is searching. For hub owners, this is a crucial item, as it may make or break their love for either protocol. The less traffic, the more overall users.

So, let us jump right in. I’m going to break this up in two posts. The first post (this) will be about the actual searching, and I’ll later bring up the responses. I’m going to go ahead and begin with active searching and later continue with passive.

NMDC: $Search ip:port F?F?0?1?motd$txt
This is 35 characters. Atleast. (I used single digits in the IP and port. [x.x.x.x:x] Remember that a lot of users aren’t on single digit ISPs. Or are using port 1-9.)

ADC: BSCH BABA ANmotd ANtxt TOsometoken
This is 26 characters. Atleast. (I used a single character for token to come up with 26. The token may vary on implementation. It can be less or more, depending on how many searches one would want to have simultaniously. It’ll probably be less than 10 characters though, but one can’t say that for sure.) Now, this isn’t entirely true, with the 26 characters bit. You see, if you’re an active user you will most likely broadcast your IP and port when connecting. However, as this is done only once, it doesn’t matter much. If we’re going to be picky, it’s 14 additional characters in the INF. (Going by the same rules that I used previously concerning IP and port.)

Moving on to passive searching…
NMDC: $Search Hub:requesternick F?F?0?1?motd$txt
This is 29 characters, excluding the nick. Here again, the length of the nick matter.

ADC: FSCH BABA ANmotd ANtxt TOsometoken
This is (also) 26 characters, and the same rule about the token apply here. Mind you, here, the broadcasting in the INF isn’t performed. But other than that, it’s just a matter of a B for a F.

Comparing NMDC and ADC searching in active mode is definitely a clear win for ADC. The initial broadcasting is forgiveable since it’s only done once and isn’t rippled through the future searches. (It’s up to the clients to keep track of the IP and port.) If we look at passive searching, ADC will remain the same (well, ‘better’ since there’s no initial broadcast), and NMDC wil be slightly better than its active counter part. However, as the nick of the user is important, and is seldom one or two characters, ADC will win here, too.

Filed under ADC, Documentation, General, NMDC

LockToKey examples

March 14, 2007 by 3 Comments

The DC++ wiki is down, so all you developers out there are out of luck. Until now… Well, at least for one thing;

The LockToKey examples. Since it’s quite a complicating thing to reverse engineer, here’s the examples that could be found through the wiki.

Note that I haven’t written any or have any knowledge about them.

Sorry about .doc, but WordPress didn’t allow .rar. Just rename the file to .rar. (The reason I’m not pointing to the cached Google page is because it might change over night.)

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

Filed under Source code

Time left: 584 million years

March 14, 2007 by Leave a comment

In the upcoming version, there will be a fix for (as noted by the changelog) “time issues with DC++ running for more than 49 days”. This changelog entry mean that if you have your system for running more than 49 days, DC++ will most likely crash. This isn’t a new issue, it has existed for a while, though no one had gotten around to fixing it. (Though, fulDC has had it fixed a couple of versions.)

When the system starts, a specific variable is set that keep track of how long ago it was since your computer had started. When creating the variable, one must set its size as well. If you set the size of it to 100, and you assign the variable 102, the variable will overflow and nasty things will happen. This is also what has happened with DC++.

The size for this specific variable is 32-bit. This mean that the maximum size is 2^32, or 4294967296.

Like I said, this variable keep track of when the system was started, in milli-seconds. So if the variable would read 10000 it would mean that there have been 10 seconds since the start. Let us now convert the maximum amount of milli-seconds to maximum amount of days. This yeild; 4294967296 / 1000 / 3600 / 24 = 49,7102… days. Now look back on the changelog entry. It says 49 days, too.

So, if this is fixed, how is it fixed?

This is fixed by setting a new maximum size for this variable. “But… Then you’ll just end up having to fix that, too!” Well… That’s true. Sort of. If you’re planning on living for a couple of million years, that is.

The new maximum size is 64-bit. This mean that the maximum size is 2^64, or 18446744073709551616 milli-seconds. Let us convert this to days, again. 18446744073709551616 / 1000 / 3600 / 24 = 213503982334,6… days. Seems days aren’t enough. That’s 584942417,3 years. Yikes! OK, this mean that there’s 584 million years until DC++ will crash!

So you see, you don’t need to worry about this issue any more. :)

[If current DC++ crashes, and you restart it, your system will obviously still be running for more than 49.7 days. However, as the variable overflow, it is also reset, so you’ll have another 49.7 days until DC++ crashes again. Repeat ad infinitum.]

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

Filed under Documentation, General, Source code

← Older posts

Newer posts →

Design a site like this with WordPress.com
Get started