There is connection per seeder limiter by ip or if possible by ID

[Olorin 0]

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.

[Zlobomir 3]

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.

[dmvn 0]

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.

[Zlobomir 3]

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.

[spyke 0]

+1 request for ur mod --> PM

[dmvn 0]

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....

[Big Muscle 1]

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:

[Zlobomir 3]

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

[dmvn 0]

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!

[spyke 0]

hey you bring alot of interesting ideas to the table, your ok in my book :blushing:

[Satan 1]

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.

[Olorin 0]

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.

[Pothead 0]

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. ;)

[Sergeo7 1]

Fight the power. Join the ADC! :thumbsup:

[Olorin 0]

and what?

You should not flood.

to: Satan

Sorry, - offtop.

[Satan 1]

Flood where?

I been reading the news, there are no floods I know offf.

[djbarney 0]

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 =)

[Guest Toast]

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

[Big Muscle 1]

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.

[en_dator 1]

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?

[Guest Toast]

Well if newer clients support it then ppl might just stop using thier old client and upgrade so it aint all bad :)

[Big Muscle 1]

And I detected that some older clients (iDC++, Zion++) already supports some kind of GetCID, so I could continue with this :-)

[Guest Toast]

Cool

please do but isnt it psuedo cid in nmdc hubs ?

Edited August 23, 2008 by Toast

[Big Muscle 1]

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.

[Guest Toast]

that would be good news for nmdc users its nice that this is standard in ADC :)