Archive for the 'ADC' Category

Number your Result

Tuesday, July 11th, 2006

I assume you are by now a NMDC-search-hating person. All heil ADC’s search!

Yeah, I bit strong I know… But still. The NMDC-suckiness continues with the number of search results you recieve.

In NMDC, when sending a search, you will either get (from each user) 5 results if you are in Passive mode or 10 if you are in active mode. ADC have this restriction also. “Okay… Then what’s sucky if they’re the same?” Well, it’s a matter of which results you recieve.

In NMDC, there are no way to say “I want this, but not that”. In ADC on the other hand, there is; “Each filename (including the path to it) should be matched using case insensitive substring search as follows: match all AN, remove those that match any NO […] “. In laymans terms, “if I specify in the search that I want only file names (and paths) that have ’linux’ and doesn’t have ‘ubuntu’ in it (file name/path), I will only recieve results that have ‘linux’ in the file name/path and the sender of the results will have discarded all file names and paths matching ‘ubuntu’.”

So you dig through the archives, and find Filtering…, and think “hey! It says there I can filter out search results with -foo!”… Well, you’d be filtering the recieved results in NMDC. (Ehm, said ADC functionality, in DC++, doesn’t currently exist, mind you…)

If you don’t understand the problem; When you are sending a search in NMDC, the sender of the results does not do ANY filtering. He’ll send you the first 5 or 10 results said client can find. The client couldn’t care less if you don’t want ‘ubuntu’. But, in ADC, the sender of the results will know “hm, I can’t just blindly send results, this person has specifically said ‘ubuntu’ is not desired.”

Answer to Pop quiz: Downloading in ADC

Sunday, July 2nd, 2006

I think this quiz was a little harder than the previous, but nontheless we have a winner, and it is (again) poy. Congrats. You win a free trip to the public DC dev hub. (Blatant plug :D )

One of the reason I believe this quiz was more difficult was because I didn’t include the actual answer in the options. (Well, d)…) Another reason is because it (sort of) require that you have been paying attention.

The question was: Why can’t Jake download the file list or any other file from “john111/2″? Because Jake already have a transfer going from “john111″. You see, “foobar” and “john111″ is the exact same person, using the same client, but with different user names. I’ll soon get to why they are the same user.

The reason I chose this scenario with university hubs, is because users tied to a university often share IPs. This means that one can’t look at the IP for comparison if two users are the same. (If people wouldn’t have shared IP, this would be a nice clue as to why Jake couldn’t download.)

So, why are “foobar” and “john111″ the same user? They have the exact same CID. I wrote in the previous post that DC++ look at the CID to check if two users are the same. ADC natively require CIDs, meaning that DC++ doesn’t “artificially” create the CID of other users. In terms, CIDs are global, (or atleast are supposed to be) meaning that your CID is the same in one, two or 40 ADC hubs.

Since DC++ see that they have the same CID, it thinks “hey, same user, don’t start another download because I’m already downloading from that user”.


There is an issue with the scheme DC++ currently use - Most users won’t understand what a CID is (CIDs are infact displayed in the user list) or why DC++ won’t start another download (”what the… it’s not the same user! crappy program!”). There have been discussion on how one could notify the user, among them; treeview of each download (”click on a ‘+’ to expand the list of usernames”); displaying “username1,username2,username3″ (I think this would be the easiest - codewise); Have DC++ print “You are already downloading from this user. The userlist/file has been queued”; a download mini slot option (like the upload mini slot option - but applying only to certain files, like the file list). Can anyone think of more?

Pop quiz: Downloading in ADC

Saturday, June 24th, 2006

The second pop quiz is as follows;
‘Jake’ using an unmodified version of DC++ 0.691. He’s connected to 2 (two) ADC hubs with the nicks “jake99″ and “mary77″. He’s looking for the file A. He find user “foobar” in one of the hubs who have the files he’s looking for. This user is also using an unmodified version of DC++ 0.691. He start to download the file, going in 20 KiB/s and everything’s fine. But, he start to think, “what will happen if the user goes offline? better I auto search for it to check if there’s more sources”. And he does, and find user “john111″. Jake adds the user to list of sources (through the right click command menu).

Interesting in things as Jake is, he want to see what other goodies “john111″ has in his share. Jake tries to get the file list. Nothing. Nothing happens. He checks the queue, DC++ has properly queued the file list, but isn’t connecting. Nothing appear in the transfer view. The transfer view columns are fine, Jake can see that he has two downloads going (one of them the file A) and three uploads.

 But there’s no error message in the queue or the transfer view window. He deletes the file list from the queue, and tries again to download it. Same thing. Now, why can’t Jake download the file list? “john111″ isn’t blocking uploads by the looks of it in the search window (Jake can see that “john111″ has 5 slots open out of 7). Jake and “john111″ is both connected with Active mode.

The two hubs are both resident on the same university campus, where a lot of people connect from. Meaning, a lot of people have the same external IP. (Jake find out that “john111″ has the same IP as “foobar” and one of Jake’s uploads, and he draws the conclusion that those three are all living on the same campus.)

Jake asks his friend in the other room to try to download “john111″’s file list (and other files), and it works fine. It also works for other users in the same hub. Jake asks “john111″ to change his nickname to “john112″. No change in connectivity. “john112″ tell Jake to try and search for file B and try to download it. Same thing happens with file B. File B is now queued, but there’s no connectivity and no error message.

So; why can’t Jake download the file list or any other file? (File A has been downloading the entire time, now at 34 %.)

a) Jake is using different user names.
b) there’s a bug in Jake’s copy of DC++.
c) “john112″ and everyone else is lying, at Jake’s expense.
d) none of the above… (fill in what the reason is)

It would be neat if you have an explanation why you chose that particular option, but you don’t have to; I’ll explain later which option/answer is correct, and why.

SCH proudly presents $Search

Monday, June 19th, 2006

Ah, yes, today is a “why the NMDC protocol suck and ADC is so great”-post. And today’s protocol bit is brought to you by $Search (paid and sponsored by SCH in ADC) and the file types used. (You should have a look at the Search types post I made a while ago.)

Now, on to the (NMDC) protocol bit. All of the search types are “hard coded” into the protocol, meaning you will need to upgrade other clients to respond to your file type searches. This is unfortunately not enough of the NMDC sillyness. When you pick a certain file type in DC++, DC++ will change the caption of your choice (”Audio” eg) and to a number. This number is predefined (as the wiki post says) and cannot be changed (because otherwise, you’d recieve wrong search results or not get any - depending on what you change the number to). This basically means that you cannot tell DC++ (code wise, considering there is no way to do it in the GUI) to “search for _filename_ but only include audio extension AND video extension”. This is because there is no way to combine the different numbers. Now you’re thinking “but can’t you add them and the send that number out?”, and sure, you can do that. But you won’t get the result your after. Eg, “Audio” is 2 and “Compressed files” is 3. Now, if you add these, they (of course) become 5. Now, the problem is that 5 is “Executables”, making all of the other clients think you’re after “executables” and not “audio” and “compressed files”.

“Sigh… Every time you talk about NMDC, I hear something bad… Fine. So, what’s so good with ADC then?”

Ah, my dearest Watson, it is very simple. In ADC’s SCH, one can specify a “EX” (”extension”) when searching, and the responding client have to match files with atleast one of those EXs. This means that we can specify completely what kind of file types we want - even if the other client hasn’t hard coded any file extensions in its client).


Thursday, June 8th, 2006

You’ve probably seen a lot of references to ADC in the changelog for DC++, in the forum (people saying “no, this won’t come in NMDC, but in ADC” etc), the bugzilla, here and on the public DC developers hub.

What is ADC exactly then? It’s basically a way of defining how two clients (or client and server [hub]) communicate over the Internet. ADC is a protocol, just like HTTP (which you’ve probably noticed when you’re viewing web sites), FTP, IRC or NMDC. Think of this communication, the protocol, as two people in real life talking to each other. They both need to understand each other, otherwise they are just making noise with their mouths. Think of protocols as natural languages; English, French, Italian or Swedish.

ADC is not complete, but the current draft is what (basically) is going to be the final version.

What does this mean then? Well, it means different things, depending on who you are and what you want do.

For the common man, this is what ADC will bring (though, not necessarily will be in DC++);

  • Secure overall communication. This means the use of SSL (secure socket layer).
  • Secure password. This means it is impossible(1) for other people to find out what your password is when you’re logging into a hub. (Not depending on above.)
  • When searching, you can use regular expressions to accurately find what you are looking for
  • You can change nick when you are still connected to the hub (provided the hub allow you to).
  • Due to the identification scheme in ADC, different shares in hubs is possible.
  • Using partial file listing.
  • All text (between you and other users) are in UTF-8. This means that Chinese people can write characters and everyone sees them properly. Basically, any type of letter/symbol in any language will be viewable.
  • A native support for hashes (every client has to serve hashes).
  • If the hub chooses to, it can avoid sending main chat messages if you don’t want them.
  • Native support for “/me” (”* ullner is now away”). (That is, speaking in third person.)
  • Responses to searches can now be directed properly.

Wow. That’s a lot, ain’t it? And this is only what I can think of now. Think about when the protocol is finished!

So, what does ADC mean for developers?

  • A clear structure over what and when to send things. (There is no “spec” on how or when to send things in NMDC, only an semi-accurate order.)
  • We don’t need to have commands that are badly spelled ($LogedIn etc).
  • $ and | etc isn’t forbidden in commands.
  • Hub developers don’t need to depend on client developers to implement something for clients to safely log in.
  • One can change state and add features while connected.
  • Information about the client is now incremental, meaning you only send those parts that are changed.
  • Clients now don’t have to “guess” if two users in two hubs are the same.

So, I hope you have a better picture of what ADC is and what it can potentially bring.
(1) Unless the Tiger algorithm is broken, which is not likely in the next years.

Filtering Redux

Sunday, June 4th, 2006

In a past entry, Fredrik explained what caused the “Filtered” count in the Search Window. What is more interesting to me is the why. Why do all the search windows have to get all of the search results? It has to do with the design of the NMDC protocol by Jon Hess. The $Search sends out the essential information: search terms, size limitations, and search type. The $SR (search result) likewise sends the essential information: result type, directory name, file name, size. What is missing is a way to link a given $SR to the $Search that spawned it.

So, what happens when a user does two searches? The original NMDC client would not let the user do this. It didn’t have the ability to support more than one source for a given queued download, so there were no background searches for alternates. It also did not let the user open more than one window. DC++ does both, so it can have multiple searches happening simultaneously. To make sure each place gets its search results, it broadcasts them to all open search windows as well as the download queue. The windows then display the results that match their search criteria. This is the reason that ADC’s search mechanism has a token associated with it. Each search will have a different token, and each window will pick the results matching that token, with no guessing involved.

The limitations on the NMDC search also extend to other DC clients. Clients wishing to return hits based on the contents of the files will be filtered by DC++, since its search windows expect matches in the file or directory names.

New ADC draft

Saturday, June 3rd, 2006

The latest ADC is as of now out, version 0.11. Take a look here (.html) or here (.odt).

PAS has been changed so you might want to take a look at that. I see otherwise no apparant change, but I’m sure there are.

Ports in ADC and NMDC C-C

Tuesday, May 23rd, 2006

If you’ve checked your netstat lately, you will notice a port that is opened that you haven’t explicitly specified. But if you look closely, it is the port you’ve specified under Connection settings+1. (That is, you’ve entered 9999 in Settings, port 9999 and 10000 will be opened and ready for listening.)

I don’t want you to get alarmed here now, because this has nothing to do with “sending information about you and your computer” (aka spyware).

The port you have specified in Settings is the port that will be used in NMDC client-to-client connections. The “port+1″ port, will be used in ADC client-to-client connections.

Why can’t they use the same port? Well, the answer came from the master; The idea of using the same port in both protocols is of course great, the problem is the implementation of said idea. The implementation is basically just so difficult that there is little to gain.

I was poking around in the source code and I think I found the lines where “port+1″ is executed; Line 69 in ConnectionManager.cpp: lastPort++; firstPort = lastPort; Set here firstPort to something else than lastPort.

Moving toward ADC

Sunday, May 14th, 2006

The public development hub has now changed address. It is now adc:// This means that you need to run a client that support ADC.

The following clients support (atleast partly) ADC;
DC++ -
Elise -

It will not be a NMDC hub ever again. It is time we move forward.

Character representation

Thursday, March 9th, 2006

Everything you see in chatmessages aren’t always exactly what is sent and recieved. Atleast not in a Neo-Modus DC hub. Everything is displayed as it’s sent in an ADC hub (this is because of ADC’s lack of usage of certain characters).

Characters such as ‘&’, ‘|’ and ‘$’ are used by the N(eo-)M(odus)DC protocol. Therefore, if you’d try to send/recieve these characters, they’d be interpreted as commands.

Instead, all ‘&’, ‘|’ and ‘$’ characters are sent (and interpreted) as their respectively HTML representation.

For instance, ‘&’ is sent (and interpreted) as “&”, ‘|’ as “|” and “$” as ‘$’.