Posted March 27, 2008 I have 7 hubs opened at a time. All in a LAN. Many people uses all hubs at one time, so if one of them tries to load a file, he links to me from 3-5 hubs at a time, flooding my slots. There is limiter by ID needed. ID is cummulative property of a user=[ip, all tag fields, exact share, nick]. So if one parameter like nick is not the same, the user still defined as known and linked user to prevent new connections from him. And parameters showld be rated. For example, same share or IP is a miracle. Also I can flood the same way other users and the limiter is needed even here. Share this post Link to post Share on other sites
Posted March 27, 2008 Discussed for toooo long, not possible under NMDC protocol, will be fine in ADC, let's hope. As you speak of LAN hubs, maybe you can persuade the owners and users to switch to ADC. Share this post Link to post Share on other sites
Posted March 28, 2008 Discussed for toooo long, not possible under NMDC protocol, will be fine in ADC, let's hope. As you speak of LAN hubs, maybe you can persuade the owners and users to switch to ADC. The ADC-based future is like World Communism... The everything will be OK when it comes Thanx for your posting, your answer saved me lots of time, because i planned to implement this in my Apex mod. So now I wont ever try. Share this post Link to post Share on other sites
Posted March 28, 2008 You are welcome to try of course, but the unique identification of users under NMDC does not seem possible for me. P. S. Pls, PM me the name and maybe link to your Apex mod. Share this post Link to post Share on other sites
Posted March 29, 2008 You are welcome to try of course, but the unique identification of users under NMDC does not seem possible for me. P. S. Pls, PM me the name and maybe link to your Apex mod. Maybe it's not so hard to close all but one connections that have the same IP... Will dig it how to implement.... If any positive results, I'll post in this topic. 2) mod has no public webpage yet, i'm too lazy... :blushing: we have only LAN-based forum where dev is discussed.... Share this post Link to post Share on other sites
Posted March 29, 2008 Maybe it's not so hard to close all but one connections that have the same IP... different users may have same IP, so it's not solution :blushing: Share this post Link to post Share on other sites
Posted March 29, 2008 different users may have same IP, so it's not solution :blushing: Actually it is, f* virtual IPs, f* trash ISPs, f* their users. :P Share this post Link to post Share on other sites
Posted March 29, 2008 BM, of course i understand it that it's not a complete solution. Actually it is, f* virtual IPs, f* trash ISPs, f* their users. :blushing: That's actually not a problem for LANs where each user has his own IP. PS. Anyway, the DC++ is a strange thing over the Internet when speeds are limited. It has no ratio (like torrent), so there are no mechanisms to force people to upload data and avoid leeching. Please don't throw me with stones, but it's my (and very stable) point of view! Share this post Link to post Share on other sites
Posted March 29, 2008 hey you bring alot of interesting ideas to the table, your ok in my book :blushing: Share this post Link to post Share on other sites
Posted March 29, 2008 BM, of course i understand it that it's not a complete solution. That's actually not a problem for LANs where each user has his own IP. PS. Anyway, the DC++ is a strange thing over the Internet when speeds are limited. It has no ratio (like torrent), so there are no mechanisms to force people to upload data and avoid leeching. Please don't throw me with stones, but it's my (and very stable) point of view! DC 'sort of' get's around this problem by demanding users have a share to connect to hubs. Share this post Link to post Share on other sites
Posted March 29, 2008 And what the problem??? Only exact share size&IP is very stong identities. But there are autoreplier... tag... mac!!! And the mac is the strong identity in one session. Don't you think so? Macs are sent with each tcp frame. Tag is in the users list, IP is got with standart protocol methods... WHAT ELSE??? do you need to identify a user??? That is a very strong identification method. Don't you think we are banning users only by IP... that is a coplicated method using mac, ip, nick, exact share, tag, autoreplier and route trace to a host. We a counting an ID like torrent id for file, hashing parts of a user identity to prevent a user database rob. Share this post Link to post Share on other sites
Posted April 2, 2008 The ADC-based future is like World Communism... The everything will be OK when it comes :thumbsup:ADC is here. It just needs hub owners to switch to ADC hubs now. ;) Share this post Link to post Share on other sites
Posted April 2, 2008 Fight the power. Join the ADC! :thumbsup: Share this post Link to post Share on other sites
Posted April 4, 2008 and what? You should not flood. to: Satan Sorry, - offtop. Share this post Link to post Share on other sites
Posted April 4, 2008 Flood where? I been reading the news, there are no floods I know offf. Share this post Link to post Share on other sites
Posted August 22, 2008 bit late i guess, but i'd love a feature like this too. And i dont think it should be too hard, i get that it's nearly impossible to identify nmdc users from eachother, but couldn't you make it an "option" that's standard turned off, to "block multiple ip's" ? plus, i guess you could easily identify a user by the myinfo stuff he sends. Anyways, hopefully you could still have a look at this if u got some time for it =) Share this post Link to post Share on other sites
Posted August 23, 2008 (edited) This already exists in ADC function it wont exist in NMDC atleast not for this client i do belive if someone doesnt make a hexxed version and waste their time develop it. Edited August 23, 2008 by Toast Share this post Link to post Share on other sites
Posted August 23, 2008 I just got an idea. There could be CID extension for NMDC sent in $Supports. If user supports it, we could send him $GetCID| command before transfer starts and he would responds with $CID <his_CID>|. This <his_CID> would be searched in existing users. If found, this user would assigned to this transfer (and old user thrown away). If not found, user's CID would be changed to this new one. The purpose: it would allow recognizing users and block transfers with duplicate CID. Negative: it would work only for clients supporting it. Share this post Link to post Share on other sites
Posted August 23, 2008 if you can figure out a way to implement this so that at the same time the client dont have to send filelist requests in all the hubs that we both are connected to it would be great or at least it will recognise that its the same user and just apply the first list to all sources? Share this post Link to post Share on other sites
Posted August 23, 2008 Well if newer clients support it then ppl might just stop using thier old client and upgrade so it aint all bad :) Share this post Link to post Share on other sites
Posted August 23, 2008 And I detected that some older clients (iDC++, Zion++) already supports some kind of GetCID, so I could continue with this :-) Share this post Link to post Share on other sites
Posted August 23, 2008 (edited) Cool please do but isnt it psuedo cid in nmdc hubs ? Edited August 23, 2008 by Toast Share this post Link to post Share on other sites
Posted August 23, 2008 pseudo-CID (hash of nick+huburl) is only what you see. The remote client see its own CID correctly and that's why this GetCID extension could be useful to transfer this real CID and replace your pseudo-CID with it. Share this post Link to post Share on other sites
Posted August 23, 2008 that would be good news for nmdc users its nice that this is standard in ADC :) Share this post Link to post Share on other sites