Prevent users from occupying more than one upload slot

[Big Muscle 1]

just show me one case of different files with same TTH and same size

there will be a way to restore, because no another file with given size can't have same TTH, so we can restore exact hashed file

yes, we can but it takes a really long time to generate big files to match TTH :D

[ifmn 0]

BM, you are wrong. this can be proven mathematically/logically, but ill just post a quote:

In computer science, a hash collision is a situation that occurs when two distinct inputs into a hash function produce identical outputs.

All hash functions have potential collisions, though with a well-designed hash function, collisions should occur less often (compared with a poorly designed function) or be more difficult to find. In certain specialized applications where a relatively small number of possible inputs are all known ahead of time it is possible to construct a perfect hash function which maps all inputs to different outputs. However, many hash functions, including most cryptographic hash functions, produce a fixed size output from an arbitrarily long message. In such a design, there will always be collisions, because any given hash has to correspond to an infinite number of possible inputs.

also, check this: http://www.cryptography.com/cnews/hash.html

[Big Muscle 1]

ifmn: read again what I wrote. I didn't write that there can't be a TTH collision. I wrote there can't be TTH+size collision and it's verified and different file with same TTH and same size has never appeared.

also, check this: http://www.cryptography.com/cnews/hash.html

I already read this page.

"Collisions were announced in SHA-0, MD4, MD5, HAVAL-128, and RIPEMD"

where's TTH? :)

[ifmn 0]

different tth hashes - limited number; different files - unlimited number. Pigeonhole principle

it is possible imo. also, the fact there are no recorded collisions doesnt mean there cant be any.

[Satan 1]

different tth hashes - limited number; different files - unlimited number. Pigeonhole principle

it is possible imo. also, the fact there are no recorded collisions doesnt mean there cant be any.

The same principal could be applied to anything. Welcome to physics. Can we stop the catfight please.

[Big Muscle 1]

yes, it's possible to happen, but it's not probable to happen. oh, I hope you understand what I mean, it¨s strange to say it in English )

but ok, stop off-topic and return to original topic

[Mikey_69 0]

I understand the frustration over the same users having multiple of your slots open, but as long as you have decent upload speeds on both it's no worries for me...

However, would I have the misfortune of finding a user who uploads with both slots at below 200kb/s I'd PM him/her and tell them that I cannot occupy a slot for them because of their speed and the estimated time it would take. (My waiting users queue never goes below 30 people). So I'd disconnect 1 of them after letting him/her know and let someone else have that slot...

[Zlobomir 3]

I still think that if we match ALL possible info it will be enuf. Even, Apex could do "extended check" if it finds both users are Passive, i. e. if it founds that "nick + socket check" is not sufficient.

[Greg 0]

Partial sharing, that is sharing files which you are downloading cannot be disabled. It means that if someone leeches and doesn't share anything they will at least be able to upload something. It also removes the whole multisourcing damages the network argument as you can even share something before it's completed meaning you can share the content a lot quicker and in fact provide more sources for a file rather than just removing them. Also I can see no reason why you would need to disable this, saying you want to stop bad content spreading is not a reason. Why would you be downloading bad content?

[Noctis 0]

Yeah, and it doesn't occupy an extra slot or something like that... "What you download others might want too." But if you have a share that is "popular" enough (meaning you always have waiting users), you won't be uploading partial stuff too often.

[taltamir 0]

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

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

[Big Muscle 1]

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

[iceman50 0]

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 September 2, 2007 by iceman50

[taltamir 0]

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.

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

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

:blink:

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.

[Guest Toast]

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

still we dont want more speed mods that base what users think is fair then noone would share **** on dc++

[SMT 0]

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

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

[xs1 0]

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?

[Lee 84]

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

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

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

[wdc 0]

On 3. 6. 2011 at 4:25 PM, xs1 said:

I sometimes have as many as 5 connections from 1 person... Its not fair to others who have to wait in line.

same issue there, if we (me and downloader) are in lets say 5 same hubs, then it will eat 5 download slots just for this one person. I think this is just a must basic feature to give ApexDC user ability to limit upload slots/connections per one user / IP:port.

Edited April 1, 2017 by wdc