taltamir

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

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!