Re: Creating a Query for a SHA-1 Hash

Quoting Aaron Walkhouse <[email protected]> from ml.gnutella.dev-forum:
:I use them daily and they still work as well as ever. In fact, they
:are absolutely essential for the vital activity of tracking and
:fighting the masses of spam, malware and worms that pollute the
:network daily with literally millions of false filenames.

You must be using SHA1 searches for very popular values then because
I've never seen one of my SHA1 search return anything.

:Like I said, they are so specific to individual files that there is no
:possibility, read it again, _no_possibility_ that hash queries could
:do harm to the network in any way.

Can you prove that?  Flooding queries do harm the network so unless we're
not speaking about the same thing, I believe your statement is false.

:How much bandwidth do those queries actually cost?  
:Have you actually measured it? 

I did measure it.  Nowadays, the amount of SHA1 queries that my node
receives is very low (~ 3% of all queries) and these queries are most
often dropped anyway since gtk-gnutella does not route SHA1 queries with
no matching entries in the QRP.

:Is it so small that it cannot be measured at all?  No?  Prove it.  

Prove what?

:Is the bandwidth used so large that it crashes your own product or
:knock it off the network?  If so, fix your own software first before
:trying to get others to weaken theirs for your sake alone.  

Thank you, my software is runnning just fine and is never crashing.
Especially not because of bandwidth issues.

:If it is in between try to produce numbers instead of speculation or
:baseless opinion.

Sure, be my guest.

:There is no reasonable justification to eliminate such a valuable and
:useful tool, especially that which has existed peacefully and usefully
:on this open public network for years without ill effect while giving
:real, tangible benefits to end users. Trying to save a few tenths of a
:percent from the hundreds of megabytes a day our ultrapeers typically
:spend in the course of normal operations should not come at the cost
:of one of our most accurate and beneficial tools.

It's not been eliminated.  It's just that SHA1 searches must now be
conducted through the DHT, and no longer by issuing URN queries in
Gnutella.

:Instead of trying to get rid of it take a chance and test it in your
:own software first for a few months.  Don't forget to be fair and use
:the same limits established here back in the beginning, which is 8
:seconds delay between user-directed queries and only one per hour
:automatically, restricted to files which are stalled for lack of
:working sources. When your download performance jumps to levels
:comparable to BearShare and Shareaza you'll probably consider the half
:day or so of coding time well spent on behalf of your end users.

I have no idea where you're coming from here.  Gtk-gnutella has been
around since 2001 and has always strived to provided the most useful
features to its users.

:By the way.  Don't forget that hashes are never, [I'll say it again,
:never] added to query routing tables, not even by BearShare.  They
:never have been and probably never will, not even as digests.  It was
:never needed in the first place.  That makes them trivially easy to
:add to any gnutella servent.  

You are completely right.  Even gtk-gnutella no longer inserts SHA1 in
its QRP (it used to do so before DHT support was added).

:Once a working DHT is up and running in LimeWire it will likely proxy
:hash searches to it for the sake of the public as well, since gnutella
:is still an open network with room for us all and LimeWire LLC still
:feels that way as a company.  That means virtually everybody will be
:using hashes cooperatively for the sake of the whole. Do you really
:want to be left behind?

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.

Cheers,
Raphael