ADC

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
arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

ADC

Post by arnetheduck » 2004-01-17 15:28

ADC is a replacement for the current protocol, made mainly to make it easier to add new features to it without breaking old clients...a secondary objective is to give the dc world a single specification to follow, not whatevers been guessed, reverse engineered and sniffed out from nmdc...
This, in any case, is my proposition and will most probably make it into dc++/dch++ in some hopefully not too distant future...comments are welcome...

http://dcplusplus.sf.net/ADC.htm

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

Post by TasMan » 2004-01-18 06:21

I've just got one question (and yes btw it's looking quite nice or rather it did when I skimmed through it =p); Would DC(H)++ support the old protocol in the event that the hub / client connecting does not support the new one?

I would prefer it not to myself. It'd be bloody annoying to have to convert the new protocol to the old protocol and vice versa for the older outdated clients =p.

But alas, that would make a lot of client side bot devs angry; but who cares? =)
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....

seeSharp
Posts: 24
Joined: 2003-04-19 10:03

Post by seeSharp » 2004-01-22 05:44

This one looks good. (As everything here :)) My 2cents:

Sometime later, but before ADC spec 1.0 you should add an exact specification for files.xml's structure (or client will name filenames like filename, Fname, NAME, johndoe, etc...:).
There could be support for two versions of the filelist:
files.basic.xml -> could contain filepath/filename/fileext/filesize/TTH
files.full.xml -> same as above + it could include some metadata (dependant on file type).

Interactive filelist downloads, when users are looking for some files could get the full version, while automatic filelist downloads (fl download on alternate search hit) could get the basic version.

And one other thing to filelists: IMHO two compression methods should be enough (uncompressed/bz2), I don't see what gzip could add to this.

There is nothing in for crc checked and/or compressed file transfer. That could be included in the draft, maybe as a SUP thing, just put it in.

GET could get :) one more parameter:
"GET <type> <compression> <identifier> <start-pos> <bytes>"
where <compression> should be "NONE" for BASIC proto communication, and could be anything, that's in the other party's SUP (like "CRC", "GZIP", "BZ2", etc...).

BTW, I didn't find any info about hashes. Shouldn't it be added in the BASIC proto?

To 3.3.3 INF:
You didn't specify what hubs can send out about themselves, but I think it should be different from the Client INF. Hublist-BOT's could also take advantage of it. Some proposals are:
rules: minshare, maxshare, minslots, maxslots, slotsperhub, etc..
info: hub-homepage-link, hub-forum-link. (these then could be added to the HUBmenu by the clients).

That's for today.

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2004-01-22 05:57

TasMan wrote:I've just got one question (and yes btw it's looking quite nice or rather it did when I skimmed through it =p); Would DC(H)++ support the old protocol in the event that the hub / client connecting does not support the new one?
Well, technically it's possible...but the client always knows which protocol it's connecting with (adc:// for valid adc hub addies), so the problem lies mainly at the hub that would have to translate adc to nmdc and vice versa...

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2004-01-22 06:04

seeSharp wrote:Sometime later, but before ADC spec 1.0 you should add an exact specification for files.xml's structure (or client will name filenames like filename, Fname, NAME, johndoe, etc...:).
There could be support for two versions of the filelist:
files.basic.xml -> could contain filepath/filename/fileext/filesize/TTH
files.full.xml -> same as above + it could include some metadata (dependant on file type).
why bother? large metadata can be downloaded later...
And one other thing to filelists: IMHO two compression methods should be enough (uncompressed/bz2), I don't see what gzip could add to this.
actually, adc only specifies the uncompressed version...
GET could get :) one more parameter:
"GET <type> <compression> <identifier> <start-pos> <bytes>"
where <compression> should be "NONE" for BASIC proto communication, and could be anything, that's in the other party's SUP (like "CRC", "GZIP", "BZ2", etc...).
it can be put in type if you really want to use the same command...
BTW, I didn't find any info about hashes. Shouldn't it be added in the BASIC proto?
nah, that'll be an extension...
To 3.3.3 INF:
You didn't specify what hubs can send out about themselves, but I think it should be different from the Client INF. Hublist-BOT's could also take advantage of it. Some proposals are:
rules: minshare, maxshare, minslots, maxslots, slotsperhub, etc..
info: hub-homepage-link, hub-forum-link. (these then could be added to the HUBmenu by the clients).
This should be put in the hub list registration process...

seeSharp
Posts: 24
Joined: 2003-04-19 10:03

Post by seeSharp » 2004-01-23 06:02

This should be put in the hub list registration process...
knowing the rules, having the hub web-links could come handy in the clients too... :)

There is a Hungarian DC Hub and Client (X-Hub, X-DC) those support this, when user together. If you open up 2 slots, connect to one hub, and then later you connect to an other one, you don't have to bother with the settings, you get a message window, asking you wether you want to raise the number of upload slots, or disconnect from the hub.

We've really encountered a lot of users, who didn't understand, how to adjust the number of upload slots, or why they have to do it.

FarCry
Programmer
Posts: 34
Joined: 2003-05-01 10:49

Post by FarCry » 2004-01-23 23:00

I think the idea is to keep the BASE requirements as simple as possible to allow for fast development of compliant implementations. Everything not necessary for basic dc-style file sharing should be left up to future extensions - this option is one of the key features after all.

With that in mind I would rather remove some field types from the client INF, but I understand that arne's protocol can't be blamed for adopting the standards set by his client :wink: .

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2004-04-01 11:48

ADC.htm has been updated for the interested...

Also, I just started working on the client part, so in a version or two dc++ will run adc, and hopefully some hubs will follow...

Todi
Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16
Contact:

Post by Todi » 2004-04-01 15:13

Are there actually any hubs capable of ADC right now? Since i havn't heard of any, i'm gonna assume there is not. Although i know there is atleast one (ANY) planned.. i guess once a client is out, development will speed up.

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2004-06-13 06:10

http://dcplusplus.sf.net/ADC-0.6.html is up for the interested...-0.5 is also kept for reference.

The latest version can for now be found at http://dcplusplus.sf.net/ADC.html

TheParanoidOne
Forum Moderator
Posts: 1420
Joined: 2003-04-22 14:37

Post by TheParanoidOne » 2004-06-13 06:44

Is there a list of revisions between the versions kept anywhere?
The world is coming to an end. Please log off.

DC++ Guide | Words

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2004-06-13 07:22

Some changes are related to the INF, in the hub-client handshake and new flags was also added and some other changes. ;))
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-06-13 09:07

TheParanoidOne wrote:Is there a list of revisions between the versions kept anywhere?
I have older copies of ADC.htm elsewhere if you want to diff them.

TheParanoidOne
Forum Moderator
Posts: 1420
Joined: 2003-04-22 14:37

Post by TheParanoidOne » 2004-06-13 12:07

Please. :)
The world is coming to an end. Please log off.

DC++ Guide | Words

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-06-14 18:39

Ok, mail sent. I don't feel like putting them up for download... :lol:

TheParanoidOne
Forum Moderator
Posts: 1420
Joined: 2003-04-22 14:37

Post by TheParanoidOne » 2004-06-15 13:30

Mail received. Cheers. :)
The world is coming to an end. Please log off.

DC++ Guide | Words

PseudonympH
Forum Moderator
Posts: 366
Joined: 2004-03-06 02:46

Post by PseudonympH » 2004-06-16 21:43

Something just occured to me: how are we going to do emotes? i.e.
* PseudonympH does something.

Currently, they're just sent as raw text with the pipe at the end, but that obviously can't be done with ADC. So how can we do this? IMSG commands are always displayed as raw? Display messages coming from the hub's CID as raw text instead of sticking <nick> in front of it? Or add a flag at the end of the message to mean "display as raw text" (possibly enforcing it to come from hub-CID and be type I)?

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2004-06-17 04:30

I have always disliked forced-up-on layout of chat. So i will be against it atleast.. ;))

Type "I" will hopefully not happens since it would be reserved for MOTD and other status-messages coming from the hub. If you want a more chat-friendly protocol then adding subchats (like IRC channels) is more satisfying. So far this has not got into the BASE and will probably never do so.

my-thought-on-the-subject-ly'ers
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

CioDu
Posts: 21
Joined: 2003-11-02 19:46
Location: Milan, Italy
Contact:

Post by CioDu » 2004-06-18 11:47

I have a short comment, referring to 2.1
ADC Protocol Draft 0.6 wrote:Hub addresses must always be specified in url form, with “adc� as protocol specifier (“adc://x.x.x.x:port/�), or “adcs� (adcs://x.x.x.x:port) for the SSL wrapped mode (optional). DNS names are only allowed in hub lists, hub links etc. Clients may never use DNS names as their IP, to avoid spoofing and resolving problems.
wouldn't it be more extendable tu use a single tag identifier for the whole adc protocol and than tu use keywords to be put after adc:? that would have two advantages (al least imho): only one tag will be used to identify urls that browsers should give to the adc client and new link types (like a e2k-style adc:file[...]:wink:) will be added without hurting old clients (that will not process at all links like adc:<keyword> if they don't know that keyword). So those links would look like:

adc:hub://x.x.x.x:port/
adc:hub-ssl://x.x.x.x:port/

just a thought :roll:
How can you liberate people by killing them?

PseudonympH
Forum Moderator
Posts: 366
Joined: 2004-03-06 02:46

Post by PseudonympH » 2004-06-18 13:53

Links besides hub links are planned to use magnet links. Those kinds of links (ones that specify a filename/size/TTH to be added to the download queue mainly) are not even remotely ADC-specific, so it doesn't make sense to have them as adc links. Plus, it's just like http and https.

CioDu
Posts: 21
Joined: 2003-11-02 19:46
Location: Milan, Italy
Contact:

Post by CioDu » 2004-06-18 13:59

Well, there is no reference to magnet links in the ADC Draft. Where did you read about that?
How can you liberate people by killing them?

Todi
Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16
Contact:

Post by Todi » 2004-06-18 14:17

Magnet links would probably be considered an extension, like hashing, and as such not included in the basic ADC protocol. However, it should be easy to extend the protocol with it if you wanted to.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-06-18 22:24

Magnet links have no place in an ADC Draft. The draft already talks about searching by file hash - the mechanics of adding a file to the client's queue through a hash-search is uninteresting to a P2P protocol description. It is a client feature that requires no support from any other client, aside from the aforementioned search-by-hash

(PseudonympH read about them a forum post, most likely one of mine.)

Locked