Olorin

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

33 posts in this topic

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

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

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

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

+1 request for ur mod ;) --> PM

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

and what?

You should not flood.

to: Satan

Sorry, - offtop.

Share this post


Link to post
Share on other sites

Flood where?

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

Share this post


Link to post
Share on other sites

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

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 by Toast

Share this post


Link to post
Share on other sites

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

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

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

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

Cool :)

please do but isnt it psuedo cid in nmdc hubs ?

Edited by Toast

Share this post


Link to post
Share on other sites

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

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