On Tue, Oct 02, 2007 at 03:39:26PM +0200, Christian Biere wrote: > Alex Bennee wrote: > > Where do our block lists come from? I notice we have had IP lists and > > spam lists for a while in GTKG but I'm guessing the roll out of these > > is dependant on how often the packagers rebuild GTKG (or you refresh > > CVS). > > Yes, you have to update them from SVN or wait a couple of months for the next > release.
I mean where do you get them from before adding them to the GTKG repo? Are you recycling data from another project or are we generating the list within the GTKG project? > > Are there any distributed/central block list repos that would be worth > > implementing for GTKG? > > The IP range block list is not large, so it could be easily exchanged between > peers. LimeWire has been doing this for some time. However, there are few > gtk-gnutella peers, so distributed updates would spread rather slow they > usually don't see other gtk-gnutella peers frequently. So unless you want to > use LimeWire's block list, fully distributed updates would not work > > to well. Surely there should be a platform agnostic block list that is used by all servants? I assume there must be some kind of key signing involved to prevent pollution of the block list by 3rd parties. > The other option is to use one or more well-known servers which could be > normal > web servers or Gnutella peers. I think that's a pretty lame option though > because what is Gnutella good for anyway if it can't even help itself? Also, > you'd need people who provide these servers for a defined time frame like a > couple of months. Also how would you notify peers about available updates? You > see, this smells like GWebCache all over which we know is a recipe for > disaster. One option was PeerGuardian (I only mention it having seen it fly by in my news feed today). I was pondering if there where any open block list projects. > An alternative would be using a UDP crawler to search for gtk-gnutella peers > and send them update notifications. gtk-gnutella peers could also try to > remember other gtk-gnutella peers with high uptimes and query these for > updates > if they haven't received any in several weeks. Seems a little heavy handed. I think it's preferable things pull when they see rather than seeking out everything that is out of data. Would it be possible to add an extension to reply packets to let it the client know what version was the latest one of the blocklist? > > Distributing the spam list could essentially work in the same fashion albeit > due to its size, you'd want to do this incrementally. As we have tigertree > support in gtk-gnutella now, implementing this would not be too difficult, > assuming items are usually appended to the list, so that you only have to > fetch the last slice of the file saving a lot of traffic. A phase 2 problem I think :-) > > -- > Christian > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gtk-gnutella-devel mailing list > gtk-gnutella-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel > -- Alex, homepage: http://www.bennee.com/~alex/ Please recycle. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
