NMDC’s client-client handshake

As a continuation on the ADC vs NMDC posts, this post will discuss the client and client handshake under NMDC, and how DC++ has changed some parts of it.

First off, the following is taken from the old wiki, where the clients are using “RevConnect 0.668” (which I assume means that it’s based off of DC++’s 0.668 client part). Secondly, DC++ have deprecated the $Get and $Send commands in favor of $ADCGET and $ADCSND, which are ports from ADC.

There are two clients in this conversation. To simplify things, I’ll be referencing the clients as “client” and “server”, as ADC is using that, and I feel that that is more intuitive. I’ll be breaking things up in parts. The first part I’ll be listing what commands are needed to perform a proper C-C connection. The second part is “general” and apply to both ($Get/$Send and $ADCGET/$ADCSND), and I won’t repeat myself. The thid part will be a showdown with $Get and $Send versus $ADCGET and $ADCSND.

Okay. Let us give it a go. The commands that are required are;
“$Mynick user_nick”, “$Lock with_some_massive_block Pk=some_more_stuff”, “$Supports a_bunch_of_things”, “$Key some_nonsensical_thing”, “$Get filename_and_path$1”, “$Direction Download[/Upload] random_number”, “$Send” and “$FileLength the_file_length”. $ADCGET/SND comes in three flavors; (1) “$ADCGET file filelist 0 -1”, (2) “$ADCGET file TTH/root_tth_of_file 0 -1” and (3) “$ADCGET tthl TTH/root_tth_of_file 0 -1”, where the first gets the file list, the seocnd a file and the third the hash tree. Respectively; (1) “$ADCSND file TTH/root_tth_of_file 0 file_length”, (2) “$ADCSND file filelist 0 file_length” and (3) “$ADCSND tthl TTH/root_tth_of_file 0 amount_of_leaves”. (Note that the bunch of numbers you’re seeing are starting positions and stuff like that. Also, the “filelist” is shortened, because I didn’t feel like writing more here.) [Disclaimer; the $Key in the example will look like gibberish; I have no idea if it is. It’s what the wiki page says.]

Okay, now we know what we’re dealing with. Let us go through what we need to say to each other. The client is the one that want to download and the server is the one that’s going to upload.
Server
$MyNick server|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.668ABCABC|

Client
$MyNick client|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.668ABCABC|$Supports MiniSlots XmlBZList ADCGet TTHL TTHF GetZBlock ZLIG |$Direction Download 17762|$Key ……..A …..0.0. 0. 0. 0. 0. 0.|

Server
$Supports MiniSlots XmlBZList ADCGet TTHL TTHF GetZBlock ZLIG |$Direction Upload 6494|$Key ……..A …..0.0. 0. 0. 0. 0. 0.|

At which point both parties know that the client is the one that’s allowed to download since its $Direction random number is higher. At this point, the server has sent 208 characters, or bytes. The client has sent 210 characters, or bytes.

Moving on to the $Get and $Send part;
Client
$Get folder\filename$1|

Server
$FileLength 12345|

Client
$Send|

At which point the server starts streaming the file to the client. (The client will of course stop listening for the file when 12345 bytes have been received, and disconnect or send another $Get.)

The server has now sent 226 characters, or bytes. The client has now sent 239 characters, or bytes.

And now $ADCGET and $ADCSND;
Client
$ADCGET file TTH/PPUROLR2WSYTGPLCM3KV4V6LJC36SCTFQJFDJKA 0 -1|

Server
$ADCSND file TTH/PPUROLR2WSYTGPLCM3KV4V6LJC36SCTFQJFDJKA 0 12345|

At which point the server starts streaming the file to the client. (The client will of course stop listening for the file when 12345 bytes have been received, and disconnect or send another $ADCGET. )

The server has now send 273 characters, or bytes. The client has now sent 272 characters, or bytes.

Worth noting is that $ADCGET/SND will always have that 43 byte long TTH thing (except for file lists). On the other side, you might end up with a long path to the file you want, and $Get will get irritating. Also, $Get does not handle TTH leaves, so you’ll never be able to verify the data you’re downloading.

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

4 Responses to NMDC’s client-client handshake

  1. racmail2001 says:

    hi, i want to make a php bot and be able to download the filelist’s

    what i do not understand is

    if the client it’s sending this info to the hub

    Client
    $MyNick client|$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.668ABCABC|$Supports MiniSlots XmlBZList ADCGet TTHL TTHF GetZBlock ZLIG |$Direction Download 17762|$Key ……..A …..0.0. 0. 0. 0. 0. 0.|

    and all this i’s just info about the sender … how the hub’s knows to witch user you want to connect and download the list from?

    i have also a different theory

    my script want’s to get the filelist from you so
    my script it’s sending all that info to you and not to the hub

    but from where i can find your ip and your port to be able to send this info ?

    thanks in advance for your reply

  2. Fredrik Ullner says:

    You’re confused. The hub is not involved at all in the C-C handshake. That has already been communicated via CTM or RCM.

    You might want to look at http://www.teamfair.info/DC-Protocol.htm for a “complete” spec.

  3. racmail2001 says:

    wat i do not understand is from were i can find out the user ip and port address to be able to send that comands

  4. Fredrik Ullner says:

    Read $ConnectToMe and and $RevConnectToMe. Unless you don’t understand the _clear text_, it’s *your* IP and port you specify in CTM. (Obviously, in the RCM case, you will get the other user’s IP and port.)

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: