Re: Creating a Query for a SHA-1 Hash

--- In [email protected], Raphael_Manfredi@... wrote:
>
> Quoting Aaron Walkhouse <Aaron_Walkhouse@...> 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.

Read my post again.  They have always worked well for BearShare and
Shareaza users, even for rare files.  More popular files still get
lots of results.  Try it on popular files and especially on the spam
and trojans that go by false filenames and you'll see hundreds of hash
results while keyword searches yield a tenth as much.


> :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.

If hash queries are so harmful, why are we still online after so many
years of constant hash querying?  


> :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.

So, in other words, the dreadful floods of hash queries amount to a
massive backbone-breaking 3 PERCENT of all queries, and you were still
getting savings by dropping them all.  


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

You just did.  3% is so low that background noise due to malformed and
dropped packets is deafening by comparison.  


 
> :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.

So, you admit there really is no problem and don't feel like proving
yourself wrong, eh?  ;]


> :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.

Ah, so you are now the official Chief Developer for gnutella?  Will
you demand everyone else resign or just bow down and obey?  What would
Vinnie say to that little joke, I wonder?  :P

The fact is that hash queries are still working well and efficiently
even as you try and fail to stop them.  You might as well try to bail
a ocean liner with no leaks using a teaspoon and a coffee mug.  Your
only complaint so far is that you can imagine a single extremely
hypothetical drawback which has never materialized in real-world
conditions for a simple feature that you personally do not like
because you didn't invent it.

Far better to show some respect for the users and past developers of
gnutella. Accommodate what they choose to use and build on it while
moving forward instead of trying to push some of them behind in order
to wriggle "your" gnutella one step ahead.  If you show that you are
willing to respect the openness of gnutella, even with what you
personally see as it's few warts, you'll find it easier to get others
to cooperate with you in enhancing it for everyone.

 
> :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.

Yet those features you personally dislike are to be banned or at least
weakened so that other, lesser beings might stop using them?

 
> :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.

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

Don't take any of this personally, you two.  It was this same kind of
slow, steady roasting on the part of myself and the BearShare Labs
team that got Vinnie to bring BearShare to where it was while avoiding
many pitfalls like locked-in adware. I know it works and I know what
I'm doing here as I struggle to keep you from messing things up for a
few million BearShare users.  You both can help make sure hash queries
continue to work well by making sure you still handle them in a
productive fashion instead of trying to eliminate them altogether.