ADC
Moderator: Moderators
-
- The Creator Himself
- Posts: 296
- Joined: 2003-01-02 17:15
ADC
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
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
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? =)
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.....
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.
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.
-
- The Creator Himself
- Posts: 296
- Joined: 2003-01-02 17:15
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...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?
-
- The Creator Himself
- Posts: 296
- Joined: 2003-01-02 17:15
why bother? large metadata can be downloaded later...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).
actually, adc only specifies the uncompressed 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.
it can be put in type if you really want to use the same command...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...).
nah, that'll be an extension...BTW, I didn't find any info about hashes. Shouldn't it be added in the BASIC proto?
This should be put in the hub list registration process...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).
knowing the rules, having the hub web-links could come handy in the clients too...This should be put in the hub list registration process...
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.
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 .
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 .
-
- The Creator Himself
- Posts: 296
- Joined: 2003-01-02 17:15
-
- The Creator Himself
- Posts: 296
- Joined: 2003-01-02 17:15
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
The latest version can for now be found at http://dcplusplus.sf.net/ADC.html
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
-
- Posts: 506
- Joined: 2003-01-03 07:33
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
-
- Forum Moderator
- Posts: 366
- Joined: 2004-03-06 02:46
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)?
* 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)?
-
- Posts: 506
- Joined: 2003-01-03 07:33
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
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.
I have a short comment, referring to 2.1
adc:hub://x.x.x.x:port/
adc:hub-ssl://x.x.x.x:port/
just a thought
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[...]) 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 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.
adc:hub://x.x.x.x:port/
adc:hub-ssl://x.x.x.x:port/
just a thought
How can you liberate people by killing them?
-
- Forum Moderator
- Posts: 366
- Joined: 2004-03-06 02:46
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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.)
(PseudonympH read about them a forum post, most likely one of mine.)