gtk-gnutella-devel Digest, Vol 20, Issue 3
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 20, Issue 3
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. Gnutella connections healthy again (Hauke Hachmann) 2. Updated Norwegian Bokmaal translation (Alexander Nicolaysen S?rnes) 3. Re: Updated Norwegian Bokmaal translation (xiando) 4. Re: Updated Norwegian Bokmaal translation (Christian Biere) 5. Re: Updated Norwegian Bokmaal translation (Christian Biere) 6. Re: Gnutella connections healthy again (Christian Biere) 7. Re: Gnutella connections healthy again (Hauke Hachmann) 8. Re: Gnutella connections healthy again (Christian Biere) 9. false "d->status = GTA_DL_CONNECTING" problem. (Matthew Lye) 10. Re: Gnutella connections healthy again (Hauke Hachmann) ---------------------------------------------------------------------- Message: 1 Date: Tue, 11 Mar 2008 14:24:59 +0100 From: Hauke Hachmann <haxe@...> Subject: [gtk-gnutella-devel] Gnutella connections healthy again To: gtk-gnutella-devel@... Message-ID: <200803111424.59670.haxe@...> Content-Type: text/plain; charset="us-ascii" Thanks for the changes of the last days regarding gnutella connections (port-based selection of nodes, rethinking pong relevance, and temporarily changing our user-agent string so that we are no longer "accidentally" banned). My connection profile looks much healthier now. A good mixture of LimeWire/FrostWire, BearShare and gtk-gnutella. And it doesn't even take long to find these. Great! h ------------------------------ Message: 2 Date: Mon, 17 Mar 2008 21:17:27 +0100 From: Alexander Nicolaysen S?rnes <alex@...> Subject: [gtk-gnutella-devel] Updated Norwegian Bokmaal translation To: gtk-gnutella-devel@... Message-ID: <200803172117.28660.alex@...> Content-Type: text/plain; charset="iso-8859-1" Hello, Here is a Norwegian Bokm?l (nb) translation of SVN from 15th March. I had to upload it because the mailing list would not accept the attachment. http://www.thehandofagony.com/alex/oversetting/gtk-gnutella/gtk-gnutella-nb-svn-20080315.tar.bz2 Alexander N. S?rnes ------------------------------ Message: 3 Date: Mon, 17 Mar 2008 21:47:15 +0100 From: xiando <xiando@...> Subject: Re: [gtk-gnutella-devel] Updated Norwegian Bokmaal translation To: gtk-gnutella-devel@... Message-ID: <200803172147.21078.xiando@...> Content-Type: text/plain; charset="iso-8859-1" On Monday 17 March 2008 21:17:27 Alexander Nicolaysen S?rnes wrote: > Here is a Norwegian Bokm?l (nb) translation of SVN from 15th March. I had > to upload it because the mailing list would not accept the attachment. > > http://www.thehandofagony.com/alex/oversetting/gtk-gnutella/gtk-gnutella-nb >-svn-20080315.tar.bz2 Thank you. :-) Have you translated anything on the extra_files/en/FAQ? If you have not then I could translate and send you the file for proofreading? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. ------------------------------ Message: 4 Date: Mon, 17 Mar 2008 23:47:29 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Updated Norwegian Bokmaal translation To: gtk-gnutella-devel@... Message-ID: <20080317224728.GJ24641@cyclonus> Content-Type: text/plain; charset=us-ascii xiando wrote: > Have you translated anything on the extra_files/en/FAQ? If you have not then I > could translate and send you the file for proofreading? Translating the homepage or only parts thereof is also appreciated. The documentation is available locally in your SVN repository: doc/devguide/HOMEPAGE and online: https://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk-gnutella/doc/devguide/HOMEPAGE -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet ------------------------------ Message: 5 Date: Mon, 17 Mar 2008 23:49:47 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Updated Norwegian Bokmaal translation To: gtk-gnutella-devel@... Message-ID: <20080317224947.GK24641@cyclonus> Content-Type: text/plain; charset=iso-8859-1 Alexander Nicolaysen S?rnes wrote: > Here is a Norwegian Bokm?l (nb) translation of SVN from 15th March. I had to > upload it because the mailing list would not accept the attachment. Thank you for keeping the translation up-to-date. I've committed your patch. -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet ------------------------------ Message: 6 Date: Tue, 18 Mar 2008 17:58:14 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Gnutella connections healthy again To: gtk-gnutella-devel@... Message-ID: <20080318165758.GA27176@cyclonus> Content-Type: text/plain; charset=us-ascii Hauke Hachmann wrote: > My connection profile looks much healthier now. A good mixture of > LimeWire/FrostWire, BearShare and gtk-gnutella. Is that the only improvement you've noticed? Did you notice better/more good search results as well? I would have expected that there's a notable difference between the BearShare cluster and the rest of Gnutella. There seems to be less spam outside of the BearShare cluster nowadays but the good results appear to be heavily reduced too. -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet ------------------------------ Message: 7 Date: Tue, 18 Mar 2008 19:06:15 +0100 From: Hauke Hachmann <haxe@...> Subject: Re: [gtk-gnutella-devel] Gnutella connections healthy again To: gtk-gnutella-devel@... Message-ID: <200803181906.15122.haxe@...> Content-Type: text/plain; charset="iso-8859-1" On Tuesday 18 March 2008, Christian Biere wrote: > Hauke Hachmann wrote: > > My connection profile looks much healthier now. A good mixture of > > LimeWire/FrostWire, BearShare and gtk-gnutella. > > Is that the only improvement you've noticed? Did you notice > better/more good search results as well? I would have expected that > there's a notable difference between the BearShare cluster and the > rest of Gnutella. There seems to be less spam outside of the > BearShare cluster nowadays but the good results appear to be heavily > reduced too. I don't have much data to compare. I search only occasionally, and everything I can say about result quality is just rough gut feelings. But I tend to agree: My received query results are not more useful than before. BTW, the "healthy" connection profile I wrote about seems to be not very stable. Now that the BearShare monopoly is circumvented, it is quite hard for me to avoid a LimeWire monopoly, and this bias seems to get stronger every day, possibly due to my ultrapeer cache slowly converging to reflect that monopoly. Perhaps one of the two recent measures to keep BearShare out of our cache was one too much in the long run? h ------------------------------ Message: 8 Date: Tue, 18 Mar 2008 22:45:47 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Gnutella connections healthy again To: gtk-gnutella-devel@... Message-ID: <20080318214546.GH12705@cyclonus> Content-Type: text/plain; charset=us-ascii Hauke Hachmann wrote: > On Tuesday 18 March 2008, Christian Biere wrote: > > Hauke Hachmann wrote: > > > My connection profile looks much healthier now. A good mixture of > > > LimeWire/FrostWire, BearShare and gtk-gnutella. > > > > Is that the only improvement you've noticed? Did you notice > > better/more good search results as well? > I don't have much data to compare. I search only occasionally, and > everything I can say about result quality is just rough gut feelings. > But I tend to agree: My received query results are not more useful than > before. Even if it's not much data, user experience the most useful indicator. Nice statistics are useless if the net result is frustrated users. > BTW, the "healthy" connection profile I wrote about seems to be not very > stable. Now that the BearShare monopoly is circumvented, it is quite > hard for me to avoid a LimeWire monopoly, and this bias seems to get > stronger every day, possibly due to my ultrapeer cache slowly > converging to reflect that monopoly. Perhaps one of the two recent > measures to keep BearShare out of our cache was one too much in the > long run? I relaxed the constraint regarding historic ports, so that the addresses of these BearShare peers are still accepted with low probability. You could look for BearShare peers in your results and try to connect to them to accelerate discovery of them. As mentioned, the amount of spam relayed through these Ultrapeers seems to be much higher than recent LimeWires. -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet ------------------------------ Message: 9 Date: Wed, 19 Mar 2008 22:16:48 -0400 From: Matthew Lye <mlye@...> Subject: [gtk-gnutella-devel] false "d->status = GTA_DL_CONNECTING" problem. To: gtk-gnutella-devel@... Message-ID: <8FA30717-A316-46A6-9FA1-A300C42143C7@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Okay, this bug might be a bit esoteric, so I'll do my best to describe it. Replication: A) In the 'Incomplete' view of 'Downloads', one may sort the downloads by the number of sources. Doing so, then B) selecting a large group of the *not currently running/host queued* incomplete downloads which have at least one source, and C) using the contextual menu item 'Start Now' to start downloading the items as soon as possible, Symptoms: 1) I tend to notice a large number of assertion failures regarding "! DOWNLOAD_IS_RUNNING(d)" from 'downloads.c' (the main one). 2) With a bit of poking, I've found that this is due to *d->status = GTA_DL_CONNECTING, 3) allegedly to [unique enough] hosts with an IP number but no vendor/version identity. 3) Other responses have been tested and found for authentically in- use downloads; furthermore, 4) the number of connections does not appear to substantiate the claim that connections are being made. Analysis: a) I have traced this back as far and as best I can, and I believe that the problem has to do with the status information attached to incomplete files, b) but then I hit callbacks written with #define statements, et cetera, and can has cheezburgr. - M.L. ------------------------------ Message: 10 Date: Thu, 20 Mar 2008 12:41:10 +0100 From: Hauke Hachmann <haxe@...> Subject: Re: [gtk-gnutella-devel] Gnutella connections healthy again To: gtk-gnutella-devel@... Message-ID: <200803201241.10691.haxe@...> Content-Type: text/plain; charset="iso-8859-1" On Tuesday 18 March 2008, Christian Biere wrote: > > BTW, the "healthy" connection profile I wrote about seems to be not > > very stable. Now that the BearShare monopoly is circumvented, it is > > quite hard for me to avoid a LimeWire monopoly, and this bias seems > > to get stronger every day, possibly due to my ultrapeer cache > > slowly converging to reflect that monopoly. Perhaps one of the two > > recent measures to keep BearShare out of our cache was one too much > > in the long run? > > I relaxed the constraint regarding historic ports, so that the > addresses of these BearShare peers are still accepted with low > probability. You could look for BearShare peers in your results and > try to connect to them to accelerate discovery of them. That didn't seem to do the trick for me. Keeping the number of hosts with historic ports in the cache low may work well if you don't use the anti-monopoly feature. It will then lead to a better connection profile on _average_, considering all GTKG peers in the network as a whole. But the anti-monopoly feature enforces a certain connection profile on every _particular_ instance of GTKG (that has this feature enabled). I have this feature enabled, because I am not only interested in the health of the network as a whole, but of course also in the health of my very particular connection profile, because I want to receive good (read: diverse) search results and also want to share my files to as many network islands as possible. To make this work smoothly, one should not only control which hosts are put _into_ the cache, but also make a selection decision when hosts are read _out_ of the cache. Like the one I proposed 2008-01-10. BTW, since GTKG no longer puts pong results into the cache, the number of historic hosts has already decreased a lot, so perhaps the test in hcache_add_internal() is no longer needed at all? bye, Hauke ------------------------------ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 20, Issue 3 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
