LimeWire 3.6.0 Beta
 

We've released the beta version of LimeWire 3.6.0. As usual, the free version is available at:

http://www.limewire.com/english/content/beta.shtml

and the pro version is available from your pro download page.

The major improvement in 3.6.0 is the use of "out-of-band" replies to your searches. This is pretty technical change, so I'll describe it in some detail. Here's how query responses worked prior to 3.6.0:

When you sent out a query on Gnutella, anyone who received the query and had responses would send those responses back along the same route that it came, i.e. it would send it back through every LimeWire that had originally forwarded the query. This is inefficient because the LimeWires that would route the responses could be on opposite sides of the planet, forcing the LimeWire network to do much more work than necessary to get back to the querier, even circling the globe multiple times!

With LimeWire 3.6.0, however, those responses will be sent directly back to the querier instead of being sent along such an inefficient route. This allows those queries to be sent back by extremely high performing IP routers that will always clobber LimeWire's network topology in terms of performance.

The result of all of this is that the responses will get back to you much more quickly. You will especially see a speed improvement with queries for rare content because these queries travel further out on the network to get their results than queries for popular content. As a result, they have a greater distance (or number of "hops") to travel to get back to the original querier.

LimeWire 3.6.0 also adds a new "tip of the day" feature that cycles through helpful tips on using LimeWire. 3.6.0 also fixes a number of bugs from earlier versions.

Thanks for everyone's help testing the beta.

-LimeWire Team

Wahou... results are popping FAST and MORE hits are coming for rare content! Great, searches speed are now on par with Kazaa, the used to be fastest network out there! Bravo et merci!

Now time for an old bug report: I can't browse ACQX users from the upload window, but I can from the download window, so I assume this is a LW bug that as been there, well for ever... Correct that please... And test browse host with bearshare and shareaza in upload window as well. Merci

Continuez les gars!

Quick question - does a client have to be acting as an ultrapeer before it can be the receipient of out-of-band replies ?

>Quick question - does a client have to be acting as an ultrapeer before it can be the receipient of out-of-band replies ?

No. It just has to demonstrate (through use of automatic tests LimeWire performs) that it can recieve unsolicated UDP and TCP packets from users outside of its subnet.

Cheers. Will access to ports 6346-6348 through the firewall suffice or is a more sweeping range required ?

Adam and Sam--What did you do!!!!! My uploads are just flying--running as an UP and seeing 4 uploads ALL over 20KBp/s! This is great---I'm even connected through the LAN---I've never seen such success! :D :D :D

Please tell me you did something to make the uploads fly--the OOB stats are quickly climbing. I also updated the system software to 10.28 today. Or, is it time to call my ISP and find out if they did something?

Re: LimeWire 3.6.0 Beta - Text Color Problem
 

One problem...If you are using the black theme with LimeWire, the Tip of the Days can't be read at all since the text color matches the window's background color. The only thing that can be read are hyperlinks. So on my first load, I saw; "Did you know? LimeWire Pro!" (which was, in a way, quite humorous) and nothing else in the Tip of the Day dialog.

The color problem occurs in the Help -> About dialog in LimeWire, also. At the top of the scrollable About window where it shows LimeWire's version and URL, that text also cannot be seen when using the Black theme since it uses black text on a black background when I do use it.

Also, on load, you can't even see how many files you are sharing at the bottom left of the LimeWire window when using the Black theme, since there, it also uses black text on a black background. The files shared number shows up properly with the Black theme only after I do a library refresh (even when I made no changes to my library) and then it uses proper text color.

>Will access to ports 6346-6348 through the firewall suffice or is a more sweeping range required ?

If you're using a firewall / router, it must be set to forward UDP packets as well as TCP packets on the normal gnutella ports.

At home, for example, I have port 6666 set up to forward to 6666 to my computer, and have LimeWire set to listen on port 6666 as well as 'Forced IP' checked with 6666 as the port.

If I had the firewall set up to listen to 6666 and forward to 6346, I'd have LimeWire listen to port 6346 and have 'Forced IP' checked with 6666 as the port.

re stief: I don't recall anything specific changing with uploads, although we do tinker with code ... we'll take the credit, but I'd suggest calling up and thanking your ISP also.

re limenut: Just fixed that. Thanks for the heads up.

OS 10.2.8 update is pulled--serious bug disabling direct ethernet connections.

http://docs.info.apple.com/article.html?artnum=107669

LOL! The ISP said the great upload speeds are not because of them, so that left the OSX update!

I installed the 3.6.0-Pro Beta and disabled the installer option for Load LW At Startup. The installer correctly left my Windows Startup folder alone. Then, while reviewing Tools -> Options -> Advanced -> System Startup, I saw that this option was marked enabled.

So,
1. The installer needs to modify the setting in Tools/Options/etc.
2. The option in Tools/Options/etc needs to work when it's enabled.

hi sdsalsero--glad to see you're still around. I was just thinking of you this morning when a bunch of downloads completed during the night. I was surprised and pleased--Looked like babysitting LW is improved. You seeing an improvement there too? Cheers

sdalsero,

You're 100% correct. Unfortunately, there's not much we can do about it. The installer does not have access to the same system properties that LimeWire does, due to the Installer being a native program and LimeWire being a Java program.

The installer, when choosing whether or not to load LimeWire on system startup will either place the link in the startup folder or not.

LimeWire, when choosing whether or not to load on system startup, with either allow the link that was placed in the startup folder to continue loading or not.

This means that if you've chosen to not load it on startup during the installer, LimeWire itself will still think it's allowed to be loaded on startup even though nothing will be loaded on startup. There's no easy way to have LimeWire place a new icon in the startup folder if one does not already exist (or remove it from the startup folder).

Common problem.

The usual workaround is to place an entry in startup that invokes a small script (or in this case a java program) that checks the relevant config space and runs the app proper if appropriate.

sberlin,
Thanks for the reply. I see the problem now!

Perhaps the Startup icon could be labeled, "LW checker" (or "pre-start" or something?!), to somehow differentiate it from a traditional loader.

As for the Windows installer, the LW java app is storing it's settings in the PREFS file so I don't see why the installer couldn't just modify that. Perhaps that last screen of installer options could clarify that the Startup icon does NOT automatically load LW, but simply checks to see if you've requested that it load (in PREFS). If that seems like too much info, maybe a "More Info" button could be added to that screen?

I know, I know, this is largely a cosmetic issue right now but I certainly hope it can be resolved somehow since it detracts from the "finish" of the product.

3.6 is great. I've been ultrapeer for a day on my imac 450 g3 and cpu usage is between 5 and 20%, while bandwith up and down is under 5Kbytes/sec (means at 4KB/s), uploads are unaffected.

Now I have a NEW feature request for searches:
An option in the search panel to find files bigger than 1 meg (or user defined) in all types, documents, programs and maybe video searches. Why? Because dynamic seraches find easily 160 files for some type of searches, but often 140 out of 160 results are tiny files like readme.txt which 99% of the time I don't even look at (I'm sorting files by size). It is becoming more difficult to find big files because of that (small are easier to find and spread, thus replacing the diversity of big files....). En résumé, rare files might be even harder to find. It might not be a problem to overcome that increasing problem with leaf guidance you have implemented.

Merci de votre attention.

sdalsero:

The problem is precisely that the installer does not know where the limewire.props files will be or is. Java has a different method for finding the home directory on each flavour of windows, and the installer, not written in Java, won't know exactly where it's going to find the file.

et voila:

That's an interesting idea. With the rollout of out-of-band queries, we introduced a feature that would allow something like this to work, but only at search time (it couldn't be dynamically adjusted AND allow more results, although it could be dynamically adjusted to remove extraneous results perhaps).

Sam, haven't you implemented the leaf guidance of bearshare? I though it was. Or are you talking at the search level (ie no protocol variable to define size of files)? Anyway, I think many users would like that feature (including me). An other variation (at the interface level this time, but less powerful as it don't increase the number of big files found) of that option is a size slider that you move to the right to show files in your search that are bigger than... (a kind of a search filter, it might be difficult to implement in java, but many P2P on os x use this).

Merci

Better control over searches would be good. If the first row of the results pane could be search entry boxes (as in Filemaker Pro), this would save screen space and allow the user to set which terms (like size, kind and bitrate) to use, depending on the columns chosen to display search results
Are 'NOT', '>', '<' terms/character likely?

btw--LW is returning search results that seem to be matching path info or perhaps package contents. (a search for "LimeWire" should show this)

Yes, we did implement leaf guidance compatible with BearShare's. The reason that the guidance can't change after the initial search, though, is because the chances are that we already sent a few guidance messages with a higher value, telling the Ultrapeer to shut off the dynamic query. Sending a subsequent message with a lower value will have no effect.

We do plan on implementing some slider-type filters at some point. Expect pretty changes. :)