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

[adrian_007 0]

just a thing.... patching nmdc will only make adc life more complicated (in this scenarion, there's no reason to switch to adc, in case you're not developer/advanced user in dc world). instead focus on adc-extensions that would bring new ppl to this protocol ^^

[Olorin 0]

just a thing.... patching nmdc will only make adc life more complicated (in this scenarion, there's no reason to switch to adc, in case you're not developer/advanced user in dc world). instead focus on adc-extensions that would bring new ppl to this protocol ^^

you are right. But the protocol will not be patched. The client wiil be patched because of some troubles in nmdc.

[adrian_007 0]

maybe in not full meaning, but it surely will be patched - because of this troubles in nmdc :]

[djbarney 0]

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

Hiya BM, any news on progress in this area m8? I would love to see an option (can be disabled by default ofcourse) that would "prefer" different ip's.. Let me explain my current situation:

I am in around 10 to 20 hubs right now, all kind of focussed on electronic music. A lot of other ppl do the same. So when i connect to these hubs, it can happen that i find a user called "insertnicknamehere" in hub 1,2,3 and 7 that i am in as well. That's not a problem, the problem for me starts when this "insertnicknamehere" queues some tracks from my share, because apex currently sees "insertnicknamehere" from 4 different hubs, as 4 different users. As i spend a lot of time on these hubs, and i dont mind filling my uploadspeed to ppl, queues of uploaders of over 100 different users can appear in my list, sometimes even more. Still, i have no problem with that. The "problem" for me is, that sometimes there's 100 different users waiting for a slot from me, and "insertnicknamehere" is taking 4 or 5 slots out of the 15 i have opened. Now that is unfair imo. "insertnicknamehere" could take just 1 slot, and leave those other 4 slots he's using (often for the same file as well, cuz of the segmented downloading features in various clients) for other users that are waiting for a slot. I really dont mind if "insertnicknamehere" takes all of my slots while they are open and available (i'd rather see my uploadstream being used then being unused) but i do mind when "insertnicknamehere" uses multiple slots while other ppl are also waiting for a slot. To me it feels like that user is very greedy then.

So what i would like, is an option that would look at the ip-adress of a user that wants to download from me, and let the client check if that same ip-adress is already uploading. Basically a "1-slot per ip-adress" idea. To make that idea more fair even: i'd like to see that it checks available slots before it allows or denies the upload. With that i mean: "if ip is already downloading & if open slots is bigger then 1, allow upload" and "if ip already downloading & open slots is 0, queue upload like it does normally when slots are unavailable"

I'm not great with coding etc, but i think that something like this could be made pretty easily and would really be an improvement to the client, because it will open up slots for other users that are otherwise hogged by the "greedy" users.

I'm not sure, but i have a feeling that some dodgy clients are forcing connections, or are requesting uploads way more often then normal clients, because i happen to see a lot of the same nicknames hog up multiple slots vs normal users. With this requested function, i guess those ppl would be handled exactly the same way as normal users.

Anyways, long story, hope it makes some sense =)

/djb

[Olorin 0]

1

[Guest Toast]

http://dcpp.wordpress.com/2007/10/02/nmdcs...ient-handshake/

http://dcpp.wordpress.com/2007/10/04/adcs-...ient-handshake/

a simular system for nmdc must be made so this can work

and since users insist of using nmdc instead of adc then the user must suffer the drawbacks of the protocol

but if the getCID protocol for nmdc can be updated to detect CID in nmdc this might change but still for what use ?

trying to prolong the nmdc lifespan with all its drawbacks is that really a noble cause ?

[Olorin 0]

http://dcpp.wordpress.com/2007/10/02/nmdcs...ient-handshake/

http://dcpp.wordpress.com/2007/10/04/adcs-...ient-handshake/

a simular system for nmdc must be made so this can work

and since users insist of using nmdc instead of adc then the user must suffer the drawbacks of the protocol

but if the getCID protocol for nmdc can be updated to detect CID in nmdc this might change but still for what use ?

trying to prolong the nmdc lifespan with all its drawbacks is that really a noble cause ?

OK :shifty:

You can read Big Muscul posts above He have already thought about some ways :yahhooo:

[Guest Toast]

That was what i said if u cared to read my post and not just blurry thru it

nmdc currently supports pseudo cid not actual cid there for the GetCID Protocol got to be reworked and for it to work a 100% later on means that old clients will corrupt this since they dont support the GetCID Protocol that BM wants to make.

this will probly only work for newer clients. this is already a standard in adc so why bother with in the long run of patching nmdc, just update to adc and be done with it

i totally agree with Adrian about making ADC Extensions instead of pathcing NMDC cause NMDC has by this time so many flaws that one more patch cant really help it and making extensions isnt gonna improve it in the end

Edited September 21, 2008 by Toast