Steps to reproduce:
1- Do a query and choose a file with one source to download. Let's call the host that contains the file, host A
2- The file starts to download.
3- After a while host A disapears (for example the user shutdowns his computer).
4- Wait until there's no sources in the sources tab.
5- A couple hours later the host A joins the network, but with a new IP address.
6- The download never resumes.
To resume the download, it's required to:
7- Search again, either the same search or search for the exact filename.
How it should behave:
The step 7 shouldn't be required.
Regards,
David Santiago
A minor correctioin
Step 7: Search again. Can be anything that yield the stuck download as a result.
Diff:
This is not a defect of gtk-gnutella, it is the way the Gnutella network works.
To mitigate the behaviour you are describing, GTKG allows people to advertise a host name (configured in the preferences), so when their IP changes, assuming their DNS entry is updated accordingly, GTKG can still find the remote host. This host name is going to be advertised in query hits, and therefore associated with the source.
GTKG peers also implement the QUEUE callback, which means that if you were downloading from a GTKG peer and your address did not change, you will get a QUEUE callback from that host when its comes back, and you will be able to learn its new IP and resume, if still interested.
Only GTKG implements these features as far as I know.
Hence when you are downloading from a host whose IP address changes, the behaviour you described above will indeed happen if the remote host is not running gtk-gnutella. If it was running gtk-gnutella, let me know because then we could have a resuming logic bug somewhere.
Meanwhile I am closing this bug report, since, as I explained, this is a behaviour implied by the design of the Gnutella protocol.
Thanks for the explanation. The other host was not running gtkg it was running shareaza.
I see... we need more gtkg hosts in the network :-)