Direct Connect: Just These Guys, Ya Know?

Client Information And You: The Stats

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 $ $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 $ $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 $ $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 topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Client Information And You: My Information

It has undergone a few changes through the years, it has been through several heated discussions and a few have wondered about it day and night. No, I am not talking about Britney Spears’s belly. I am talking about NMDC’s $MyINFO.

The information you may find in $MyINFO is (the client’s) nick, description, connection type (and some more info on it), e-mail and share size.

This command is sent during login and will be completely re-broadcast if any of these parts change. As many may notice at this point is that this is quite annoying, stupid and pointless. If don’t get it, then consider the scenario where your share size change (constantly) while the other types of information remain intact. This will cause your client to send information about itself that people already know. Why should they want to see your nick or description again if only your share size changed? This is one of the short comings of NMDC’s $MyINFO.

One of the major changes made to $MyINFO (that some consider) is the “hijacking” of the description. This is the addition of the tag (that originally came from DC++, do to pressure from hub owners, requiring DC++ to notify how many hubs it was in [since the original NMDC client was only capable of connecting to one hub simultaneously]). Of course, this was more a client and hub implementation standard, rather than a protocol standard (there’s no definition of any of the NMDC commands, remember?).

Some decided, at some point, that instead of hijacking any other part of the description (or $MyINFO), that it would be best to provide (and get) client information through extensions. ClientID for “global identifier”, UserIp for getting users’ IP and so on.

What is great about $MyINFO, $ClientID and all of the other NMDC client informational commands? It is that they are relatively short and concise. They provide a nice deal for client developers, since they don’t require that you implement them all at once. They don’t rely on each other, so you can send one but don’t need to send the other.

Unfortunately, their problems are equally important to know. Like I said about $MyINFO, it (and other NMDC commands) has a problem with re-broadcasting of already established information. Also, none of the current commands are (easily?) extensible. That means that if you want to make a small change, you need to (1) change it in your client (duh!), (2) change it in today’s hub softs and, hopefully, (3) notify others by posting on eg the DC++ wiki.

This was everything from this edition of Client Information And You. Next up is Client Information And You: The Information.

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

Client Information And You

One of the important parts of NMDC and ADC, is the exchange of client information. In NMDC we have MyINFO and in ADC we have INF.

I had planned on discussing the upsides, downsides and everything in between about these exchanges. But instead of writing one massive post, I thought I would split them up in segments. So, I bring you Client Information And You, the series.

To start these series, I should explain what the actually do (beside the somewhat ambiguous “exchange of client information”).

So, what do I mean? I mean the exchange of client information. (Duh!)

This is the part of the protocol(s) where the client send specific information about itself to the hub (which then relay the information to the other clients).

This information ranges from nick, to client version to the amount of hubs the client is operator in.

These types of information reveal nothing of true importance, from a security stand point. And from a general point of view, they are simply informational, and only provide the information for the benefit of the network. Spoofing the information is extremely easy, although it require that you have some coding skills (or know someone who do).

Stay tuned for the next part in our series, Client Information And You: My Information.

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

Answer to pop quiz: Searching magically work

Since we had such a gigantic outcome of the last pop quiz, I thought I would wait posting the answer.

Riiiiiiiight.

Anyway… Let us get down to business. “Why was user B unable to find the file (especially when the switch was off) and why did it ‘magically’ work after 10 minutes?”

Well, I guess we need to clear up if the switch was on or off when he searched those 8-9 times. Of course, it was ON. This can be easily figured out by noticing that user A was able to search and thus meaning “user B” sent out a massive 8-9 searches at once.

So, does this give us more information as to why user B where unable to find the file, after the switch was OFF? First of all, you need to understand a crucial feature of DC++; If DC++ see a user that searches more than 5 searches in 7 seconds, it (DC++) will think of the searching as “search spam”.

Ok. We’ve all seen “search spam” in chat, and it’s pretty easy to figure out what it meant when we see it (though the exact triggering stats may be difficult to guess).

What most people don’t know is what happens after you see that “search spam” notice. What happens is that DC++ see and think: “search spam. huh, that client is trying to spam me with his searches. If he want to play that game, fine. I can play also”. This “playing” that DC++ does, means that DC++ automagically refuses to answer that client’s searches for the following 2 minutes!

So in the case of this problem, user B caused a “search spam” in the other user’s client and it refused to answer user B’s following searches. Since user B waited 10 minutes for the next search, the “search ban” had been lifted and the client was answering to user B’s searches.
And the side question, “Was AHUB a NMDC hub or a ADC hub, or does it not matter?” is most easily answered by looking in NmdcHub.cpp and AdcHub.cpp in the DC++ source. Well, since I don’t require you to do that, I’ll answer it. It was a NMDC hub, and simply because there is no such code for ADC hubs (in DC++). So you won’t see a “search ban”, and not even a “search spam” in ADC hubs.

The inspiring FAQ entry that I had in mind that mention this, is the How do I protect myself from search spam in DC++? article.

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