Prevent users from occupying more than one upload slot

[Aztek 2]

at least three clients implemented this feature very correctly: they are checking IP+exact share size, or IP+nick (if share size is 0).

i've tested this much and didn't find troubles with users beyond NAT

what clients?

[SMT 0]

what clients?

PM-ed. "cheating" clients are forbidden to advertising here

[Satan 1]

How are they cheating? If all they do is prevent one user from multi-uploading from you, how is that cheating?

[Big Muscle 1]

at least three clients implemented this feature very correctly: they are checking IP+exact share size,

I don't see it so much correct, because you can't get share size of connecting users in NMDC hubs.

[SMT 0]

I don't see it so much correct, because you can't get share size of connecting users in NMDC hubs.

i've seen only PtokaX (windows) and Verlihub (linux). both of them shows share size of every user when i connects to hub

[SMT 0]

well. even if hub does not show share size (never meet this rare case), just don't restrict their users. but uploading to same user from different hubs is not good behavior, because it forces user to join as much hubs as possible. users that didn't join all possible hubs looses in download speed / waiting time. so it must be fixed

[Big Muscle 1]

yes, you see share size in userlist, but you can't get share size of user who is connecting to you, just because NMDC doesn't have any user identification.

Imagine this:

User A - shares 2 GB

User B - shares 3 GB

(both have same nick, but are in different hubs)

now user A is connecting to you, but it gets share size of user B

then user B is conencting to you and it again gets share size of user B, but connection to this user will be dropped

[Aztek 2]

yes, you see share size in userlist, but you can't get share size of user who is connecting to you, just because NMDC doesn't have any user identification.

Imagine this:

User A - shares 2 GB

User B - shares 3 GB

(both have same nick, but are in different hubs)

now user A is connecting to you, but it gets share size of user B

then user B is conencting to you and it again gets share size of user B, but connection to this user will be dropped

what if it matches ip aswell?

[Big Muscle 1]

nevermind... both users can have same IP.. but what I don't know is whether they can have also same port.

edit: yes, they can have same port, if they are passive users

[SMT 0]

yes, you see share size in userlist, but you can't get share size of user who is connecting to you, just because NMDC doesn't have any user identification.

Imagine this:

User A - shares 2 GB

User B - shares 3 GB

(both have same nick, but are in different hubs)

now user A is connecting to you, but it gets share size of user B

then user B is conencting to you and it again gets share size of user B, but connection to this user will be dropped

why i see "hub" in Trasnfer List, is it fake? user connection (afaik) initiates via hub commands "$ConnectToMe" and "$RevConnectToMe", so client knows nearest incoming connections came from

[SMT 0]

i agree that there is insignificant probability of mistake (if both users have save Nick, same IP, and connects with same time, 2-3 seconds delay for socket connetion accept). but it worths fixing hell with 15-20 actively used hubs in one local network

[Big Muscle 1]

why i see "hub" in Trasnfer List, is it fake? user connection (afaik) initiates via hub commands "$ConnectToMe" and "$RevConnectToMe", so client knows nearest incoming connections came from

yes, hub in TransferView is just a guess from last ConnectToMe, but there is one thing... if user A tries to connect, then user B with same nick tries to connect and this user B connects faster, the user A will be dropped and hub of B will be displayed as hub of A. It¨s just current implementation of NMDC protocol.

[SMT 0]

yes, hub in TransferView is just a guess from last ConnectToMe, but there is one thing... if user A tries to connect, then user B with same nick tries to connect and this user B connects faster, the user A will be dropped and hub of B will be displayed as hub of A. It¨s just current implementation of NMDC protocol.

not big problem: user waits one minute before connections, but item in connection queue waits 1-2 secs (socket connect - socket accept)

with other unique things (IP, Nick) error probability is very low. its acceptable that second user in this rare case gots 'no slots' until 1st user completes his donwload

[Big Muscle 1]

error probability is very low

but it can happen and we don't play at "probability is low, so it can sometimes work"

[Greg 0]

Even if it is implemented, it's not going to be very efficient due to the prefixes a lot hubs require (registered) users to have? As I understand it the ADC protocol will have some features which will allow us to implement a feature like this a lot better. I don't think it's a partially needed feature and there's little point adding it to try and work with a protocol which really isn't designed for it.

[SMT 0]

but it can happen and we don't play at "probability is low, so it can sometimes work"

ha-ha, then don't use TTH hash because there is a probability of collision, and sometimes it will not work =)

well, it's your client and up to you to decide, implement user' requests or not.

but it is user' choice, which client to use =)

[Satan 1]

ha-ha, then don't use TTH hash because there is a probability of collision, and sometimes it will not work =)

There is a much greater possibility of error with the topic's technique. Whereas TTH can only be 'faked' with specific programs to do so.

[Big Muscle 1]

ha-ha, then don't use TTH hash because there is a probability of collision, and sometimes it will not work =)

no, there's not a probability of collision because we use also size check, so it will always work :D

[irish 0]

i don't, i download, sort and THEN put in the sharing folder...

i don't want the unsorted stuff i am not sharing atm to be uploaded.

Hi Aztek.

I think I understand now. You seem to have two complaints

(1) You don't wan't anyone having more than one connection to you.

I think that's fair enough. Personally I think if the person who has two connections to you, had any manners, they

would disconnect one of the connections providing they knew how to do it, and noticed it.

I've been on both ends. I have had the same person have two connections to me, and I've had two connections

to the same person. In the first case, it doesn't bother me. In the second case I will try to disconnect one of the connections. If that doesn't work, I'll pm the person and let them know that I've tried to disconnect, but it's not working.

Hey sometimes they're not bothered either.

(2) People are downloading stuff from you before you are ready to share it. I'm not sure how that's possible

unless you tick "share downloads instantly" or however it's worded.

I did get the impression that you weren't sharing anything at all.

But this isn't the case, is it?

M

[Satan 1]

I think that's fair enough. Personally I think if the person who has two connections to you, had any manners, they

would disconnect one of the connections providing they knew how to do it, and noticed it.

Good as that sounds, not everyone is always in front of their PC when they're downloading, and even if they did disconnect, DC would start another segment automatically.

[SMT 0]

no, there's not a probability of collision because we use also size check, so it will always work

there is a probability of tth collision even for files with same size (if you didn't know it) =)

[Big Muscle 1]

there is a probability of tth collision even for files with same size (if you didn't know it) =)

no, it's not... if two different files have same TTH, they have different size :)

[Noctis 0]

(2) People are downloading stuff from you before you are ready to share it. I'm not sure how that's possible

unless you tick "share downloads instantly" or however it's worded.

That looks like PFS (partial file-sharing) it's perfectly normal, it only affects your unfinished files, but they are not shared actually.

[Aztek 2]

i have it happening all the time, files i recently downloaded (download finished) are being uploaded even if they are NOT in share...

i hate that because i always want to review what i download before i share it (to stop bad content from spreading)

[SMT 0]

no, it's not... if two different files have same TTH, they have different size

back to school, please.

if things will be so easy, there can be possible 'super-archiver', that compress *ANY* file (regardless of its size) into pair size+TTH.

and 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

do you realize, that it's impossible to lossless pack DVD-image (or whatever) into 32bytes (24tth+8size)? =)