http://dcplusplus.sf.net/ADC.html
The ADC Protocol isn't a draft anymore :D
Quote from: Toast on 02 December, 2007, 15:58:01
http://dcplusplus.sf.net/ADC.html
The ADC Protocol isn't a draft anymore :D
What are the advantages over NMDC then? What NMDC issues have been addressed?
Looks like joke, after many years they remove from it everything that can make it better than nmdc ;D
Few reason why is ADC worse than DC protocol:
1 ) No hublist and hublist pinger support. In DC hub can reg and update users/share info on hublist, and pinger can get basic info from hub.
2 ) No standard Operator commands, and no way to add some commands to menu. In DC we have standard kick/redirect/close commands and we can add more menu items with usercommands.
3 ) More badwith usage. In DC is critical hub startup where is very much badwith used for sending userlists, ADC using for userlist 2-2.5x more badwith.
4 ) Allowing share where is not possible to download all files because file is identified in ADC only with hash (here already exist few iso images contains bigger and smaller files where every bigger file have small file with same hash, and only smaller file is possible to download).
If i remember something else i will add it later :P
Quote from: PPK on 02 December, 2007, 17:02:42
2 ) No standard Operator commands, and no way to add some commands to menu. In DC we have standard kick/redirect/close commands and we can add more menu items with usercommands.
BMSG %[mySID] !kick\s%[userNI]\s%[line:Enter_Reason]\nTry it u might be surprised ^^
No i will not be surprised, is normal that hub have chat commands for operators. But that not fixing problem with missing commands in menu and no way for hub to add them :P
Well my usercommands works perfect :P so it must be a local problem for u :P
No is not local problem for me. ADC draft 0.14 have user commands support, and that support was removed to ADC 1.0 ;D
Please somebody answer my questions, thanks.
Well Encryption is one advantage and search made with regex is another feature that i like and kicks with regex that some of the feats for issues with the nmdc protocol check DC++ blog at http://dcpp.wordpress.com/ they have posted their findings there over issues from the nmdc protocol // Regards Toast
Please read ADC 1.0 first. They removed encryption and regex support !
sigh its gonna be an extension
So far the only advantage seems to be extensibility.
Quote from: Toast on 02 December, 2007, 20:35:18
sigh its gonna be an extension
And for this as extension we don't need ADC, we can use it as extension in nmdc too :P
Quote from: bastya_elvtars on 02 December, 2007, 20:40:45
So far the only advantage seems to be extensibility.
It is extensible in same way as nmdc. Both have command (SUP in ADC, Supports in nmdc) where client/hub sending what extensions support.
1) ADC is more secure : passwords are not sent unencrypted like in NMDC
2) global client identification cid -based
3) the multiple hash support ( nmdc has no hash support -> corrupted downloads, and problems like that )
4) dynamic feature modifiers like changing a client type, or the supported features, nick, etc without reconnecting...
5) extensions like adcs... ( secure )
p.s not being arrogant if i was arrogant u would notice ppl tend to notice when im arrogant im only joking around most of the time
but this should straighten up any questions around the adc protocol and its advantages // Regards Toast
Quote from: Toast on 02 December, 2007, 22:21:45
1) ADC is more secure : passwords are not sent unencrypted like in NMDC
Can be added to nmdc as extension, but is not important (else it will be already added).
Quote from: Toast on 02 December, 2007, 22:21:45
2) global client identification cid -based
Can be added to ndmc as extension, but is not needed and for example cid as is in ADC can't be used to ban user because is easy to change it like nick.
Quote from: Toast on 02 December, 2007, 22:21:45
3) the multiple hash support ( nmdc has no hash support -> corrupted downloads, and problems like that )
ADC 1.0 supporting only tiger hashes, same hashes that we use many years in nmdc. And we can use another hashes too, so no improvement with ADC.
Quote from: Toast on 02 December, 2007, 22:21:45
4) dynamic feature modifiers like changing a client type, or the supported features, nick, etc without reconnecting...
Only thing in nmdc what need reconnect is nick, that is small but not important improvement.
Quote from: Toast on 02 December, 2007, 22:21:45
5) extensions like adcs... ( secure )
We use in nmdc extensions for years. No improvement with ADC. And secure connections is only to avoid isp p2p limiting, it will not stop RIAA+MPAA etc to join hub, download your list and send nice email to your isp (police...) ;D
I'm curious if these shortcomings with ADC are so great why are those who are pushing ahead with it A) doing so B) not listening to you C) you not adding your input about what needs to be done. What's needed is some unity, since DC is undoubtedly dying as it stands. I've said that before and people have denied that simply because DC still exists. Well those who say that clearly haven't been in public hubs looking at the trend with user counts and hubs closing in the last 3 years. DC may not die completely but it will end up as some obsolete p2p service like (I've forgotten the name of the thing I used as soon as audiogalaxy closed, the default message when you sent a PM to someone was 'hello banana'!). The people on this forum, and likely the DC developers have lost sight of the most important thing, what the end user wants. If the users want encryption don't say 'oh that's a small feature, it's not that important or it's not worth having', work on getting it done. Maybe what I am saying isn't technically right, however I'm sick of the way things stand since I've been running my hub since May 2004, and I closed it about a week ago. And I just bought it back yesterday but I'm thinking it's really a waste of time. I just think both sides are stubborn, set in their ways, unwilling to compromise, arrogant, the list goes on.
I for one, as a forum admin here, haven't lost sight, rather lost interest because there have been no significant improvements in DC for like... 4-5 years? Segmented downloading, for instance, has been added only a few weeks ago, and the possibility for having it in the client was there for a very long time (= many years).
Quote from: Toast on 02 December, 2007, 22:21:45
1) ADC is more secure : passwords are not sent unencrypted like in NMDC
Uh oh... and what if the password
hash gets sent? If I sniff that, I can write a client that connects and sends the exact same info... whoa! The account gets compromised immediately. Only SSL'd login could be called really secure, this is rather false sense of security.
Agreed, it should have been done many years ago, again by looking at what the end user wanted. You can see more evidence of the point I am making on the DC++ website:
QuoteThe client can be downloaded, precompiled and ready to run. DC++ runs best on Windows NT based operating systems. If you run Windows 95, 98, or ME, your experience may not be the same. If you have experience in C++ programming, the source code for DC++ is also available. Although DC++ is free, the tools for compiling it are not. You will need to purchase Microsoft Visual Studio 2005 in order to compile it. DC++ is distributed in English, but it comes with the ability to download a language file that translates DC++ into their own language. The "language file" link below hosts many such translations. Once the language file is downloaded, DC++ must be configured to use it though Settings → Appearance → Language File.
It's completely inappropriate considering who the average DC++ user is. As I say I know I'm not totally right about everything but I wanted to make those points because I am frustrated. I've run my hub for over three years, and at the end of it it seemed like a total waste of time. I'm not totally knocking the DC developers since they have done infinitely more for the community than I have done, I just think a slightly different change in strategy would have made the world of difference.
Quote from: imb on 02 December, 2007, 23:17:37
I'm curious if these shortcomings with ADC are so great why are those who are pushing ahead with it A) doing so B) not listening to you C) you not adding your input about what needs to be done. What's needed is some unity, since DC is undoubtedly dying as it stands. I've said that before and people have denied that simply because DC still exists. Well those who say that clearly haven't been in public hubs looking at the trend with user counts and hubs closing in the last 3 years. DC may not die completely but it will end up as some obsolete p2p service like (I've forgotten the name of the thing I used as soon as audiogalaxy closed, the default message when you sent a PM to someone was 'hello banana'!). The people on this forum, and likely the DC developers have lost sight of the most important thing, what the end user wants. If the users want encryption don't say 'oh that's a small feature, it's not that important or it's not worth having', work on getting it done. Maybe what I am saying isn't technically right, however I'm sick of the way things stand since I've been running my hub since May 2004, and I closed it about a week ago. And I just bought it back yesterday but I'm thinking it's really a waste of time. I just think both sides are stubborn, set in their ways, unwilling to compromise, arrogant, the list goes on.
well as an end user and a small scripter i would like to see both sides prosper right now im using adc hubsofts and adc clients alot but that doesn't shut the door on nmdc the lua in ptokax is always interesting for trying new and crazy stuff in the end i just wanna see a secure p2p model thats what its all about
Quote from: bastya_elvtars on 02 December, 2007, 23:31:40
Uh oh... and what if the password hash gets sent? If I sniff that, I can write a client that connects and sends the exact same info... whoa! The account gets compromised immediately. Only SSL'd login could be called really secure, this is rather false sense of security.
please read the protocol:
"Password. The password (utf-8 encoded bytes), followed by the random data (binary), passed through the session hash algorithm then converted to base32. When validated, this transitions the server into NORMAL state."
more info: http://en.wikipedia.org/wiki/Salt_(cryptography)
Quote from: PPK on 02 December, 2007, 22:30:47
Can be added to nmdc as extension, but is not important (else it will be already added).Can be added to ndmc as extension, but is not needed and for example cid as is in ADC can't be used to ban user because is easy to change it like nick.ADC 1.0 supporting only tiger hashes, same hashes that we use many years in nmdc. And we can use another hashes too, so no improvement with ADC.Only thing in nmdc what need reconnect is nick, that is small but not important improvement.We use in nmdc extensions for years. No improvement with ADC. And secure connections is only to avoid isp p2p limiting, it will not stop RIAA+MPAA etc to join hub, download your list and send nice email to your isp (police...) ;D
1) No one added encyption to nmdc hubs, and you will not (http://board.ptokax.ath.cx/index.php?topic=7415.0). But there are some hubowners which consider encryption of c-c/c-h connections as useful, maybe they are fools but i am one of them. A reg only hub will be definitly more secure with encryption.
2) with identifing via cid its very difficult to get unallowed access to a reg only hub. in nmdc you only need the nick and pass.
3) no one will add other hashes to nmdc because it is more difficult and annoying than with adc.
4) no one will add other features to nmdc because "its not important".
5) a tls reg only adc hub will probably stop RIAA+MPAA more than a nmdc hub
6) i am curios how the "nmdc's" here want to support multiple shares for multiple hubs via protocol? or this isnt important too? with adc its possible, with nmdc not. open up another client is not a solution ;)
sorry to butt in here ;D i was reading through this topic and i found it interesting. I've never used ADC (that i know of) but judging from everyones attitude towards it for some reason i cant help of thinking about the 'new kid on the block' meaning everyone teaming up against it because its new. I dont believe ADC is here to take over or replace the existing NMDC which we are all familiar with i think it is a perfect alternative. yes ADC has its flaws and so does NMDC. direct connect protocols are like operating systems 'they all suck'. if it was arounf the other way ADC was developed first and NMDC was just developed i bet everyone would have the same attitude towards the NMDC protocol.
i can fully understand why PPK can quickly see the holes in the ADC protocol because he obviously knows the NMDC protocol well but on the other hand there is a threat that if everything did change to ADC then it would also mean a total core change for PtokaX to work with the new ADC protocol 'ouch' ;D after all what use would a NMDC hub be to everyone using ADC clients?
on a personal note i think ADC and NMDC should work on a paralell, meaning you have a ADC network and a NMDC network where ADC does not work with NMDC and NMDC does not work with ADC. less work for the devs, easier for the end user, more choice for the end user. Maybe one day a ADC PtokaX hub and a NMDC hub??? its like trying to make a vehicle run on several different fuels but with a lot more complications (as if there wasnt already complications)
lastly has anyone considdered the problems the public hublists devs have been having concerning the introduction of this new ADC??? ive spoken to several public hublist owners and it seems this new ADC is causinf nothing but headaches and confusion. its a bit like Apple and Microsoft ::) they DONT go together well ;D
i wish all the devs a jolly good luck 8)
Quote from: blastbeat on 03 December, 2007, 13:53:28
1) No one added encyption to nmdc hubs, and you will not (http://board.ptokax.ath.cx/index.php?topic=7415.0). But there are some hubowners which consider encryption of c-c/c-h connections as useful, maybe they are fools but i am one of them. A reg only hub will be definitly more secure with encryption.
Ony reg only hub will be secure, and only when all connection will be encrypted. Not only client->client.
Quote from: blastbeat on 03 December, 2007, 13:53:28
2) with identifing via cid its very difficult to get unallowed access to a reg only hub. in nmdc you only need the nick and pass.
Imho is not problem to sniff cid, but yes it is harder. Imho registering by user cid it making harder for users... user can remember nick but how much users can remember theyr CID ? When they lost cid, then they lost all they regs ::)
Quote from: blastbeat on 03 December, 2007, 13:53:28
3) no one will add other hashes to nmdc because it is more difficult and annoying than with adc.
No, in nmdc is now TTH on all places identified with TTH: prefix. Is easy to replace it with another hash, but it was not needed yet because tiger working good and is not publicly know fast way to generate collisions.
Quote from: blastbeat on 03 December, 2007, 13:53:28
4) no one will add other features to nmdc because "its not important".
When you add something that is good and nobody else support it or supporting it and in newer versions remove it as buggy code then you don't want to waste your energy next time to add something ...
Quote from: blastbeat on 03 December, 2007, 13:53:28
5) a tls reg only adc hub will probably stop RIAA+MPAA more than a nmdc hub
Yes, that will work. But afaik i don't know any private nmdc hub who has problem with RIAA+MPAA ...
Quote from: blastbeat on 03 December, 2007, 13:53:28
6) i am curios how the "nmdc's" here want to support multiple shares for multiple hubs via protocol? or this isnt important too? with adc its possible, with nmdc not. open up another client is not a solution ;)
In ADC it is easyer, but is possible to go hard way and do it in nmdc too. No imo is not important and most users will use it only to have min share on every hub.
Quote from: ruler on 03 December, 2007, 15:10:38
if it was arounf the other way ADC was developed first and NMDC was just developed i bet everyone would have the same attitude towards the NMDC protocol.
Yes exactly, after many years protocol that is similar than older one. It is waste of time to change to something that is almost same.
Quote from: ruler on 03 December, 2007, 15:10:38
Maybe one day a ADC PtokaX
Impossible :P
Quote from: PPK on 03 December, 2007, 18:16:06
Not only client->client.Imho is not problem to sniff cid, but yes it is harder. Imho registering by user cid it making harder for users... user can remember nick but how much users can remember theyr CID ? When they lost cid, then they lost all they regs ::)
one could also say its easier to store one pid somewhere then remember many nicknames and passwords ^^
True, when user have many nicks then it is improvement ;D
http://dcplusplus.svn.sourceforge.net/viewvc/dcplusplus/dcplusplus/trunk/ADC-EXT.txt?view=markup
the extensions if anyone is intressed
Quote from: blastbeat on 03 December, 2007, 13:53:28
6) i am curios how the "nmdc's" here want to support multiple shares for multiple hubs via protocol? or this isnt important too? with adc its possible, with nmdc not. open up another client is not a solution ;)
I already done this for my client, works on both nmdc and adc :) It's always been possible, and we actually talked about doing it for DCDM years ago, but never did. The idea is to have different shares on different ports, because then you have different listeners for each share and the whole guessing what hub a user is trying to download from is not important because you will have that share only on that port, so even if it guesses hub wrong it will still be from a hub where you have that share, since the request is done on port.
Nice, good to see that working implementation exist :)
Quote from: Carraya on 07 January, 2008, 19:13:02
I already done this for my client, works on both nmdc and adc :)
And it is working as I been testing this with Carraya's new client. :D
it is about time is being done, I am sick and tired of running several clients.
Carraya Client ? is he making any clients these days at least i hope not
Quote from: Toast on 08 January, 2008, 06:05:02
Carraya Client ? is he making any clients these days at least i hope not
Yeah I am, besides my obvious dislike of you why do you hope not.
No flamewar here, please. Go to the DCDEV if you want some. ;-)
Quote from: Carraya on 07 January, 2008, 19:13:02
I already done this for my client, works on both nmdc and adc :) It's always been possible, and we actually talked about doing it for DCDM years ago, but never did. The idea is to have different shares on different ports, because then you have different listeners for each share and the whole guessing what hub a user is trying to download from is not important because you will have that share only on that port, so even if it guesses hub wrong it will still be from a hub where you have that share, since the request is done on port.
It's good to see some people still working on NMDC implementations ;D
Is encypted transfer between clients possible to use on NMDC? I've seen some newer client had such a feature (though it was marked by experimental) but why not ask if pros are here ::)
Quote from: Naithif on 09 January, 2008, 22:42:25
Is encypted transfer between clients possible to use on NMDC?
Yes it is possible ;)
Thank you ::)
Even if PPK has answered already, yes it's just as possible to make a $SUPPORT for it in nmdc as it is to make an extension for adc.
But no one make it...
But how could a client that's already out use secure transfer on NMDC? ???
I believe not by adding new support, it wouldn't be non-functioning until all clients support it isn't it?
And if it would be possible, and all the requirements are already implemented (if it works on ADC), why it's only ADC? >:(
Quote from: Naithif on 10 January, 2008, 15:21:12
why it's only ADC? >:(
Afaik in ADC it is now as unfinished extension. I'm sure that after they finish it will be easy to hack it for use in nmdc (i want to do that, only for that fun to show that it is possible in nmdc) :P
I already done this for my client, works on both nmdc and adc It's always been possible, and we actually talked about doing it for DCDM years ago, but never did. The idea is to have different shares on different ports, because then you have different listeners for each share and the whole guessing what hub a user is trying to download from is not important because you will have that share only on that port, so even if it guesses hub wrong it will still be from a hub where you have that share, since the request is done on port.
Carraya
Where is link to client ?
QuoteWhere is link to client ?
It does not exist, yet anyway
Quote from: Archangel_UK on 10 February, 2008, 16:35:16Carraya
Where is link to client ?
It's only been released as alpha yet (to a selected audience), so there's not really a publicly available link, but it is however in my dc share (if you can find me on dc). I will post on this forum, when there's a public beta available.