very true!

but how the 3 guys at Limewire manage to support (or try to support) so many versions over so many platforms is beyond me.

do they ever sleep?

anyone want to run a sweepstake on Limewire's Pizza and Jolt Cola annual budget?

maybe they should make Limewire "Pizzaware" and get sponsorship from Pizza Hut.

Good point. Maybe they need to stick to Windows until Apple gives them better Java to work with.
I went ahead and upgraded to the Java Preview Release 1.4.1. It stopped the Java crashes I was getting before with Acquisition. Running 0.74 now. Personally I'd like to see more of the LW interface elements ie stats etc. But it'll do for now.

Acquisition uses the open-source LimeWire code. It simply added a native GUI for OSX. So all the testing and developing for Acquisitions Gnutella features is done by LimeWire. If the guys at Acquisition did any substantial changes to the core, they decided not to share it with the LimeWire developers.

The Acquisition sourcecode can be found here:

http://sourceforge.net/projects/aquisition

i have no idea what he's done differently but it works!

i suggest you get in contact directly

I looked at the source code, it's almost the same.

Here's a list of changes.

* Acquisition uses java.util.* instead of com.sun.java.util.collection.* (probably improving performance. LimeWire uses the other package for MacOS compatibility)
* Added Acquisition to the list of trusted vendors
* Some fixes for possible nullpointers he might have encountered
* removed chat support
* makes four times as many requeries as regular LimeWire (definitely harmful for the network - I'm going to submit a patch to LimeWire making LimeWire's clustering effective against Acquisition hosts).
Ooops, I see now, that it doesn't requery that often. The requeries were only sent every ten minutes in some previous version but the code has been commented out....
* removed unit tests (not relevant for end users)
* made it impossible for dumb users to share incomplete directory
* added error messages for debugging
* added some statistics
* some changes to integrate the GUI part of the searching
* reduced default upload speed
* removed media player
* modified interface of HTTPDownloader to stop a transfer at any time
* sends a requery everytime the user hits the resume button (only resulting in a few megabytes in traffic for the network every time the user hits that button - I mean there IS a reason queries don't return many results, it's that ultrapeers are simply overloaded!)
But that is right.
* doesn't use http1.1 in downloads anymore, reducing effectiveness of download meshes but users don't complain anymore that their clients download files in 100kb chunks.
* disabled update manager
* removed cross-plattform compatibility

That's about it. The only possible explanation for a better performance is that he sends 4.5+ times as many requeries (if LimeWire did that, the network would collapse - and I'm seriously pissed Acquisition uses such cheap QTraxMax-like tricks to improve performance for its users while reducing performance for all the others).
You got to understand, - it was late. ACQUISITION DOES NOT SEND that many requeries, - Sorry...
trap_jaw

Maybe Acquisition's policy not to download in 100KB chunks improves the subjective download experience but the download mesh (every client who has a file keeps track of all other clients with the same file) doesn't work as good without chunked downloads. With the new LimeWire downloads, the downloader is regularly informed about all other locations, so swarming should work a lot better.

well, excuse me!

Trap-Jaw,

I believe that have have honestly checked the code, and [except for the 10 versus 45 minute requery mixup] the diferences are what you mention, but nothing you've said explains why LimeWire 2.8.x over the course of one month did not download a single large file for me, not even when I left it running 24 hours a day, while Acquisition downloaded three on the first night I tried it! LimeWire loses all connections it makes within seven minutes; Acquisition retains the connections. LimeWire never reconnects to hosts after the initial failure; Acquisition does reconnect when possible.

Trap-Jaw, I have 30 years experience in software development --OK, not internet software. My "customers" were manufacturing machines. But, the same rules apply: the only way to test software is in the real world: run it and see what happens. If it doesn't do what it was intended to do, then the software is broken, I don't care how pretty the code is. If the user wants a 0.05mm tolerance on his cut and you give him 0.5mm, he's not going to be happy.

I'm not happy with LimeWire at the moment. It is not doing what I want it to do. I invested a month of my time trying to get it to work. I participated in this forum; I ran tests; I experimented. Nothing helped.

You guys keep up the good work. The minute that's a new version worth testing, I'll be back. Until then, I'm using Acquisition.

Janet

The policy to disable HTTP 1.1 downloading was made back in October, long before the LimeWire HTTP 1.1 code in CVS had hit the main release. At that time, most chunked downloads would stall after the first chunk had come in. Perhaps now that download mesh enabled clients are more pervasive, chunking works better. I will experiment with this and see if I should change this policy. But, based on jannuss's subjective experience, it sounds as though chunked downloads are still stalling.

And thanks for acknowledging your error regarding Acquisition's requeries. I have every desire to make Acquisition as good a network citizen as possible.

Dave @ xlife

not sure i understand all this techno dick swinging but as a user here are the facts:

on my configuration (at the start of this thread):

- Limewire doesn't work
- Acquisition does work

go figure...