LimeWire 2.9.0 Alpha
 

We have just released the LimeWire 2.9.0 alpha. We're calling it an "alpha" because it has so much new code that hasn't been tested on the wilds of the Gnutella network that we're going to extend the alpha/beta process slightly more than we normally would. That said, this version is loaded with new features, including:

- New "dynamic search" architecture will make Ultrapeers dynamically adjust their search based on how many results have been received. This frees up bandwidth by cutting off searches for popular content when enough results are received. For searches for rare content, it will send the search further on the network to ensure that you receive the results you're looking for.

- Indexing between Ultrapeers now allows Ultrapeers to only forward searches to their neighboring Ultrapeers when the neighboring Ultrapeers have matching content. This change should save about another 50% of network bandwidth over the old search architecture, leaving more bandwidth for rare content searches and for your downloads.

- MAGNET links. LimeWire now supports the MAGNET protocol. Using MAGNET, you can insert a link on a web site that will automatically wakeup LimeWire to search for and download the content specified in the link. In the future, this will mean that you will be able to click on a file in your library and select to e-mail a link to that file to a friend. When your friend clicks on the link, it will wakeup LimeWire and download the file directly. If you've ever had trouble e-mailing large files to your friends or associates, this will solve the problem!

- Local subnet searches -- LimeWire will now always search your local network for anyone sharing content with another LimeWIre. If you're in a dorm, on a corporate LAN, or on a wireless network at a conference, fire up your LimeWire to see what other people on the local network are sharing. The results will appear in special blue stars with the speed listed as "Ethernet." When you go to download these files, the speeds will be unmatched because the transer is happening locally.

- New LimeWire look -- new buttons, smaller icons, and a new feel make LimeWire sharper than ever.

- Improvements to the "download mesh" architecture will improve your download success rate and throughput.

We've added many more features and bug fixes, but there are so many that I can't quite keep track of them all! This version is also really a "beta" for LimeWire 3.0, which will include refined versions of all of these features. The search architecture changes in particular incorporate some of the latest ideas from the p2p research community, including more agressive use of indexing to decrease the average load on a given computer and the use of more connections between Ultrapeers to create a network less vulnerable to node leaves and joins, to save bandwidth on query hits by reducing the distance on the network they travel, and to reduce the latency of searches, so you get your results more quickly!

This is really the first installment of a series of radical improvements that promise to dramatically improve the searchability of the Gnutella network!

Thanks for everyone's support. We hope you like it. There are surely bugs with all the new code, so be patient with this version for a week or two -- we think it's features will soon impress you.

One last thing -- this won't be available for Mac 9.x and below until Monday -- our apologies for the delay.

-LimeWire Team

2 words
 

I have have been waiting for this release forever...i have 2 words thank you.:D

I did not really expect it today anymore.

whatcha mean?

I thought the release would be delayed till next monday when I did not see it earlier...

First thing I noticed was that the block host feature works great (really speeds up ease of searching)--thanks Sam and trap_jaw--and so far, no "could not move to library" message.

trap_jaw, thanks for the pointers, updates and reports. It has been reassuring to know you've been monitoring developments.

Would anyone kindly suggest some tips for the most efficient way to report bugs to bugs@limewire.com? The http://www.limewire.org/project/www/bug.html looks to be for project members, but seems like the place to start finding out what issues need more info. I guess key words are "core" or "gui," but I'm not sure about the minimum platform/OS info--Some tips on key words to snip from OSX Console entries would be appreciated.

You will still see 'couldn't move to library' errors, when you are trying to download a file with an illegal character in its name (and without sha1 hash), but the error is shown when the download is started and not when it's near finished.

Trap_Jaw,

I have been dragging my feet today on downloading 2.9. I am still kind of licking wounds from 2.8.5.

Have you tried 2.9 & if so any issues?

Norm

The ethernet connect worked very well, but then killed all my host connections on both machines. I quit both Limewires; mail client were able to reconnect several minutes later. Installation wasn't trouble free on both Macs (OS 10.2.4).

lookupd[273]: msg_send failed ((ipc/send) invalid destination port)
Quit

It's working well on Linux and Windows. Maybe there are some minor installer issues left but LimeWire itself *should* run without any major stability problems.

You mean to say that LimeWire killed your internet connection - so you weren't able to use it after the ethernet download?

That's fairly strange.

All hosts were disconnected on both machines, and the OSX mail.app couldn't connect. Both Limewires, when restarted, recovered quite nicely and resumed downloading (even before any connections were displayed!). I'm just going to try to reproduce this crash again before the others on my LAN start screaming at me.

hi stief,

what is it that you do to trigger the crash / network meltdown?

thanks.

Once I wrote a multi-threaded port scanner in java and left it running over the week-end - a few weeks later my internet connection at my dormitory was cancelled forever... Good thing I had planned to move anyway.

I wish I knew. Just tried again, but all seems fine with one to four small files.
-check mail to validate internet access in both clients
-wait for "stable" connections in LW Connections pane (>8 mins, besides self) in both clients (each shared folder only has 5 files)
-new search for "canon" [Pachelbel--it's not a popular mp3] on the G4 Mac or v.v
-download the 4 ethernet listed files
-check connections pane on the G4; Monitor pane on the G3
-check mail to confirm internet access.

btw, the speeds are great (I read the tooltip reports as estimates). The G3 reported the four 4.5MB files uploaded @236-467 KB/s; the G4 said 192-316 KB/s
The Process Viewer on the G3 did occasionally show some unusual activity--??? user with a process name in oriental-like characters. Console Log hasn't entered anything since the first crash, and the loss of connections could just be the usual.

I'll try again with some new, unhashed files later. The disable untrapeer settings are different in both, too

sorry trap_jaw--I missed your post. Yeah, and my kids aren't going to like that I can search their shared files!

cool, i'm glad it works. :)

just fyi -- you don't need 'stable' connections for the ethernet listings to work. due to some quirks in the way LimeWire handles connections, it won't let you search until you have an active connection. but technically, you don't need any connections at all -- the queries are sent directly to others on the network that have requested to listen for them.

i imagine you have the new limewire beta installed on the other computers in the network also?

Search Question
 

OK, I have 2.9 now. Its too early to make an assessment. I ll have to wait till it propogates.
But, I m wondering when LW is going to fix the inaccuracy of the search filters. For example, when u do a search of say "pink floyd" "320kbs" and you get a bunch of unrelated search results.
Thanks

BTW, did LW abandon GUESS? I heard it wasnt gonna be used anymore duie to technical reasons.

Keep up the good work.

Hello again Sam
thanks for the info on connections--makes more sense now.
Looks like my previous crash is related to my IPNet Router software, but it will take quite a while to be certain. My ISP was able to confirm that the DNS servers, the neighbourhood cable network, and my modem have run uninterrupted for the past 10 hours, yet all three of our machines suddenly couldn't connect again [hmm--LimeWire just unexpectedly quit on this machine G3/ OK on the other--lots of JVM_GetMethodIxExceptionTableEntry in the crash log. Anyone want it?]

As I was saying before being so rudely interrupted, suddenly all three machine couldn't connect, two of them showed Console entries of
lookupd[291]: DNSAgent: dns_send_query_server - send failed. Two of them were running the beta; the other wasn't. For some reason, the G3 has been trying to maintain 15 host connections (often an additional 6 or so are trying to connect); the G4 tries to keep 3 over and above the local IP. Does that make any sense to you?

IPNet Router runs on an old Mac IIci that controls the two ethernet cards. I haven't touched it for two or more years, other than to push the power button after an outage. Before I look at it, I'll have to drag out an old monitor/keyboard/ etc and see if there are some settings to play with. That's a job for next weekend, but by then 2.9.0 will probably change.

Cheers--and by the way, the autocomplete search feature is a nice touch.

hmm, if the logs aren't too large, could you post them here? (or just a few samples if they're all repetitive.)

also, this just happened once, right? it hasn't been a consistent thing?

trying to maintain 15 connections probably means the g3 is being promoted to an ultrapeer. the g4 having 3 probably means it's a leaf.

the autocomplete was surprisingly easy to add -- all the tools already existed for checking incoming searches against the library filenames/metadata. so this was just extended to store inputted searches & retrieve them when something you're typing matches. you may also notice that when you succesfully make an outgoing connection (seen in the connections tab), that ip:port will be stored in the autocomplete memory for that textbox. so if you succesfully connect to 1.2.3.4:6346, then if you happen to type in '1', it will fill it with '.2.3.4:6346'. (and the port there will override the other port-specific textbox.)

Sorry about the delay. Ironically, I just set up a temporary .Mac iDisk account to post the logs, notes, and a screen shot in its Public folder. You can access it under username "stief1". http://discussions.info.apple.com/we...UR.0@.3bb85a78 has FAQ's on accessing iDisks . P2P can be a chore!

I was able to trigger the home network locking again, only the Limewires didn't crash. I had to quit them both manually, and a few minutes later regained internet access. If the G3 thought that the speeds to the G4 made it qualify for an Ultrapeer, I'm guessing the poor little Mac IIci wasn't able to handle the shock and something there overloaded.

Adding the IP to the search box is a great idea. Now if only we could copy and paste them . . .

iDisks are webdav volumes, which probably means more to you than me. Do let me know which entries were important.
temp account: stief1@mac.com

I miss the connection changing feature. Helps to conserve bandwidth, or increase number of hits if your doing a search for a rare piece. I'm getting much fewer results because LW defaults to 3 connections... any way to raise this?

No. Although increasing the number of leaf-ultrapeer connections increases the number of search results *you* get - it reduces performances for everyone else. Once there are enough 2.9 ultrapeers out the number of results you will find should increase very much.

Just a quick update on an earlier problem. This time a single LW 2.9.0 on the G4 stopped Web, mail and gnutella access on the G3: (interrupted Acquisiton .74 downloads). I only had to quit LW to regain mail and web access.

Luckily, this didn't break my Acq. hosts, but did interrupt three active downloads.
Acq still shows uninterrupted uptimes, but the active downloads stalled, and haven't yet restarted 30 mins later (cache entries are being written, though, and new searches are giving new results).

More irony, though. This happened while getting the Limewire FAQ link for another post and I only fired up LW on the G4 to check the keystroke for Audio contextual menus (and searched for "canon" to see song results)!

No Console entires noted on the G3; G4 Console wasn't running.

Were you running as an ultrapeer while that happened?

I think I've found something but it doesn't seem to be related to ethernet downloads but to searching while you are an ultrapeer.

This is what happened: When running LimeWire in ultrapeer mode a search, when I start it, might cause all connections to be dropped. So far it appears to be some weird synchronization problem that keeps connections from being initialized properly after I started a search. Disconnecting LimeWire and connecting after several seconds solves the problem.

I'll be able to tell you more in an hour or so.

Don't know. Only had it up for a few minutes, and yesterday the G4 kept to three connections. The few files didn't show as ethernet either (I did remember to scan the IP's). If yesterday's logs are any help, feel free to grab them.

Did the search drop affect any other machines?

Thanks for the info--maybe I can stall on fiddling with IPNetRouter.

Just reproduced the bug. Yes, the G4 was trying to be an UltraPeer. No Console entries, though. I'll give up my Acq. UltraPeers (uptime >15 hrs), and see if it just affects the browser on the G3.

I'm not able to reproduce the bug reliably, so I can't tell what causes it. - It doesn't seem to be too bad on linux and it didn't cause any weird network activity either.

The problem went away after a minute or so...

Yeah, I tried again a few times with and w/o Acq.
Couldn't reproduce the same behaviour when Acq G3 wasn't running: Instead, Limewire G4 as UltraPeer crashed after Acq started up (logged--130+threads; no Console), but no web or mail loss--I tried. Restarted Limewire while Acq still running, Limewire went into leaf mode and I haven't been able to make more problems since. Quit Acq on the G3, and tried twice more to get Limewire in Ultrapeer mode--it's behaving.

Looks like two clients trying to hold down quite a few connections is needed first for me. Explorer was running on both machines too. Oh well, another weekend not wasted.

use limewire on the g3 & g4. i dunno what could be going wrong with acquisition, because i don't know how he's modified certain things. i assume in no instance you had both programs running on a single machine, because that is just asking for a crash.

if the problem's related to acquisition, i'm not sure how much of a help i can be.

Right. I'll see if I can reproduce it again later this week if it's still unsolved.

Yesterday was all Limewire--I just ran Acq last night to get a sense of the differences and was pleased with the stability of the connections, so let it run all day today on the G3 (my main machine). As I said, it was a fluke I triggered today's crash. Someone asked a question about Limewire, so I started it up on my wife's G4, and that triggered the discussion above. I might try running them together for personal curiousity, but I fully expect that to bring trouble.

Don't worry about helping me--afisk did the right thing by posting this release as alpha. If these bugs help you and other developers come up with better Mac clients, I don't mind testing what I can. I do appreciate the expertise you and trap_jaw freely offer.

Were you able to get hold of the logs? If the iDisk isn't efficient, just email me at stief1@mac.com. I'll dump today's limewire.crash.log in there too.

Cheers, and good luck with this week's developments.