Haxe wrote: > On Wednesday 11 July 2007 03:04, Christian Biere wrote: > > Haxe wrote: > ... > > > Or at least lobby the > > > LimeWire developers into fixing the problem themselves?
You don't think I would have published this if I hadn't talked about it with them at least once, do you? > > Did I hear "I volunteer"? Please, go ahead. > OK, I have just subscribed to LimeWire's development forums. But for a > technical discussion, I need technical arguments why LimeWire's current > behaviour is especially bad. Several questions come to my mind: > - Does LW drop long queries as an Ultrapeer, so that these queries are > not even routed, or does it only ignore them when comparing to its > local database? As far as I can tell, it ignores them and drops them. > - What about non-simple-keyword searches? SHA1? Are they affected? Does > LW honour them at all? The SHA-1 is not carried in the plain search term field of a query. Some buggy clients put it there though. LimeWire drops SHA-1 searches anyway except for single-hop queries. > And what are those "XML queries" mentioned in > the recent SVN commits? XML sounds like "longer than 30 bytes" to me. XML queries have a lot of overhead. They are usually over 100 bytes large. LimeWire accepts up to 500 bytes of XML payload for queries. > - Are there other types of queries that I don't know about that tend to > be long? Do magnet links induce special query types? magnet-links trigger either plain searches (e.g, magnet:?kt=my+new+car ), SHA-1 searches (e.g., xt=urn:sha1:... ) or both. > - Does LW's behaviour have a bad influence on QRP? With respect to length of queries, not all. Though the routing might be less effective if you're forced to broaden your search by using less or shorter words. Including the SHA-1s of files in the query routing table increases the fill significantly because the hashes don't overlap as much as those for words, so almost each shared file fills on slot of your table. LimeWire supports only tiny 64 KiBit tables. Others support 2 MiBit large tables, so that they are still rather sparse even if you share thousands of files. > - How did you discover LW's behaviour? What kind of bad effect did you > notice? I noticed that a specific search gained almost no results. Then I cut some words from the string and noticed that I suddenly get a lot results. > - Why was the bug not noticed during the last three years? Is it > possible that it is not such a big problem after all? BearShare, Shareaza, Gnucleus, Morpheus, gtk-gnutella don't do this. Their marketshare has significantly decreased over the years and some of them tend to cluster, so that these users would not notice it as long as they have a connection to their own breed. Also many users don't use the latest versions, so the real effect was delayed by 6 months or more. Most search terms are certainly shorter than 30 characters. At least it's not 30 bytes. Also if you cannot find a file, wouldn't you simply assume it is shared by nobody? There could be thousands of reasons and bug why some file could not be found. I rarely dig through LimeWire source code except when I'm forced to due to lack of alternatives. I don't aim for bug-compatiblity anyway. The Gnutella protocol is quite flawed and limited anyway, I don't see any need for crippling it even more. The worst about this issue though is, that they never said a word about this bold move. > When I clearly understand the problem, then I will try to get in contact > with the LW developers. They added this limit because they wanted to cut-off auto-generated requeries. They are aiming for those which use full filenames, I guess. This is their only reason for dropping searches with terms longer than 30 characters. They are quite proud of it, too. -- Christian ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
