Can you tell me if gnucleus has a proper resume download feature such as Audiogalaxy?

It's really annoying, and time consuming, to get almost through a download only to have it time out or something else happen to abort the download and then to have to start again right from the beginning. At least with Audiogalaxy I don't have to worry about reconnections etc.

I recently installed Limewire v1.7 which is supposed to have this feature but I haven't got it working yet (following the faq just starts a new download).

I've downloaded gnucleus but haven't installed yet as I'd like to be sure it will offer more than Limewire or Bearshare.

Also, is there a screenshot I can access to see what it looks like, I haven't been able to find one as yet?

Functionally it is far better than Limewire and Bearshare.
But I am not totally satisfied with the resume download feature. When starting Gnucleus again after losing connections etc. and you want to resume downloads, you will have to let the client search the net for the correct files. If it finds one which is available it tries to connect and resume. Unfortunately it works perhaps with only 20-25% success.

Xolox seems to have one of the best resume features out there. You can set it and forget it (pardon the cliche).
:-)

Gnucleus resumes partials very reliably.

It uses a 4096 byte, roll-back buffer to ensure that the file your resuming is positively the same file you already have. No matter what server you resume from.

> If it finds one which is available it tries to connect and resume. Unfortunately it works perhaps with only 20-25% success.



Note the IP of the D/L and try to re-connect directly to it when you get back on-line...



The 4.kb rollback is nice - I have GetRight do the same..


For me the question is whether the same or a identical file exists (same as the original Gnutella .56) which appears to use a MD5 fingerprint to see (?)

I don't see more than 3 to 5 hosts with the same file (I look for rare songs) so I place my chances on completing the D/L from the (usually) single host, as far as other hosts completing it that depends on them having the same file - most of my MP3's I makee myself using the old L3ENC, then the Radium ACM, now LAME VBR, plus some Liquid Audio files (LQT's) and even MPEG4-AAC (AAC)

No one would have a copy of these - many times there is no other host to find it on (same file for resuming)


When I find a really important song I'll disconnect from other hosts and let the D/L complete at full speed.

Generally it seems the faster you get the file the more likely it will complete. Also many people seem to be college students who stay on-line for a few hours then shut down for the nite (some do stay on all night - even days at a time) You can see by "tracking" IP's (making notes of them and re-connecting at different times keeping in mind that they may reject your connection attempt but connecting at all even for a second shows they're still there) This is in contrast to a stealth setup where you don't appear to be there at all to anyone other than allowed traffic and route through anonymous proxies so your own IP isn't left scattered about in other people's host caches. Using push requests to serve files either only to the people you are directly connected to (a network within a network - the port is the same but the IP is non-internet) or supply an IP that makes the rounds but people can still only D/L from you by connecting directly to you first.

The other option is you are connected to the GnutellaNet and the D/L request makes it's way back to you through other host's search data (the typical method)


People are comparing aspects of a server-based file sharing service (fast searches, well sorted hosts/song lists, other ways of matching files) to a true P2P system, in a true P2P system *you take your chances* when it comes to :

1.) finding songs
2.) finding more than 1 host with the same track
3.) push requests getting back to the host
4.) being able to resume/complete a file when the host may be off-line, no other host has the exact same song, or no other host that does have it will allow you to D/L


These elements have a much larger "wildcard" factor for true P2P...

I haven't tried Xolox yet, but I think Gnucleus has the best resume of any gnutella peer I have used so far. Like you I could never get LimeWire to work reliably with this, but with Gnucleus, if you can find the file again, you can resume it. It's a very important feature to me since I share and download big files (about 120 meg on average). The chances of getting it all from one host in one session are usually slim.

Really I like the re-searching. For me trying the same IP often doesn't work. Often a host will go offline only to come back with a different IP address, and firewalled "pushable" hosts can't be connected to directly at all (yet they often have the fastest transfers if you can get to em').

One trick is Gnucleus lets you redefine the search terms before re-searching (right-click over the file name in the "partials" tab).

By default it uses the original search terms, but if they were overly broad (like "Divx" or "mp3"), you'll have trouble finding the file again. Instead try entering a key part of the filename - the results will be much better.

Exactly.

I've improved downloading from bearshare, and fixed more push issues.

Ive tested push and d/ls with the biggest clients and patched any problems.

Expect a 1.4.2 release friday night (9/28).

Thanks to Swabby and everyone else for the input.

A couple more questions if I may.

Is there any problem with running Gnucleus and say xolox and/or Bearshare on the same machine?

Does gnucleus add any DLL's to the system during install?

Swabby, Gnucleus should remember the old IP it was downloading from. If not for all files for files over a certian size, say 50MB. People sharing larger files are less likely to be on dynamic IPs and therefor can often be reached at the same IP on a later day.

Yep it should, needs to be programmed though. I think there are some guys working on a new transfer window for me that incorporates this.