gtk-gnutella-devel Digest, Vol 28, Issue 2
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 28, Issue 2
by gtk-gnutella-devel-request
::
Rate this Message:
Send gtk-gnutella-devel mailing list submissions to
gtk-gnutella-devel@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel or, via email, send a message with subject or body 'help' to gtk-gnutella-devel-request@... You can reach the person managing the list at gtk-gnutella-devel-owner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of gtk-gnutella-devel digest..." Today's Topics: 1. Re: Version 0.96.6 stable has been released (Larry Nieves) 2. Re: Version 0.96.6 stable has been released (Christian Biere) 3. Re: Version 0.96.6 stable has been released (Christian Biere) 4. Re: Version 0.96.6 stable has been released (Larry Nieves) 5. Re: Version 0.96.6 stable has been released (Christian Biere) 6. Re: Version 0.96.6 stable has been released (Raphael Manfredi) ---------------------------------------------------------------------- Message: 1 Date: Thu, 2 Apr 2009 10:08:27 +0200 From: Larry Nieves <lanieves@...> Subject: Re: [gtk-gnutella-devel] Version 0.96.6 stable has been released To: gtk-gnutella-devel@... Message-ID: <20090402080827.GD29085@...> Content-Type: text/plain; charset="utf-8" Congratulations to all who have worked to make this release possible. Having said that, I have three questions: 1.- When will GTKG reach version 1.0? If this has beed discussed before, please point me in the right direction and I will go and read that discussion. 2.- If GTKG is not publishing data to the DHT how are we supposed to download from the provided magnet: link? 3.- This is probably related to the previous question: How long a time would it be considered wise in order to label a magnet: download as failed completely? I ask this because I'm trying to download the tarball following the provided magnet: link (just to try the magnet: functionality) and after more than one hour, there are still no sources. I'm currently connected to 28 Ultranodes, 2 of which are GTKG (although one of these is running 0.96.4). I'm running r16308 and have, of course, DHT enabled. On Wed, Apr 01, 2009 at 11:54:23PM +0200, Raphael Manfredi wrote: > Dear Gnutella fans, > > Version 0.96.6 stable has been released on sourceforge. You may get it at: > > http://downloads.sourceforge.net/gtk-gnutella/gtk-gnutella-0.96.6.tar.bz2 > > You can also download this release from Gnutella using this link: > > magnet:?xt=urn:sha1:GGKBP2G6CBFTHEJ6BCQKV3EMB4RKMEU5&dn=gtk-gnutella-0.96.6.tar.bz2 > > IMPORTANT -- Larry Alex?nder Nieves Colmen?rez <lanieves@...> El Liberal Venezolano http://liberal-venezolano.net/blog/ GPG Public Key: 0x1525843C Key Fingerprint = 76D0 2DA1 ADA8 11EF 661B FEE2 923C 050F 1525 843C gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 0x1525843C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature ------------------------------ Message: 2 Date: Thu, 2 Apr 2009 12:22:14 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Version 0.96.6 stable has been released To: gtk-gnutella-devel@... Message-ID: <20090402102214.GA11053@...> Content-Type: text/plain; charset=utf-8 Larry Nieves wrote: > Having said that, I have three questions: > > 1.- When will GTKG reach version 1.0? If this has beed discussed before, > please point me in the right direction and I will go and read that > discussion. The idea that 1.0 is reserved for a feature-complete release. It's a rather idealistic approach. Releases are not frequent and are made out of boredom. If there's a release, people should really update and bug their package distributions, even if the version number seems to imply just minor changes. The changes are always significant albeit most of that happens under the hood and is invisible if you're just looking for changes in the GUI. > 2.- If GTKG is not publishing data to the DHT how are we supposed to > download from the provided magnet: link? I wondered myself. Maybe Raphael has a modified version of gtk-gnutella that already supports publishing. Otherwise, if nobody using LimeWire or FrostWire shares the file, it won't be found through the DHT for now. > 3.- This is probably related to the previous question: How long a time > would it be considered wise in order to label a magnet: download as > failed completely? I ask this because I'm trying to download the tarball > following the provided magnet: link (just to try the magnet: > functionality) and after more than one hour, there are still no sources. > I'm currently connected to 28 Ultranodes, 2 of which are GTKG (although > one of these is running 0.96.4). Just to see the DHT feature in action: Bitzi provides sourceless magnets. If you enabled the DHT, look at http://bitzi.com/ for speeches by Martin Luther King as these should be shared by many DHT-publishing peers, one would be enough. Likewise most other popular files should work as well. Shameless plug: See contrib/bitzify in the SVN repository for submitting metadata of your shared files to Bitzi. Bitcollider works, too, of course. The DHT feature is rather a preview in the current release. There are no GUI controls to inspect the DHT status or configure it. You might want to set dht_debug or dht_lookup_debug to some value above 1-20 to have at least some information on the standard error output respectively your log file. There's diagnostic output showing when DHT lookups are performed, whether they succeeded or failed etc. gtk-gnutella tries one DHT lookup per hour for each orphaned (sourceless) download. I believe a DHT lookup finishes in about a minute. -- Christian ------------------------------ Message: 3 Date: Thu, 2 Apr 2009 12:27:39 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Version 0.96.6 stable has been released To: gtk-gnutella-devel@... Message-ID: <20090402102738.GC11053@...> Content-Type: text/plain; charset=utf-8 Some corrections. Christian Biere wrote: > Larry Nieves wrote: > > 1.- When will GTKG reach version 1.0? > The idea [IS] that 1.0 is reserved for a feature-complete release. It's a ^^^^ > Releases are not frequent and are [NOT!] made out of boredom. ^^^^^^ -- Christian ------------------------------ Message: 4 Date: Thu, 2 Apr 2009 13:13:38 +0200 From: Larry Nieves <lanieves@...> Subject: Re: [gtk-gnutella-devel] Version 0.96.6 stable has been released To: gtk-gnutella-devel@... Message-ID: <20090402111338.GE29085@...> Content-Type: text/plain; charset="utf-8" On Thu, Apr 02, 2009 at 12:22:14PM +0200, Christian Biere wrote: > > 2.- If GTKG is not publishing data to the DHT how are we supposed to > > download from the provided magnet: link? > > I wondered myself. Maybe Raphael has a modified version of gtk-gnutella > that already supports publishing. Otherwise, if nobody using LimeWire > or FrostWire shares the file, it won't be found through the DHT for now. Good to know I was not the only one wondering about that :) Anyway, you get a faster result just by doing a normal search for "gtk-gnutella" and now I see that doing that triggers the "orphaned" magnet: download, which is cool because I didn't have to double click on the search results. > The DHT feature is rather a preview in the current release. There are no GUI > controls to inspect the DHT status or configure it. You might want to set > dht_debug or dht_lookup_debug to some value above 1-20 to have at least some > information on the standard error output respectively your log file. There's > diagnostic output showing when DHT lookups are performed, whether they > succeeded or failed etc. Yes, I have dht_debug = 1 and I see one peculiar thing: ALL the DHT FETCH result in "not found". I have three days worth of debug output and absolutely all DHT FETCH are "not found", whether they were for "ALOC", "PROX" or "BTAL" (?). I don't know if this is normal, but it sure looks suspicious to me (which may be due to my ignorance of the DHT's inner workings). On the other hand, searching for this file: http://bitzi.com/lookup/YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C (MLK speech, as you suggested) does produce very quick results: ----- DEBUG LOG ----- 09-04-02 12:54:56 (MESSAGE): DHT LOOKUP[906] ending value fetch with 0 pending FIND_VALUE RPCs 09-04-02 12:54:56 (MESSAGE): DHT LOOKUP[906] terminating value lookup (ALOC) for c344a3ce02b06716a515e59a0277524d202cbba2 with 15 values 09-04-02 12:54:56 (MESSAGE): DHT LOOKUP[906] 3.683538 secs, hops=2, in=5673 bytes, out=2106 bytes 09-04-02 12:54:56 (MESSAGE): DHT ALOC lookup for YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C returned 15 values ----- END DEBUG LOG ----- It doesn't happen this way if I simply search for the urn:sha1: value. -- Larry Alex?nder Nieves Colmen?rez <lanieves@...> El Liberal Venezolano http://liberal-venezolano.net/blog/ GPG Public Key: 0x1525843C Key Fingerprint = 76D0 2DA1 ADA8 11EF 661B FEE2 923C 050F 1525 843C gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 0x1525843C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature ------------------------------ Message: 5 Date: Thu, 2 Apr 2009 14:12:47 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Version 0.96.6 stable has been released To: gtk-gnutella-devel@... Message-ID: <20090402121247.GE11053@...> Content-Type: text/plain; charset=utf-8 Larry Nieves wrote: > On Thu, Apr 02, 2009 at 12:22:14PM +0200, Christian Biere wrote: > > > 2.- If GTKG is not publishing data to the DHT how are we supposed to > > > download from the provided magnet: link? > > > > I wondered myself. Maybe Raphael has a modified version of gtk-gnutella > > that already supports publishing. Otherwise, if nobody using LimeWire > > or FrostWire shares the file, it won't be found through the DHT for now. > > Good to know I was not the only one wondering about that :) Anyway, you > get a faster result just by doing a normal search for "gtk-gnutella" and > now I see that doing that triggers the "orphaned" magnet: download, > which is cool because I didn't have to double click on the search > results. Yes, for popular files that are shared by many peers, it can be useful to use a combined magnet that provides a "keyword topic", too. So if you append "&kt=gtk-gnutella-0.96.6.tar.bz2" it will also search Gnutella with a classic keyword search for the filename. Search results with matching SHA-1 will then be picked up by the orphaned download that was created by the magnet link. For rare files it will hardly work because it's unlikely you'll find a source. Likewise, this is only advisable for files with unambiguous, unique names. > > The DHT feature is rather a preview in the current release. There are no GUI > > controls to inspect the DHT status or configure it. You might want to set > > dht_debug or dht_lookup_debug to some value above 1-20 to have at least some > > information on the standard error output respectively your log file. There's > > diagnostic output showing when DHT lookups are performed, whether they > > succeeded or failed etc. > Yes, I have dht_debug = 1 and I see one peculiar thing: ALL the DHT > FETCH result in "not found". I have three days worth of debug output and > absolutely all DHT FETCH are "not found", whether they were for "ALOC", > "PROX" or "BTAL" (?). I don't know if this is normal, but it sure looks > suspicious to me (which may be due to my ignorance of the DHT's inner > workings). That sounds a bit odd, yes. Note that sharing a file isn't actually sufficient. It has to calculate the SHA-1 first and then store it periodically in the DHT. LimeWire's publishing strategy seems to be rather sub-optimal and DHT values expire quickly even for peers with long uptimes and static IP addresses. That explains why you still won't find all shared files at any time. > On the other hand, searching for this file: > http://bitzi.com/lookup/YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C (MLK speech, as > you suggested) does produce very quick results: > > ----- DEBUG LOG ----- > 09-04-02 12:54:56 (MESSAGE): DHT LOOKUP[906] ending value fetch with 0 pending FIND_VALUE RPCs > 09-04-02 12:54:56 (MESSAGE): DHT LOOKUP[906] terminating value lookup (ALOC) for c344a3ce02b06716a515e59a0277524d202cbba2 with 15 values > 09-04-02 12:54:56 (MESSAGE): DHT LOOKUP[906] 3.683538 secs, hops=2, in=5673 bytes, out=2106 bytes > 09-04-02 12:54:56 (MESSAGE): DHT ALOC lookup for YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C returned 15 values > ----- END DEBUG LOG ----- > > It doesn't happen this way if I simply search for the urn:sha1: value. If you just enter a prefix SHA-1 as search, it triggers a classic URN search by SHA-1 and will rarely gain any results. It doesn't use the DHT (at least for now) because the DHT doesn't tell as more than addresses of peers. In theory, we could use a HTTP HEAD request to gather information like filename and filesize to fabricate a search result. -- Christian ------------------------------ Message: 6 Date: Thu, 2 Apr 2009 15:09:26 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] Version 0.96.6 stable has been released To: gtk-gnutella-devel@... Message-ID: <gr2kf6$sr3$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel: :Yes, for popular files that are shared by many peers, it can be useful to :use a combined magnet that provides a "keyword topic", too. So if you append :"&kt=gtk-gnutella-0.96.6.tar.bz2" it will also search Gnutella with a classic :keyword search for the filename. It is my fault, I forgot to append kt. I assumed that the dn would be used as the search in that case (i.e. that kt would fallback to dn if not supplied). :> Yes, I have dht_debug = 1 and I see one peculiar thing: ALL the DHT :> FETCH result in "not found". I have three days worth of debug output and :> absolutely all DHT FETCH are "not found", whether they were for "ALOC", :> "PROX" or "BTAL" (?). I don't know if this is normal, but it sure looks :> suspicious to me (which may be due to my ignorance of the DHT's inner :> workings). : :That sounds a bit odd, yes. No, this is perfectly NORMAL. In Kademlia, a FIND_NODE and FIND_VALUE are similar, excepted that FIND_VALUE will return a value if found locally. A DHT FETCH, as logged by GTKG, is a FIND_VALUE. The semantics is that you need to converge to the key in the KUID space, so nodes looking for a value ask your node about closest nodes, and in turn they will contact these closest nodes to ask them about even more closest nodes to the key until they have found 20 closest nodes (and none has returned any value, meaning the value is not found) or one node returns value stored locally. :If you just enter a prefix SHA-1 as search, it triggers a classic URN search by :SHA-1 and will rarely gain any results. It doesn't use the DHT (at least for :now) because the DHT doesn't tell as more than addresses of peers. In theory, :we could use a HTTP HEAD request to gather information like filename and :filesize to fabricate a search result. I think "ALOC" values contain enough to fake a query hit if needed. Raphael ------------------------------ ------------------------------------------------------------------------------ ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 28, Issue 2 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
