DCExt..

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
aDe
Forum Moderator
Posts: 138
Joined: 2003-01-07 09:14
Location: SE
Contact:

DCExt..

Post by aDe » 2003-01-15 13:21

Well.. we have been over this..

Hub softwares and diff. clients are popping up from all over, and we are not satisfied with the protocol - extensions are being made..
We need to get some order before this turns into chaos :)

Here is my proposal... please let me know what you think..!
http://dcpp.no-ip.com/dcext

Gumboot
Posts: 22
Joined: 2003-01-15 20:08
Location: New Zealand

Post by Gumboot » 2003-01-15 23:46

Excellent! This is just what we need! :)

One thing that occurs to me though is how do the clients know that this extension is available? Perhaps you should include the QuickList spec as part of your document (I assume Nev won't mind): http://forum.dcstats.net/showthread.php?s=&threadid=802

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

Post by aDe » 2003-01-16 03:30

Quicklist isn't completed yet.. I think, but I'll ask Nev about it later on

The clients / hubs do not yet have a way to send the list of what it supports, but, Nev is proposing a $Supports like in the client<->client which would be fine.

I have also been considering splitting the DCExt up into two pieces - one that can be scripted to work with original nmdchub and one that can not.
It is still that common, i'm afraid..

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-01-16 15:33

we have some other non-urgent extensions too that have already been implemented in some hubs / clients:

$UniSearch
implemented in the dctc hub: http://www.ac2i.tzo.com/dctc/ChangeLog.dchub
version 0.0.9 wrote:To ease some script function writing, the hub has an extension to the set of DC commands. This function is $UniSearch. Its goal is to provide the capability to send a search query to one given user. When someone/something sends a $UniSearch command, dchub internally converts it into a standard $Search command (thus all clients will understand it) and sends the command only to the select user.
quoting $ and |
oDC++ (http://gempond.com/odc/) uses [§] and [¦]
some other client uses \e(some_char) (\e=ESC)
and the $Key uses /%DCN036%/ and /%DCN124%/
..all quite a mess
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

ender
Posts: 224
Joined: 2003-01-03 17:47

Post by ender » 2003-01-16 15:49

IMO, %DCN encoding should be standarised for escaping $ (only in private messages, it displays fine in the main chat) and | - %DCN is already used in DC, even though it bloats everything...

As for UniSearch, is there any detailed description available on how to use it?

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

Post by aDe » 2003-01-16 16:15

I agree with /%DCNxxx%/ escaping..

As for UniSearch- this is not a bad idea but perhaps a more sophisticated search command should be figured out, that supports more things, all in one command..

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-01-16 17:38

protocol_extension (dchub-0.2.5.tar.gz)

Code: Select all

dchub comes with its own extension to DC protocol. This file contains the list
of all them, what they do and how to use them.

$UniSearch              : this function works like $Search except it provides
                          the capability to send a search query to one specified
                          user.
                          syntax: $UniSearch destination_nick XXXXXXXXX
                                  where XXXXXXX is the same parameter as $Search
                                  function (return address, search type and
                                  pattern).

$ForceSend string	      : send the following string to all users (you must have
                          BOT privilege to use it).

$ForceSendTo username string
                        : send the following string to the given users (you must
                          have BOT privilege to use it).
p2p_capabilities (dctc-0.84.0.tar.gz)

Code: Select all

On the link established between two clients, a new command have been added.
During the initial handshake, after the $Direction and before the $Key, each
client can send its capabilities to the remote one using a new commmand named
$Capabilities.

Usage:
$Capabilities CAP1[$CAP2....]|

Each string CAP* is a capability supported by the client sending the
$Capabilities string.

List of defined capabilities:

* SEND_WITH_SIZE

  When a download is initiated, usually, the client sends a "$Send|" command.
  If the remote client has the SEND_WITH_SIZE capability, it also supports the
  command "$Send xxx|" where xxx is the number of bytes the local client wants.
  This capabilities has been added for future usage in segmented download.
search_by_content (dctc-0.84.0.tar.gz)

Code: Select all

DC protocol extension.
----------------------

* Search by content
  -----------------

To be more efficient while searching, the search by content has been added.

2 DC commands have been modified:
$Search (to start a search)
and
$SR (the search result)

$Search change:
===============

a normal $Search command is like this:
$Search sender a?b?c?d?e
where sender is "Hub:nick" for passive search or "ip:port" for active search.
a is F if size doesn't matter, else T
b is F if size is "at least", else T (at most)
c is the size in byte
d is data type: 1=any,2=audio,3=compressed,4=document,5=exe,6=picture,7=videos,
                8=folder
and eeee is the pattern to find

To remain compatible with DC, it is not possible to add new field. I have
modified the 'a' field (the wanted size)

now, the command is like this:
$Search sender a.md?b?c?d?e

where md is a MD5SUM (see below).

$SR change:
===============

a normal $SR command is like this:
$SR sender a\5b c\5d (e)
(\5 is the character '\005')
where sender is the nickname of the person sending this reply.
a is the found filename.
b is the filesize
c is the slot ratio (freeslot/total slot)
d is the hubname
e is the hub address.

To remain compatible with DC, it is not possible to add new field. I have
modified the 'b' field (the filesize)

now, the command is like this:
$SR sender a\5b.md c\5d (e)

where md is a MD5SUM (see below).

Note on compatibility: For a strange reason, on the hub, there is no warning when 
the modified $Search is sent but there is a warning when the $SR is sent (only
in passive mode because active mode doesn't use the hub). It is only a warning
and the extension works fine.

--------------------------------------------------------------------------------
MD5SUM computation.

the MD5SUM is computed on the first 4KBytes of the file using the standard
MD5 algorithm (see md.c file of DCTC). The algorithm produces a non printable
16 bytes string. To be able to send it using the DC protocol, the string is
rewritten. The 16 bytes non printable string is converted into a 48 bytes
printable string using the following very simple rule. Each byte of MD5sum is
written in a 3 decimal characters string. Ex:
254 is written "254", 136 becomes "136", 28 becomes "028". 

This is not the most efficient way of storing the value but using this, the
filesize (c) and the encoded MD5sum (md) looks like a float (c.md). Ex:
35345.111222333444555666777888999000111222333444555666
35345 is the filesize and the part after the dot is the md5sum (bad example,
it is not possible to encode 333 ... 999 into a byte :) ). Thus, even if the
program expect a number, there will be no error.
sorry about the size of this..
("dctc hub" was not correct, dctc is the client, dchub the hub)
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

ender
Posts: 224
Joined: 2003-01-03 17:47

Post by ender » 2003-01-16 17:50

Sedulus wrote:$Capabilities CAP1[$CAP2....]|
Hmm, DC++ (and compatible clients) use $Supports, where features are separated by spaces. Currently BZList is supported, and ZLib file compression is planned.
Sedulus wrote:$Search sender a.md?b?c?d?e
There was talk about hashes already, IIRC it was suggested that the size would be negative, and the hash would be sent as the searchstring. IMO, that's a better way of doing it - the first two fields should only be 1 byte long...

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-01-16 18:00

ender wrote:Hmm, DC++ (and compatible clients) use $Supports, where features are separated by spaces. Currently BZList is supported, and ZLib file compression is planned.
true, and DC++ also knows by the Lock who he talks to, instead of just sending crap to some poor innocent client.
But nevertheless it's useful to know what others are doing.
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

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

Post by sandos » 2003-01-16 19:11

I really dont like the idea of hashing only the first 4k bytes though.

ender
Posts: 224
Joined: 2003-01-03 17:47

Post by ender » 2003-01-17 04:13

Yes, hashing only the first 4k of the file doesn't solve anything - most corrupted files are missing something in the end (or in the middle) - if they were corrupted in the first 4k, they probably wouldn't work at all...

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

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

Great work aDe!
[url=dchub://ancient.myftp.org]ancient.myftp.org - [BBB][Sunet][Tele2] ONLY! @ 20GB (ISP/IP/Share Scripted)[/url]

Locked