DC Protocol Guide (Complete)

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Locked
Sid
Posts: 56
Joined: 2003-01-07 18:13
Contact:

DC Protocol Guide (Complete)

Post by Sid » 2003-04-30 02:28

Well i finaly finished it! Its been kinda siting on my desktop for a few months awaiting a few tweaks and i think its just about done. I may add non NMDC commands in the future but as of right now its just going to be NMDC. Check it out and let me know if something is missing or incorrect http://www.1stleg.com/index.asp?sArea=Projects
Sid

[email protected]
http://www.1stleg.com
[url=dcHub://Greed.1stleg.com]dcHub://Greed.1stleg.com[/url]

aDe
Forum Moderator
Posts: 138
Joined: 2003-01-07 09:14
Location: SE
Contact:

Post by aDe » 2003-04-30 02:36

The login example is titled "Download example" which must be wrong.
Also, about the hublist registration; NMDC hub does use that special formula, I think the reason you see it as random is because you're using the wrong localport. It is not the hub's listening port, but rather the random outgoing port that the winsock selects!

Btw, TasMan claims his hub handles registering to the NMDC list, so you might want to check the source for that hub; http://sf.net/projects/shadowdc

ButterflySoul
Posts: 210
Joined: 2003-01-23 17:24
Location: Nevada
Contact:

Post by ButterflySoul » 2003-04-30 03:40

Very nice doc =) A few comments for the "$MyInfo" section, in "client to server" :

I'm not sure if it's permitted for a client to send this again if the information changes.
Yes, it's permited. Actually, they're even expected to =)
Clients might also resend their $MyInfo on a regular basis, even if the info itself hasn't changed.

-----
SX says (if I understand right) that the last byte of the speed is selected from the ascii values of 1 for normal, 2 for away, (...)
Yes, you understood it right =) The extra character after the speed is how the NMDC Clients determine which icon to show for each user in the list, and how the NMDC Hub determines the value for the (undocumented) isAfk property of each user object.
[CoZ] Children of Zeus
-----
Shadows DC Hub - VBS and JS scripting at their best

TasMan
Posts: 196
Joined: 2003-01-03 08:31
Location: Canada
Contact:

Post by TasMan » 2003-04-30 03:40

Errr are you sure 'bout that aDe?

Because with VB winsocks, you'd have to do some work to get the outgoing port (it always reads 0 unless you set it).

Hmmmmm but I was on the NMDC list at one point (I've never registered a hub at this address before), with the correct amount of users. But I use the localport as the hub's listening port, as it was the only thing that seemed to make sense.

Does sandos' server also check? Either way, I was both both lists with the wrong special byte =p (assuming it isn't the listening port).

(*prepares to do more research on this*)
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....

sandos
Posts: 186
Joined: 2003-01-05 10:16
Contact:

Post by sandos » 2003-04-30 03:56

TasMan wrote:Does sandos' server also check? Either way, I was both both lists with the wrong special byte =p (assuming it isn't the listening port).
Mine does not check the Key. And he is right, as near as I know.

aDe
Forum Moderator
Posts: 138
Joined: 2003-01-07 09:14
Location: SE
Contact:

Post by aDe » 2003-04-30 07:51

TasMan wrote:Errr are you sure 'bout that aDe?
Well.. yes. I did research on this myself, tried making a program a long time ago to register my nmdc hub 1.0.23 which does not have those calculations, thus failing to register.
TasMan wrote:Because with VB winsocks, you'd have to do some work to get the outgoing port (it always reads 0 unless you set it).
Are you sure? I can't check right now, but I think, once the connection is established, if you read the .LocalPort property it should give you the correct number.

Oh btw, I never managed to register with my program, I gave it up much too soon, because it was a pain to wait 14 minutes between each attempt to avoid getting 'banned' by the register-server, and then having to use the same method for a couple of hours, and then finally getting a confirmation, on the list.

TasMan
Posts: 196
Joined: 2003-01-03 08:31
Location: Canada
Contact:

Post by TasMan » 2003-04-30 12:28

Hmmmmm I suppose I'll have to check it out. This weekend I suppose. Maybe I'm wrong, but I was sure I always got zero.....maybe not. It was a long time since I had to do anything in that area.
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....

TasMan
Posts: 196
Joined: 2003-01-03 08:31
Location: Canada
Contact:

Post by TasMan » 2003-04-30 14:44

Hmmmmm I just noticed you can. Strange how I used to have problems.....it always gave me zero - must have been the timing I suppose.

I've changed this in my personal test hub.....assuming I stay on the NMDCH list, I'll assume aDe was right (I was on before but I can verify it right now.....damn random list.....).

But that still doesn't explain how I was on the NMDCH list. I've never registered a hub on my test hub address. With others yes, but not this......Maybe Hess is using a new registration server (one which does not care about the key) ? He does after all have a new Mac client/hub....Or it could have been pure chance that the n value ended up being the right one =).

In any event, it will be settled in a few days =).
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....

aDe
Forum Moderator
Posts: 138
Joined: 2003-01-07 09:14
Location: SE
Contact:

Post by aDe » 2003-04-30 19:17

TasMan wrote:Maybe Hess is using a new registration server (one which does not care about the key) ? He does after all have a new Mac client/hub....
Interesting.. anyone care to do some testing with the mac hub?

Sid
Posts: 56
Joined: 2003-01-07 18:13
Contact:

Feedback

Post by Sid » 2003-04-30 20:17

Thank you for the feedback, it is very helpful when you create a document this large. I have made changes and may wait a little while for more changes before updateing this document on the site.

If their are 3rd party commands in use like the $BzList dc++ command please let me know because i would like to add a section for those.

Also i have a questions about he hub registration, how does hub registration software check to see what the random wsk port of the incomming connection is? VB wsk explanation is fine.

Thanks again.
Sid

[email protected]
http://www.1stleg.com
[url=dcHub://Greed.1stleg.com]dcHub://Greed.1stleg.com[/url]

Nev
Programmer
Posts: 40
Joined: 2003-01-03 13:29

Post by Nev » 2003-05-01 06:52

NOTE: some hub implementations do not consider a client to be in a logged in state before it has sent a $MyINFO. this is the correct behaviour, and the NMDC hub is flawed in this respect.
Loved this section. The protocol is obviosuly very forgiving when it comes to the order of things. Hence ValdidateDenide, GetPass, BadPass and LogedIn can be sent from the hub after MyINFO have been sent from the client. Neither nmdc nor dc++ have any problems with that. Maybe you should make a note of that.
[url=dchub://ancient.myftp.org]ancient.myftp.org - [BBB][Sunet][Tele2] ONLY! @ 20GB (ISP/IP/Share Scripted)[/url]

andlju
Posts: 27
Joined: 2003-02-28 12:58
Location: Stockholm, Sweden
Contact:

Post by andlju » 2003-05-01 09:56

First of all, thank you for the doc, it's great!

A few comments though (all in Client2Client):

There is no need to re-$Send after 40906 bytes.

I don't really like the fixation with what goes in what packet. E.g.
The $Lock is sent immediately after the $MyNick command within the same packet
...
After the $Direction command we must send the $Key command (still with in the $Direction packet) in response to the other clients lock
Sure, this is the way it is done in NMDC, but it isn't mandatory in any way. The important thing is (and should be) the order in which the commands are sent, not what TCP packet they are sent in. But please, correct me if I'm wrong here!

The part with the $Canceled-command is missing some information.
The downloader is the only one who can initiate a Cancel, by sending exactly: "$Cancel". NOTE: Without the ending | char!
When the cancellation is recieved, the uploader responds by ending the file transmission and sending "$Canceled" - no ending | here either.

Code: Select all

D>U: $Send| 
U>D: file stream [D saves to disk and doesn't care about any "commands"] 
D>U: $Cancel [D stops saving to disk and starts to check for $Canceled commands] 
U>D: maybe a few more bytes of file stream [ignored by D] 
U>D: $Canceled

TasMan
Posts: 196
Joined: 2003-01-03 08:31
Location: Canada
Contact:

Post by TasMan » 2003-05-02 13:48

Alright I figured out what's with the NMDCH registration server lock to key.....I set vandel405.dynip.com to 127.0.0.1 in my hosts file and generated random locks and logged the lock/key/port.

As it turns out, you are right aDe. It is the local port used to connect to the registration server.

However I noticed something else, which is a bug in my Lock to Key function.

At first I did this :

Code: Select all

  h = InStrB(1, Lck, " ")
  If h Then Lck = LeftB$(Lck, h - 1)
....I assumed that the lock stopped after the first space. But NMDCH actually does it when it finds the first " Pk="

Code: Select all

  h = InStrB(1, Lck, " Pk=")
  If h Then Lck = LeftB$(Lck, h - 1)
And now I generated the exact same keys as NMDCH. Alright!

Thanks for the help aDe =)


And to help you out Sid....with the client-client and client-hub, to the first character equals this (assume h is the first character) :

Code: Select all

h = aByte(0) Xor aByte(ub) Xor aByte(ub - 1) Xor 5
"ub" is the last character byte value, as "ub - 1" is the second last. It Xors 5 for this.

However with the registration server it does this :

Code: Select all

h = aByte(0) Xor aByte(ub) Xor aByte(ub - 1) Xor ((wskRegister.LocalPort \ 256) + (wskRegister.LocalPort And 255)) And 255)
Assume wskRegister to be a winsock control. That is why the first character seems to be determined "randomly"....but no - just different =)
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....

TasMan
Posts: 196
Joined: 2003-01-03 08:31
Location: Canada
Contact:

Post by TasMan » 2003-05-02 14:11

Btw you should mention in your documention that default port for registration servers (2501) and how often the NMDCH registers (to prevent getting banned from the server - the NM list anyways).

Does anybody know how long you stay banned for? Hours, days or permanently?
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....

SBSoftEA
Posts: 20
Joined: 2003-01-03 12:29

Post by SBSoftEA » 2003-05-03 16:43

i also use the local port and my code worked, even before those Mac clients came out
key = CreateKey(&(d.SubString(8,d.Length())),_RegisterTCP->Socket->Binding->Port + (_RegisterTCP->Socket->Binding->Port >> 8));

the functions:

int __fastcall TRegister::ns(int *value)
{
return (((*value << 4) & 240) | ((*value >> 4) & 15));
}

AnsiString __fastcall TRegister::CreateKey(AnsiString *Lock,byte xorwith)
{
AnsiString key,key2,slock;
int i;
int temp;
slock = Lock->SubString(1,Lock->Pos("Pk=") - 2);
key.SetLength(slock.Length());
temp = slock[1] ^ slock[slock.Length()] ^ slock[slock.Length() -1] ^ xorwith;
key[1] = ns(&temp);
for (i = 2; i <= slock.Length(); i++)
{
temp = slock ^ slock[i-1];
key = ns(&temp);
}
for (i = 1; i <= key.Length(); i++)
{
switch(key.operator [](i) )
{
case 0:
key2 = key2 + "/%DCN000%/";
break;
case 5:
key2 = key2 + "/%DCN005%/";
break;
case 36:
key2 = key2 + "/%DCN036%/";
break;
case 96:
key2 = key2 + "/%DCN096%/";
break;
case 124:
key2 = key2 + "/%DCN124%/";
break;
case 126:
key2 = key2 + "/%DCN126%/";
break;
default:
key2 = key2 + key.operator [] (i);
break;
}
}
return key2;

}
SBSoftEA Test Hub ---> seabass.no-ip.org:413
Not online 24/7 come by to help us test =)

Locked