Hide share feature bug

[Mek 13]

Let me explain by example:

I am an OP on a hub, I have share enabled, people download from me. But then I realise they are depleting my upload limit (my internet does not work when it's depleted completely), so I disconnect from that hub, enable Hide share feature under this particular hub in favorite hubs, and reconnect. My share is hidden, but people are still downloading from me. Is this a bug?

[Big Muscle 1]

Maybe bug, maybe not. Everyone should realize that Hide share feature available in some clients is one of the "fake" feature. Current (NMDC) protocol has no way to detect which hub the connection comes from. So it is impossible to really hide share for any hub. It "works" only by "oh, I don't the hub, but I will select random one and maybe it will work"

[Crise 26]

Maybe bug, maybe not. Everyone should realize that Hide share feature available in some clients is one of the "fake" feature. Current (NMDC) protocol has no way to detect which hub the connection comes from. So it is impossible to really hide share for any hub. It "works" only by "oh, I don't the hub, but I will select random one and maybe it will work"

It isn't really quite as random as you make it sound, since nmdc pseudo cids do the job in a decent way these days. Sure there are possibilities for incorrect behavior, but not nearly as much as before...

[Big Muscle 1]

CIDs for NMDC don't do anything, because they aren't transferred during connection, so it can't still identify which hub the connection belongs to.

[Lotus 0]

But if I am connected only on hubs where I have OP account and the share hidden... :unsure:

[Big Muscle 1]

Then this feature is unnecessary, because you needn't share at all.

[Guest Toast]

Actually BM this feat is quite nice to have since ive got places i dont wanna share eg DCDev etc and all ADC Hubsofts dont support hideshare actually the only one out of the box that does is ynhub.

[Big Muscle 1]

Nice to have a feature which doesn't work? It works partially in NMDC, but doesn't work in ADC at all... just look at the source, if you are in more ADC hubs, it will always take the first one and not the correct one where the connection belongs to.

	bool getSharingHub(const UserPtr& p) {

		Lock l(cs);

		OnlineIterC i = onlineUsers.find(const_cast<CID*>(&p->getCID()));

		if(i != onlineUsers.end()) {

			return (!i->second->getClient().getHideShare());

		}

		return true;

	}

but "onlineUsers" is multimap, so it can contain more records to one CID. The stated code always select the first record. But what if I share for this record and have hidden share for the other ones?

And what will happen when I want to download something from user with hidden share and I disconnect from the hub at the time when connection has been established but file hasn't been requested yet? I will be able to download normally although share should be hidden ;-)

[Crise 26]

Ok, I was wrong not a big surprise really since when that was made I was a complete newbie and then it was just copied from pwdc to apex, now looking into improving it I just have to ask this:

In newer SDC svns there is a nice method/function in ClientManager to handle hintUrls and that function compares passed hintUrl with the result of getAddress() but as far as I can see the hintUrls are most of the time of the getHubUrl() sort (ie. an address with port, while the other one is always without, right?). Now logic tells me this won't match up... or have I missed something here?

[Big Muscle 1]

I have to check it :-)

EDIT: yes, it was wrong, it should be getHubUrl()

[Guest Toast]

Then make a better feat that works since we are plenty of user that wants this functions where there isn't a substitute for it in hub software since we don't wanna share on every hub since there are other purposes with some hubs then sharing.

[Big Muscle 1]

I can't do, because as I already said it's impossible to do it for NMDC protocol (and with current implementation it's impossible also for ADC)

[Lotus 0]

But if I am connected only on hubs where I have OP account and the share hidden... :crying:

Then this feature is unnecessary, because you needn't share at all.

Yesterday I connected to hubs where I have share visible, for downloading purposes.

Today I only connect to hubs where I have OP account and hidden share, in order to only chat with my friends.

But they can still download from me...

Why it is impossible to implement for this particular case ? Because my share is hidden in every hub where I am now connected. Not like yesterday...

I read that when the first DC client was made, it was capable to connect to only 1 hub at a time. I think that this was the basic idea behind the DC protocol. Now things evolved but you still build and improve and build on the old concept of the "1 hub only". And probably the protocol hasn't changed also in this regard.

Since now I can connect to N hubs, it would be very nice to have different share for each one of them, according to each particular hub specifics. Because hubs have different share requirements, not only in share size, but also some recommend or even forbid sharing certain material. For example, on a "music" hub I would love to share only music files. And on my own hub I would probably have the idea to require the users to share only music... but this is impossible with the current clients if they are connected on more then just my hub.

I agree that this would be not as simpler as it is now and probably "fake feature", not fully supported by the protocol. But I still think it would be a step forward.

[Mek 13]

Okay, so, from what I read, I guess it is technically impossible to fix my reported bug.

Thank you for replies.