Re: Re: Creating a Query for a SHA-1 Hash
Arne Babenhauserheide <[email protected]> Sat, 3 Jan 2009 19:52:25 +0100
| Newsgroups | gmane.network.gnutella.devel |
|---|---|
| Message-ID | <[email protected]> |
On Saturday 03 January 2009 02:54:53 Aaron Walkhouse wrote: > > Gtk-gnutella has been supporting the DHT (the same DHT as the one used > > by LimeWire) since September 2008 and is conducting its SHA1 searches > > through the DHT. Nobody is left behind, hopefully. > > Good. So you are saying that instead of blocking or dropping hash > queries by servents you have no control over, you will also try > proxying them for the sake of the millions who still use them? Or are > you saying that you have just CHOSEN who gets left behind and it's > fine as long as it's not you? :p No. You have chosen to be left behind when you chose to stick to a dead client. A program is dead as soon as noone develops it anymore, but the environment changes around it. At some point Bearshare will cease to interoperate with other clients, because the other clients will work on improving the protocol, and even though Gnutella is _extremely_ conserative when it comes to protocol changes, . such changes will become necessary. The Bearshare team brought that problem on you when they chose to keep their sources unfree. Don't blame it on others that they keep improving teh protocol. With the DHT the hash queries will become more efficient than keyword queries for rare files. > So, from an absence of evidence and a couple of old guesses made by > others who were actually working on other things entirely you presume > a 100 to one potential savings on a type of query you admittedly have > paid little to no attention to over the past how many years? ;] No. First: I paid attention to hash queries. I've been advocating to use a more efficient hash query mechanism for years, and to treat hash queries differently from keyword queries, since they require completely different optimizations. Second: They did real life load evaluations. BearShare did them on QRP, LimeWire on DQ, and each mechanism individually reduced the load for keyword queries by at least 90%. With out of band replies, hash queries create about equal load as keyword queries without QRP and DQ. With QRP and DQ each keyword query creates only about 1% of the load of a Hash query. > There's a reason hash queries were left to run in the old way. They > didn't actually waste bandwidth as you have just assumed here. Run > the math again and this time don't forget to run it in a high > outdegree model instead of the original flat 0.4 model with a TTL of > 7. Show the impact on the UPs 3.5 hops away from the source. You wanted data and I gave you data. Now you want math, so do it yourself, document it and post it here. And plase don't calculate the impact on an UP 3.5 hops away, but the impact of a single search on all nodes in the network added together. That's what we have to work with to optimize the network. Best wishes, Arne -- -- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :) -- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the history of free software. -- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln. -- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt [Non-text portions of this message have been removed]