[Bug 3.8.7] Duplicate connections as UP
 

Salut à tous, as an UP i've seen today duplicates in UP connections as well as leaf connections. ie two instance of the very same IP (they weren't nated or behind router etc..). This is quite a stupid bug to say the least ;) Now, please fix it!

Merci beaucoup

Salut et voilà

I just checked my connections--no duplicates (uptime 30 hrs as UP on the official 3.9.1beta).
Sandvine p2p controls did show duplicates (of my own client) in the past: old screenshot here

This does not sound like your case, but just in case . . .

Héhéhé, at least I know Sandvine isn't the problem here :D I am UP for a couple of hours, the two connections were from a 3.8.7 as UPs and two same 3.6.15 as leafs. The duplicates have been connected for the same time +/- 1 second (ex: 3.8.7 connected for 15:26 and the same 3.8.7 connected for 15:27) to my UP so this may be a race condition in the code. (I should have taken a screenshot, I disconected them manually before thinking about that...:rolleyes:).

Ciao

Not necessarily a bug: there may exist two distinct hosts at the same IP, trying to connect to you through the same firewall or NAT routing device...

Why do you think that these hosts are not firewalled or NAT-routed? It's possible, for NAT-routed hosts on the same LAN sharing the same Internet access, to create independant connections to the same target UltraPeer on the Net, and these two hosts on the same LAN way still be able to accept incoming connections on the same port.

These two hosts do not communicate each other to check their mutual connections attempts.

But usually the UltraPeer will disconnect one of them, à priori the most recently connected one that will have to seek for another UltraPeer...

But normally, the first Gnutella packet that a Limewire leaf node sends to an UltraPeer is a connection header specifying on which port they expect to receive incoming connections, as well as their own Gnutella servent GUID and IP address and port number within the first Gnutella message sent which should be a direct PING with TTL=1 and Hops=0 (so that this ping message will not be relayed to other hosts, but will just feed the UltraPeer pong cache, and will setup a routing path for QueryHits to forward after the leaf has relayed a Query through your UltraPeer.)

MÀJ/update here is a picture of the same UP connected two times (the ip and port are the same and the QRP filling is the also the same. They are unfirewalled because they're running UPs.) They connected at the same time to my machine (+/- 1second).http://cmt.homeip.net/documents/buggy.jpg

Took a while for catch this rare condition, but now can confirm--3.9.9 Beta (pro). Also managed to get screenshots of the tooltip info (identical). Uptime over 5 hours, and each using differing amounts of bandwidth.

Note that a firewalled node CAN BE a UltraPeer. What is really needed is to accept incoming connections on the configured port. This does not forbids firewalls or NAT routing devices.

Even in the 2 other examples shown as screenshots just above this message, it is really possible that two hosts (with distinct GUIDs) share a connection with the same visible IP, and even the same shared directories (which may be on a mounted local network shared disk).
For Gnutella, they may even be two distinct UltraPeers each one with its own set of connections. So they participate to the topology. Servents are not uniquely identified by their IP but also by their port number for incoming connections. As the first ping that is exchanged between connected host will contain this port number, they will be distinct.

I can't remember however if the two direct pongs exchanged contain the unique host GUID or just a unique GUID matching the ping request. If this is the unique host GUID (to be used in QueryHits and routing of pushes), then it should be possible to identify if two connections from the same IP belongs to the same host.

Humm je le sais, it's obvious Philippe....

There is one chance out of 50 billions that this eventuality happens .... Admit it, there are 10 millions more chances for this to be a bug and a lottery happening:rolleyes:
Possibilities are one thing (what you describe CAN happen, but can it have happened a couple of times on my computer and on the one of Stief-- no!) , but you have to look at the probabilities sometimes...

Philippe, t'es sûr que tu n'as pas un diplôme en philo? Moi je suis plus du type statistisques :)

just to clarify, I looked back at the screenshots and that host had the same IP:Port (6346). However, in another screenshot earlier the host used 6348. If it connected twice using a different IP:Port, and changed to the same later, that would explain the rarity, no?

Salut Stief, if he had port 6348, maybe he was running two instances of LW, which is possible under windows (this happened to EllisD). Anyway it is weird and LW shouldn't allow two UP connections of the same ip and port.


Here is another thing weird, an UP connected for more than two hours but it didn't even sent a QRP??? Has you can note on the shot it isn't a 0.6 normal peer either....
http://cmt.homeip.net/documents/pkoi.jpg

For some strange reasons, that I'm looking for since several months, this occurs due to an internal exception when building QRP tables. The QRP table is dropped or marked incomplete by the recipient.

Another bug is caused the first time a Shareaza node enters to a LimeWire UltraPeer with its 1MBit table (apparently there's a transient problem that causes its table not being resized before computing the intra-QRP table, and there are attempt to patch bits after the last one 65535 in the resized table.) This bug is more common, but may affect the intra QRP table that your should have received.

In your case, Et Voilà, this is probably what happens: this is a connection from UltraPeer to UltraPeer, which should join its Leaf-to-UP tables and a map of its local shared library to create a merged QRP table. If this exception occurs, the QRP table becomes resized despite is is still not complete and new patches are received from a Shareaza node connecting to the remote LimeWire.

This bug is more frequent, but I really can't understand why this can happen, given the code we have. My modified version of LimeWire detects it (attempt to patch bits number 65535..65599 in a 65536-bits QRP table), but I have still not found a reason for why such exception occurs.

Limewire 3.9.7 and later
 

I have been running 3.9.9 since I downloaded it a day or two agao. Earlier his evening, I had to reboot, and when my system came up again, 3.9.9 couldn't reconnect. Kept twitching at Quality: Poor for a couple minutes before giving up. Connections window showed only two or three connections which eventually died. I dropped back to 3.9.2 which reconnected quickly. Relaunched 3.9.9 but still no luck. Something broke after 3.9.3 but I can't tell what.

I encountered this a couple times already with 3.9.7 and 3.9.8 but dropping back to an earlier version than returning to latest beta fixed things. This time it didn't.

Did you enable "Locale Preferencing" for connections? And set it to a too high threshold in the "Advanced" options?

This new feature will not work appropriately (for now) with other locales than English, French and German, due to an insufficient installed base of users showing this locale.

Things will go better once 4.0 will be released and more largely deployed. But for now, if you have difficulties to connect with Locale Preferencing and your locale is Dutch/Nederlands, disable this option, or set it to a lower number of connections.

Locale preferencing works great for French with 2 connections set with preferencing, but for other locales it may be useful to set this threshold to a lower value.

This feature works by looking for LimeWire agents that share the same locale as you (using a "X-Locale: lc" connection header where lc is the language code.

Don't set this value too high, notably if you're running in Leaf mode; may be this option will be off by default in 4.0 for other locales than English (en) and French (fr), and may be German (de) or Spanish (es). The Locale indicator is already sent by all 3.9.x versions, even if they disable connection preferencing. This will allow setting workable thresholds later. For now it's best to be careful and not use this feature too high.

Limewire 3.9.7 and later
 

Thanks for the reply. Local preferencing was indeed enabled with the default 3. I disabled it but I was still unable to reconnect using 3.9.9.

I solved the problem this morning by deleting the file limeware.props in the .limeware directory. Some setting in it was screwing things up (although it didn't seem to effect 3.9.2, only the latest betas).

Did you keep a copy of your previous "limewire.props" file?

We could see what is needed for upgrades, or if this was caused by some weird properties which were used in a intermediate beta but not supported now (it may be important to facilitate upgrades from released versions)

What I suppose is that this may be a setting related to firewalls/NAT routers (the advanced "force IP" option no longer accepts manual input of the IP address, as LimeWire will determine now the public IP in echoes from the network with a new callback option).

Or it may be special settings used only for debugging/testing purpose. Some settings are normally only used within the automated tests project, to simulate Internet connections through local hosts only. They are not meant to be used in normal installations.

Thanks for pointing that some previous settings may not work as expected in the new version.

For your information, you should know that LimeWire integrates now a "Revert to Defaults" button in the options panel. This should help in case your custom settings get garbled and don't work. Click it and apply.

However if you have a firewall with NAT routing, you'll need to reconfigure the port number set in its port-forwarding rule, and add agains your custom shared folders, meaning that all shared files out of the default folder will be rehashed and reindexed.

Limewire has been enhanced so that file hashing will work faster than before, and with less CPU used.

Yep, tell me where to send it.

Did you keep a copy of your previous "limewire.props" file?
Why not to the bugs report address?.
If there's nothing secret in it, you may also copy/paste it here... This is a plain-text file.

limeware.props file
 

#LimeWire Properties IO Test
#LimeWire properties file
#Sun May 09 11:58:05 EST 2004
WINDOW_Y=212
BANNED_WORDS=.wma;.rm;.m4a
PORT=6348
WINDOW_X=220
CLEAR_UPLOAD=false
INSTALLED=true
USE_LOCALE_PREF=false
EXTENSIONS_TO_SEARCH_FOR=mp3;jpg;ogg
AVERAGE_UPTIME=939127
TOTAL_UPTIME=939127
MAX_UPLOAD_BYTES_PER_SEC=113
BLACK_LISTED_IP_ADDRESSES=80.11.114.38;200.56.156. 47;82.169.225.112;81.67.236.34;200.52.198.135;24.2 21.226.42;193.253.178.169;89.149.185.154;81.49.209 .167;213.13.216.171;81.208.36.89;82.104.98.80;62.1 01.126.217;213.80.33.231;80.177.223.72;64.26.167.1 69;64.26.167.135;64.26.167.175;217.81.70.47;213.13 .208.115;82.197.208.59;80.145.64.23;83.154.239.236 ;80.221.70.97;82.121.39.99;81.74.102.31;24.126.4.6 3;64.170.115.159;64.170.115.159;81.193.174.156;213 .13.218.231;43.244.149.63;203.45.215.118;208.35.94 .50;69.70.238.142;69.81.93.19;207.237.42.28;212.41 .84.217;213.58.88.181;81.193.174.170;209.6.154.12; 213.58.88.58;80.108.60.239;200.142.186.71;213.58.8 8.196;213.66.98.167;81.57.241.82;69.192.144.10;65. 66.22.175;213.118.10.70;82.225.7.6;138.88.186.247; 213.23.143.249;213.84.21.47;66.27.138.153;200.119. 43.109;81.251.229.118;209.88.131.25;212.41.72.175; 81.51.50.244;82.66.184.188;201.8.6.137;200.207.190 .238;80.202.32.126;216.58.75.21;213.156.52.121;65. 6.160.211;82.48.203.78;138.231.75.148;194.183.7.22 6;213.84.141.22;200.149.26.70;24.203.59.23
COUNTRY=
FREELOADER_FILES=100
SHOW_TOTD=false
PROXY_HOST=www-cache.demon.nl
UPLOADS_PER_PERSON=1
CONNECTION_SPEED=350
LAST_EXPIRE_TIME=1083527005240
DIRECTORY_FOR_SAVING_FILES=E\:\\cb\\mp3
MAX_DOWNLOAD_BYTES_PER_SEC=213
CONNECTION_TYPE=1
EVER_SUPERNODE_CAPABLE=true
FREELOADER_ALLOWED=10
MAX_SIM_DOWNLOAD=12
DIRECTORIES_TO_SEARCH_FOR_FILES=e\:\\cb\\mp3
LAST_GWEBCACHE_FETCH_TIME=1083527017110
EVER_ACCEPTED_INCOMING=true
CLIENT_ID=621FF7AA6D0AF415FF2CE524971F0800
THEME_DIR=C\:\\JAVA142\\.limewire\\themes\\limewir ePro_theme
PLAYER_ENABLED=false
INCOMPLETE_PURGE_TIME=30
PARALLEL_SEARCH=10
PROXY_PORT=8080
CONNECTION_VIEW_ENABLED=true

Maybe the large number of black-listed IP numbers caused a problem... if you are wondering, I am sharing 4,5k files, and regularly get leachers trying to d/l +100 a time and I shut them down by adding them to the list, but maybe this isn't necessary...

Well I wonder why you blacklist those IPs. If they are dynamic IPs assigned by ISP to some users, their validatity will be shortlived before they get reassigned to another user...
It's quite uncommon to have these many IPs, but does not explain why you've got problems to connect.

But I see something interesting:
PROXY_HOST=www-cache.demon.nl
are you sure that this external proxy works as expected?
This may prevent you of performing requests to Gwebcaches, as this proxy may cache their data for too long (so that the IPs that get returned get too old).

I'm not sure you need such external proxy. The proxy settings are just there for those that absolutely require passing through a HTTP proxy to get connected to the Internet. It won't have any impact on your performance, but will just worsen your experience as GWebcache requests and replies should not be cached in proxies...

If Limewire works without proxy settings, then don't use such proxy with LimeWire... Your only interest would be to let this proxy enhance ("accelerate") your web browsing, as the web should be mostly static. But if this proxy has too long caching timeout, it will negatively impact your performance as Gwebcaches return non static data.

I switched off the HTTP proxy cache setting; I was just experimenting anyway. Apparently the entry is still listed even if proxy cache is off. I noticed it also interferes with browsing remote hosts.

Ok, henceforth I will not add IPs to the black list and let the anti-"greedy servent" routines handle leechers.

Otherwise, 3.9.9 seems excellent: loads quickly, searches are fast , and generally seems quite stable. I haven't used any other other P2P packages so I can't really compare, but LimeWire 4 looks like a winner.

question about search results
 

In the search results window, why are some IP numbers listed in red and others in black? I couldn't find an explanation in the userguide on Limeware.com

This is explained in the FAQ. Red hosts are either firewalled or NAT-routed without port-forwarding.

This means that you can't connect directly to them; you can however download from them as Limewire sill send back a "PUSH" request along the same path from which the Query Result was received.

If that host has not disconnected from that path through which it sent its result, then it should receive the PUSH message, and then will connect itself to the downloader (you) using a "GIV" connection. Then your servent will be able to send its download request to the firewalled servent, now connected with you.

LimeWire has increased a lot the reliability of PUSH:
- first, it uses a "High-Degree/Low-TTL" topology that allows reducing the routing path between querying downloaders and replying uoloaders.
- second, PUSH messages can now traverse the cloud and get directly to the UltraPeer where the firewalled leaf node is currently connected.

A host is detected as "firewalled" (shown in red), if its IP address (indicated in its QueryHits) is local only (unreachable via Internet) for example 10.*.*.*, 172.16.*.* to 172.31.*.*, 192.168.*.* or other non routable IP addresses. Or if the replying host indicates this status in its QueryHits.

A few hosts are also firewalled but not detected like this. They are shown in black, but any attempt to connect directly to them may not give a reply or may timeout. In that case LimeWire will retry by sending a routed PUSH back to that servent.

Note that firewalled servents cannot download directly from other firewalled servents with this method.

However LimeWire implements now "Push Proxies", where an intermediate non-firewalled servent acts to relay the push and the transfer. Currently, push proxies are supported by UltraPeers, but this may change in the future to also allow non-firewalled leaf nodes acting as push proxies.

Limewire has just announced publicly that 4.0 should be released around Tuesday May 18. There has been so much improvements and bugs tests that releasing 4.0 will definitely boost the network. The Lime crew is preparing a feature list showing the many improvements that occured.

Last year most work was within the core protocol and the GUI was not enhanced a lot. 4.0 now gives more immediately visible changes for users. The core engine is still being worked on very actively to improve its speed or increse its reliability. The new anti-corruption THEX support will certainly improve swarmed downloads for better download success. Stay tuned... You should see the annoucement by an alert in your servent when it is released and starts being deployed (note that LimeWire versions can be downloaded very fast from Gnutella, with LimeWire itself, as the installer adds itself to the list of shared files).

Cool! I keep hoping LW will implement some kind of security so they could trust their Pro versions to be downloaded this way too.

btw--thanks guys for the questions and detailed answers. I'm reading along and appreciating the clarifications.

Until now, this was the SHA1 file content signature that allowed detecting malicious/corrupted/modified versions.
Now, starting Limewire 3.9.8, THEX data is also used so that corruption can be detected long before the end of the download.

LimeWire downloadable versions are found directly from Gnutella using signed queryhits, where the signature comes from a secure strong encryption key owned only by Limewire, but whose decryption key is publicly announced within the LimeWire released code. See for example what you have in your "update.ver" file. It contains some XML and that signature from your current version, and it is compared with incoming update.ver which may also contain some messages to display in the dialog box.

For now, this has just been used to indicate that a new version was available, but soon you you be able to download directly from that dialog instead of being directed to the LimeWire download site.

But already today, you can seek for LimeWire version by searching for "LimeWire" in a application search. When Limewire will be released, the main download site may become slower for a few days, but you'll be able to download the new version by searching from it in LimeWire directly, as newly installed versions will also be shared immediately.

Hmmm--Interesting. I'll try using the same installer for the different user accounts and machines on my LAN (I hadn't tried this since - - LW 2.7.13?) for the next release, and save some bandwidth.

btw--a search for "LimeWire" on 3.9.9 Pro just now only returns images from within package contents

[edit--search type was intended to be "Any Type", which returns 1037 results; "Programs" found 3 results]

I said you to search for Programs.
LimeWire shares its "LimeWireWin.exe" file with an extension specifying its version.
It's quite useful to see which LimeWire version are the most widely used (however users are still free to delete the installer from their default shared directory after the installation, so not all people will share this file).
I made such a search, and I immediately got 201 replies. Most of them for the version 3.6.9.10, followed by 3.5.8 and then 3.8.5. But even the current beta 3.9.9 could be located on multiple sources.
There remains some copies of LimeWire 2.x...

Hmmm I'm confused here:confused: I thought that LW didn't share LW installers since 3.8.x for the what's new feature. I thought that searching for LW would return the what's new results.... Philippe or Sam can you enlighten me SVP?

Merci

Edit: I think I'm right on track, I've just done a limewire search in any type and it gave results as the what's new feature... Philippe what are you talking about :confused:

Edit2: ah Phil responded 1 minute before... ak, ok a search in programs....

I actually don't know what is done in the "what's new" search. That's something I'll look later. But traditional searches will correctly find the copy of the installer, made by the installer itself within the default shared directory.
I just verified this in 3.9.9, and this copy is there...

Well, I tried a keyword search for programs several times, and can't see why these results are so different (the Any Kind search also only found the same programs: the other 1034 results seem to be from files with "LimeWire" in their path)

Currently, I believe only the Windows English version of LimeWire will share the installer (as LimeWireWin<version>.exe). Searching 'LimeWire' by itself gives very random results, as it will contain random files people's shared folder if that folder was a subdirectory of 'LimeWire'.

The What's New feature works by searching the network with a special kind of query that tells people to respond with the newest 3 files they have downloaded. Every time someone downloads a file, the uploader informs the downloader of the creation time, so that the creation time of a file will propogate throughout the network. Clients respond to a what's new query with the files that have newest creation time. Starting in LimeWire 3.9 betas, clients also pay attention to the kind of what's new search -- that is, an audio what's new search will make sure to return the 3 newest audio results, and a programs what's new search will make sure to return the 3 newest program results.

This feature also became applicable to other kinds of searches in LimeWire 3.9. Previously, someone could do a program search for a common name, and LimeWires would return any kind of result, despite knowing that the searcher would discard those results. Now, LimeWire will only return results that are of the same type.

Interestingly, I just now encountered this duplicate connection issue but while acting as a leaf in LimeWire 3.9.12 beta. It made 3 connections simultaneously, the same second, to the same ultrapeer at the same IP on the same port (verified by a "netstat -nt" in linux showing the same IP connected to 3 times on the same port) . During this, the quality meter was at "Excellent" and "Locale Preferencing" was disabled. This occured on a fresh load of LimeWire and it stayed connected 3 times to the same IP on the same port for a few minutes before dropping one of the duplicate connections to find another ultrapeer, but it still had one duplicate connection to the same ultrapeer up for the entire time I had limewire loaded. My O/S is SuSE Linux 9.0 and java version is 1.4.2_04.