ADC 0.8

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 0.8

Post by arnetheduck » 2004-12-03 19:23

Since the latest dc++ contains a few adc updates, I thought it was about time to revise the protocol ducument as well, so now you can download a new revision at http://dcplusplus.sf.net/ADC.html (or /ADC-0.[5,6,7,8].html for the different versions)

This is a good time to comment if you're interested as the hopefully is the second last revision that will be made...

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

Post by PseudonympH » 2004-12-03 22:27

I'm on the fence about the mandatory hashing. While it is of course a good thing to have, it does raise the barrier of entry for people making new clients.

Also, it could use a bit of proofreading. For example, in the connection examples, "BASE" is sent in SUP instead of "+BASE".

The protocol is, of course, very nice and elegant, especially compared to what we're using now. :) Have you given any thought to having it be an official RFC?

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

Post by arnetheduck » 2004-12-04 04:37

indeed, it does raise the barrier, but that wasn't my main consideration - it's not that hard to provide tth's and afaik many of the current clients do it already so...

The bigger issue is that we lock onto tiger tree's and it will be difficult to switch to another hash once tth's become extinct (hopefully it'll be a while), for example when a weakness is found...

Nevertheless, after some discussion it was decided that this is the best way to go - it keeps broken files out and we avoid a lot of issues pertaining to file names - all downloads are now handled by tth, even the requests for a particular file (meaning that even if a user moves a file within his/her share, it's still available to the downloading client). The only time I can imagine a filename would be sensible to use would be the day we stumble upon a hash collision - and that day we're in deep trouble anyway ...

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

Post by CioDu » 2004-12-04 12:25

when thinking of credit-based queue management, slot-granting, favorite users and so on, I see that the most natural implementation of all these in the ADC protocol is through the CID, which is supposed to identify uniquely a user - but what prevents a malicious user to steal a CID of another user? suppose user Pippo is a big uploader and Paperino is a malicious user, what prevents Paperino from using Pippo's CID when Pippo is offline so he gets all the benefits of the other clients thinking that he's Pippo? the draft says "It is invalid for two clients with the same CID to connect to the same hub, and hubs must enforce this", so when Pippo tries to login back to the hub where Paperino is in with Pippo's CID, Pippo gets a error code 24 and has to change his CID, losing all his credits and being nobody for all the fellas that put him in their favorive user list.

now I thought, what if the CID is a public key and the client, when logging in a hub, is asked to sign a random string or the handshake or whatever, so it is not possible to steal other people's CIDs? this would make possible building a strong, malicious-users-proof credit system, together with unique client identification. the bad part of this being extra work in terms of coding and probably cpu usage for the hub during the handshake...

not to mention that the same public key could be used by any extension that requires cryptography, and I saw that there was the idea of doing a extension like that in a old thread: http://dcplusplus.sourceforge.net/forum ... c.php?t=35
How can you liberate people by killing them?

YaRi
Posts: 18
Joined: 2003-08-19 10:52

Post by YaRi » 2004-12-12 07:07

Credits and userhashes? Sounds like eMule. :) They have struggled with the same probems in the past so why not learn from them. Here's how they keep the userhashes safe :) http://www.emule-project.net/home/perl/ ... pic_id=135

[NL]Pur
Programmer
Posts: 66
Joined: 2004-07-21 14:32

Post by [NL]Pur » 2004-12-18 10:09

Didn't want to start a new thread about this because it rather small thing.
Hopefully this thread is still being read :)

Is the HU field of INF automatically an hidden one? or should the hub send
both HU with HI too not appear on the list?

and i got an comment on the SCH
SCH Types: P, U, D, (B), (A)

Note that hubs normally only relay searches to passive clients (type P) and clients send searches to active clients by themselves using type U, which should prove a massive bandwidth saver for the hubs. Should ISP’s dislike this, a switch to type B searching is easily done.


I assume the (B) (A) are noted this way because they are unlikely to be used. But i disagree with that.

I think only ASCH whould be sended by passive clients , since they only can download of active clients so the SCH should only be broadcasted to the Active clients.

Active clients whould use USCH client<>client way, but that was already noted.

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

Post by arnetheduck » 2004-12-18 12:16

hum, hi as well probably...seems the logical thing...I dont' think dc++ acutally implements it yet in any case...

[NL]Pur
Programmer
Posts: 66
Joined: 2004-07-21 14:32

Post by [NL]Pur » 2004-12-18 12:55

which part ? :?

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

Post by PseudonympH » 2004-12-18 17:42

Actually, it seems to be like ASCH should never be used, as the passive clients could simply use USCH and the other clients should be smart enough to send the results back through the hub.

Locked