Incorrect encoding of file names, directories ...in the search box.

[tka4ev]

The problem with the coding in the search box if the user is connected to a hub such as the external IP address, and I'm on the inside then the function
ClientManager::getInstance()->findHub(hubIpPort) returns an empty url and a subsequent call to ClientManager::getInstance()->findHubEncoding(url)
returns the system encoding, and encoding CP1251 hub as a result of the search box in the file names, paths, nicknames does not display correctly.

void SearchManager:: onData (const uint8_t * buf, size_t aLen, const string & remoteIp) {

..........

 string hubIpPort = x.substr(i, j-i);
 string url = ClientManager::getInstance()->findHub(hubIpPort); >>> returns an empty url

 string encoding = ClientManager::getInstance()->findHubEncoding(url); >>> does not return the correct encoding hub
 nick = Text:: toUtf8 (nick, encoding);
 file = Text:: toUtf8 (file, encoding);
 hubName = Text:: toUtf8 (hubName, encoding);

...........

 SearchResultPtr sr (new SearchResult (user, type, _slots, freeSlots, size,
  file, hubName, url, remoteIp, TTHValue (tth), Util:: emptyString));

 fire (SearchManagerListener:: SR (), sr);

...........

}

Forgive me, I used google translate

[Steven Sheehy (steven-sheehy)]

While I understand the logic of what you're saying, I don't understand what would cause this. In what situations would you get a search result with ClientManager::getInstance()->findHub(hubIpPort) returning an empty url for it? The hub:ip is required in the $SR and findHub() iterates over all of the available hubs you are connected to. The only situation I can see is if you got a search result from a hub (if passive) or user (if active) after leaving the hub you initiated the search from. However, in that case you wouldn't want the search result anyway since you're not in the hub to download it.

[Razzloss (razzloss)]

Well, I doubt you'll get a passive result after leaving the hub....

Aww.... I really don't want to go checking the code or protocol right now so I might be just talking BS, but here goes anyway...

If hub has multiple IPs or ports, the SRs coming in will contain the IP:port where that user has connected to. If local client is connected to another address/port, like private IP of the hub, (it's the same hub still) obviously the IP:port won't be found by ClientManager. (Can you even download those results, if the client doesn't know the hub?)

If I'm correct, this really isn't fixable. At best the default hub encoding could be used instead systemCharset, but that was GUI only?

--RZ

[Steven Sheehy (steven-sheehy)]

Ok, so this should only occur when a hub has both a public IP and a local IP. I assume a hub can't have multiple public IPs or multiple private IPs since Client.h only stores one local and one public IP? What if we rewrite ClientManager::findHub to also look at client->getLocalIp()? Or is it possible that this is not set/not accurate with what we're seeing in search results?

[Razzloss (razzloss)]

Hub can have any number of public and local (by local I mean IPs in RFC1918) adresses. So I don't think there's anything to be done to the ClientManager::findHub, assuming the hub doesn't let the client now about all it's IPs (which I doubt considering the state of the rest of NMDC).

Let me explain how I understood the problem.

User A connects to hub X with address 1.1.1.1,
User B connects to hub X with address 2.2.2.2.

If both are active, user A sends SR to user B with hub address 1.1.1.1. User B has no idea what this address is, as he has connected to 2.2.2.2, there's no local IP or anything that would connect this address to 1.1.1.1. So findHub returns an empty url. (With passive user receiving SR there shouldn't be any ambiguity what hub it came from. Do the passive results even include the hubIP:Port?)

Feel free to correct me if it seems I'm on crack...

--RZ

[Steven Sheehy (steven-sheehy)]

The issue it seems is that ClientManager::findHub() doesn't always find the hub if the hub has multiple IPs and the search result contains a different IP than the one the core expects. DC++ team, is there any way this could be fixed to find the hub?

[tka4ev (tka4ev)]

ok. try to describe the situation

net1: 10.139.xx - internal LAN
net2: 92.255.xx - Public network direct access to the Internet (my network)
net2 has more internal addresses in the range 192.168.xx

all machines these networks to see each other and can exchange information directly with peering

hub1 has address 10.130.0.226 and 2 public address 89.223.127.222

I connect to a hub at 89.223.127.222, but some users at 10.130.0.226
I can communicate with the user in active mode, and he with me but there is a problem
described by me in the search box.

In any case, it seems to me that the return from the function ClientManager::getInstance()->findHubEncoding(url)
Text:: systemCharset (systematic encoding) if not find a dc + + server is not correct because it
usually does not coincide with the coding dc + + server (in case of win32 clients the same on this there is no such problem).

In the setting of a parameter linuxdcpp <default-charset> so this value in my opinion and should return
function ClientManager:: getInstance () -> findHubEncoding (url) by default.

http://omploader.org/vM3NpMw/10.03.2010-13.49.12.png

[poy (poy)]

the general idea to be able to reliably find what hub a search result comes from is to send search queries with a different token in each hub; then on reception of a search result, simply match the received token to the ones that have been sent.

DC++ does not currently do this, but the plan is there. there are a few todo's scattered around the source to remind of this task...

[Steven Sheehy (steven-sheehy)]

Based upon Poy's response, marking as confirmed.

[poy (poy)]

my comment #7 was completely wrong. it applied to ADC hubs, which are not affected by these encoding issues since they are all UTF-8. there is however no plan to modify NMDC searches to have a hub differenciating token.

the current logic indeed breaks when faced with public/private address discrepancies. there is a fallback to finding a user only by nick were the nick+address match to fail (call to ClientManager::findLegacyUser in SearchManager::onData) but the resulting user isn't used to deduce a proper encoding.

[poy (poy)]

tentative fix in rev 3203; not tested at all.

[eMTee (realprogger)]

Fixed in DC++ 0.811.