73 replies to this topic

[taltamir]

There seems to be some complete misunderstanding as to what this is about. This is DEFINATLY an important feature...

Multi source downloading is NOT about raping someone's connection by using several connections to a single person to get more of his bandwidth compared to other people, it is about getting a single file from multiple people.

Example (from real life, Sql and John are the actual nicknames and the speeds are true):

I upload at 80kbs
Sql from hub 1 is downloading from me at 20kbs
Sql from hub 2 is downloading from me at 20kbs
Sql from hub 3 is downloading from me at 20kbs
John from hub 1 is downloading from me at 20kbs

*note = Sql had the same ip, dc tag, and sharesize in all three hubs. So don't tell me it is a different user. Besides, my idea was to go by ip with sharesize comparison for verification (for university students who share the same ip but are different people).

Had Sql only been allowed ONE upload slot from my machine he would have gotten 40kbs from me, and john would have gotten 40kbs. Instead Sql is getting 60kbs and john is getting 20. sql is also forcing my computer to make more random harddrive access increasing wear and tear on the drives.

This is an abuse of multi segmented downloading.

The non abuse way to use it is for Sql to download from me at 40kbs (ie, only one segment). And if he can also find them, download some from john at 30 kbs, and some from momo at 30 kbs and some from .... And so on... one connection per person, but connecting to multiple people (like in bit torrent basically).
Currently he could get three connections from me, and two from john, and three from momo, and so on...

So yes, there should definately be an option to prevent a single person from grabbing multiple slots from you. One slot per person, multiple slots per file is what I say!

[Satan]

Thats all fair and well. However, it's not possible as previously discussed. Not under NMDC anyway.

[Big Muscle]

taltamir, on Sep 1 2007, 06:24 PM, said:

I upload at 80kbs
Sql from hub 1 is downloading from me at 20kbs
Sql from hub 2 is downloading from me at 20kbs
Sql from hub 3 is downloading from me at 20kbs
John from hub 1 is downloading from me at 20kbs

but "Sql" in hub 1 is me, "Sql" in hub 2 is my friend and John is Sql from hub 3 but only with different nickname. What then? According to your proposal we could disconnect Sql from hub 1 and Sql from hub 2. So 2 totally different users would be disconnected and one same user with different nicknames would still eat your slots

[iceman50]

well the only proposal which would be more plausible for ADC is to go via UserIP but the client could check Nick against the IP it receives from the userconnection

PS> it is possible in NMDC to an extent learn your protocol a connection attempt must be made via an IP of said nick in this instance sql ... so therefore you can check via the active connection made to your machine via the client

Edited by iceman50, 02 September 2007 - 03:40 AM.

[taltamir]

Big Muscle, on Sep 1 2007, 11:12 AM, said:

but "Sql" in hub 1 is me, "Sql" in hub 2 is my friend and John is Sql from hub 3 but only with different nickname. What then? According to your proposal we could disconnect Sql from hub 1 and Sql from hub 2. So 2 totally different users would be disconnected and one same user with different nicknames would still eat your slots

Except john had one ip. While sql had the same ip, and the same share size, in all three hubs...

Same share size + same ip + same nick + same dc version = same person.

It is entirely possible to limit on a per ip basis. And for the sake of fairness to people using a university internet then you also compare their sharesize, dc version, and possibly nickname.
Yes the nick can be different from hub to hub. And the version can be different beacuse of emulation (custom tags). But so what? then a few people WILL be getting multiple upload slots from you, at least the problem would be subsided... Right this very moment I am uploading at 120kbs... to 4 people. 1 has one slot, and each of the three others have two slots each. their IP's and nicknames are the exact same on those different connections (i didnt bother checking their tag and their sharesize), they are just in different hubs.

iceman50, on Sep 1 2007, 09:38 PM, said:

well the only proposal which would be more plausible for ADC is to go via UserIP but the client could check Nick against the IP it receives from the userconnection

PS> it is possible in NMDC to an extent learn your protocol a connection attempt must be made via an IP of said nick in this instance sql ... so therefore you can check via the active connection made to your machine via the client

Seconded, there is nothing in the protocol PREVENTING this. Heck, the protocol wasn't originally intended for multiple connections anyways. Multiple connections make use of the resume function combined with completion emulation and the antigragmentation downloading method to work.
This is much much much simpler... check for the ip of a connecting client. If it is identical to an existing upload then compare the nick/sharesize/tag. If they match (or ideally, only if the sharesize matches, the other two aren't needed) then your client needs only to reject the incoming connection. It is much much MUCH simpler then implementing segmented downloading in the first place.


As an interesting aside. You can tell if the person taking up multiple slots is using a segmented client or not... If they are, then they will be downloading the same file. But if they aren't then they will be downloading different files. So this isn't even an aspect of segmented downloading, but purely an uploading issue that exist even in non segmented clients.

[SMT]

Satan, on Sep 1 2007, 09:00 PM, said:

Thats all fair and well. However, it's not possible as previously discussed. Not under NMDC anyway.

don't say "impossible", because there ARE working implementations

[Big Muscle]

SMT, on Sep 3 2007, 12:04 PM, said:

don't say "impossible", because there ARE working implementations

there aren't... yes, there are implementations which almost work, but it's very easy to break it.

[SMT]

Big Muscle, on Sep 3 2007, 05:45 PM, said:

there aren't... yes, there are implementations which almost work, but it's very easy to break it.

there is nothing to break. some crazy wants to simulate, that he can't download from me because have same share and ip as some other user?

[Pinchiukas]

How about matching IP+port? There is no way more than one person can be connecting from behind a NAT using a single port. At one given moment, at least.

And even then, what's the worst that can happen? All the clients behind a NAT that want to download from the same user are placed in a queue. Is that so bad that this feature shouldn't be implemented?

I can give you one more reason why this feature would be useful: I have 100mbit upload speed. And as you might have guessed, I'm connected to several hubs as are people that try to download from me. Instead of downloading in a single instance with a speed of say ~8MB/s they create 3 connections ~2MB/s each which is not only slower but slows my system to a crawl (unusable even) and also cripples the speeds of other people downloading from me. I can limit the upload speeds but some hubs forbid it and this is kind of running away from the problem... Oh... and it sucks.

[xs1]

I'd hate to have to bump such an old topic, but this is really a big issue i have as well. I upload, alot. Thats basically all i do all day is serve files in numerous hubs. I sometimes have as many as 5 connections from 1 person... Its not fair to others who have to wait in line. This is a feature that really should be initiated. Any word on this even still?

Attached Files

•  uploads1.1.png   188.49K   12 downloads
•  uploads1.png   113.84K   11 downloads

[Lee]

xs1, on 03 June 2011 - 02:25 PM, said:

I'd hate to have to bump such an old topic, but this is really a big issue i have as well. I upload, alot. Thats basically all i do all day is serve files in numerous hubs. I sometimes have as many as 5 connections from 1 person... Its not fair to others who have to wait in line. This is a feature that really should be initiated. Any word on this even still?

It's possible with ADC hubs because every user has a CID.

[xs1]

Lee, on 04 June 2011 - 06:25 AM, said:

It's possible with ADC hubs because every user has a CID.

Be that as i may , most of the hubs today are not exclusively ADC hubs.. This needs to be iniated as a client feature.

[Lee]

xs1, on 15 July 2011 - 11:33 PM, said:

Be that as i may , most of the hubs today are not exclusively ADC hubs.. This needs to be iniated as a client feature.

Then it would have to be DC++, because only then would all DC++ based clients use it with the same level of compatibility. However, they are not interested in working on an old protocol and are focusing on pushing ADC for hub owners to migrate.