Client Information And You: The Stats
December 18, 2006 Leave a comment
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 I184.108.40.206 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
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;
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
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.)