DC++ tries to connect/pm through wrong ADC hub

yes, it's wrong now...round-robin would be better (starting with the hubframe hub if added from hub frame)

Same problem doesn't apply for connecting only, but also for private messaging, sending search results and user commands. I think there shouldn't be online user map stored in ClientManager, but it should try to find online user in correct hub. It would save some memory too.

+1

It's for private messaging too, and it's a critical security issue in that manner, so it would be urgent to fix this bug.

** you cannot share sensitive information on "trusted" hubs in pm, since you never can be sure if your pm goes through on your trusted hub or on another one
** you cannot control bots, because they answer on random hubs and take actions on random hubs
** it's an irritating, old bug but noone seems to care

i already tried to fix this bug, but without success. Code of this part is too complicated and it would require redesign client and gui part to avoid stability problems.

it's a privacy problem too, so i set it to hight

Ok, committed a tentative fix for this...the prefered hub won't be saved in the queue though so it's only valid for the first connection attempt...there's also no warning if pm:s go through another hub (ideally one would have a dropdown with a hub url chooser in the pm case)

Sounds good :) (no, not "good".. rather "great" ;)) )

Just a question about PMs.. you wrote that "there's also no warning if pms go through another hub".. Theoretically how can it happen? I mean when you open a private message window, the PMs in it goes through the initial hub, right? I think if the connection is closed with the original hub, it can go through another one even if the client reconnecs, right? - Maybe this case dc++ could enter a line to the pm window telling the user that the connection with the preferred hub is lost, they have x more hub in common and those will be used for pming. DC++ don't have to track it anymore, but the user will know that it's not ensured that their pm goes through the original hub. If the sender now wants to ensure what hub is used, he may close and reopen the PM window. But you're right, a drop-down list would be better. Just playing with my thougts.

would be nice to only see the nick/hub the PM is going on with, not all of the nicks, in the title bar.

I'm not sure about situation when adding ADC source from search result. Since it doesn't know the user's hub, the "hubHint" variable will contain list of all hubs where the user is connected to. What will happen then?

Also, I think there's a bug in ClientManager.cpp, function findOnlineUser.

there's: if(u->getClient().getAddress() == hintUrl) {
but it should be if(u->getClient().getHubUrl() == hintUrl) {

because hintUrl is usually set to hubUrl and not to address.

This bug has been marked high since almost a year now, has there been ANY progress?

I still can not get a filelist or download from someone if we both are also in a ADC hub where downloading is blocked (like dcdev). This is starting to feel a little silly to have to close one hub to be able to download off another.

rev 1864 introduces favorite hub groups; PMs & connections with users in hubs that are part of private fav hub groups should now always happen with the correct hub, and won't happen if that hub is offline.
possibly fixed other issues related to this, and added saving of queue hub hints.

haven't tested much of it.

This bug is already fixed by someone, why are you assigning it to yourself?

Reverted

mb.team dont mess around here this isnt your playground !!

ha-ha-ha!

Hi!
That's great!
People, don't you know about mailing lists?

See priv discussion.

Fixed in version 0.760

the private hub group deal may be removed in the future. re-opening this bug for now.

I would insist on fixing this bug completely - introduce hubhint in search results (probably via token) + solve the situation when file with different hubhint is being requested but old connection is used (so connection is made via invalid hub).