Direct Connect: Just These Guys, Ya Know?

ADC’s client-client handshake

I previously wrote about NMDC’s client-client handshake sequence, and today I thought I’d talk about ADC’s handshake sequence.

As with the previous post, there’s going to be a client and a server that speaks, where the ‘client’ is the one that want to download and ‘server’ that one that’s going to upload.

For starters, the required commands are “SUP”, “INF”, “GET” and “SND”. The INF is going to contain the users CID, but I’ll use the same CID for both for simplicitly sake. [The both CIDs will still be the same size…]

(Note that the ‘\n’ is one character.)

Server
CSUP ADBASE\n

Client
CSUP ADBASE\nCINF IDWTFUTQBI4NT6MKTRT2EHSMGZM5H2BVM5IZD65FA\n

Server
CINF IDWTFUTQBI4NT6MKTRT2EHSMGZM5H2BVM5IZD65FA TO123456789\n

Client
CGET file TTH/PPUROLR2WSYTGPLCM3KV4V6LJC36SCTFQJFDJKA 0 -1\n

Server
CSND file TTH/PPUROLR2WSYTGPLCM3KV4V6LJC36SCTFQJFDJKA 0 12345\n

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 sent 133 characters, or bytes. The client has sent 120 characters, or bytes.

This is pretty much what a normal client to client handshake sequence looks like. Note that the token (after the TO) is completely arbitrary. Also, the INF may contain more information; This is just what is required. I don’t see a point at the moment to send more stuff, but oh well…

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

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!”