Re: Creating a Query for a SHA-1 Hash

--- In [email protected], Raphael_Manfredi@... wrote:
> I guess what I've been trying to tell you is that SHA1 queries, as
designed
> a long time ago by HUGE, are just no longer working well.  All LimeWire
> ultrapeers drop them and gtk-gnutella will not route them if they're not
> part of the QRP table.
> 
> Maybe SHA1 queries work fine in a BearShare island, and this is just
fine
> since as long as it hits a LimeWire or gtk-gnutella peer, the SHA1 query
> will most likely be dropped and therefore will not cause any damage to
> the connected peers.  This is why I get only ~3% of SHA1 queries at
my node
> (I am connected to at most 2 to 3 BearShare ultrapeers, they appear
to be
> quite rare nowadays).

As far as I know, LimeWire has not changed their decision to pass them
along undamaged instead of dropping them and BearShare is not in any
form of island because the UPs of both LimeWire and BearShare still
have large numbers of interconnections at all times.  The reason hash
query traffic is so miniscule beside the regular traffic is that they
are used less frequently, being a power-user kind of trick.

Run a Bear in ultrapeer mode and see for yourself all the LimeWire
peers.  LimeWire is equally open to BearShare peers, connecting to
several more than what you are apparently used to.

While you're at it, try out the hash searches in BearShare and you'll
see they still work very very well.  Don't forget that Shareaza is
still supporting them too, and obviously it's in a way different from
whatever you are doing because their implementation still works.


> Please don't take this as meaning we're not supporting SHA1 queries
any more.
> This is not true. Simply we're no longer supporting them through
broadcasted
> Gnutella queries.  Big difference.
> 
> As for proxying SHA1 queries from leaf nodes through the DHT, I
think this
> would be too bandwidth consuming for the ultra nodes.  Contrary to
Gnutella
> queries where the bandwidth cost is spread over the network, DHT
queries cost
> more bandwidth to the issuer.  Therefore, it seems wiser to have
leaves join
> the DHT in "passive" mode and issue SHA1 queries themselves through
the DHT.

If you're just dropping them and not helping with results from the
DHT, how exactly ARE you supporting them?  What are you doing with
hash queries that come through a peer?  What about leaves from other
vendors?  

How does a single query cost more bandwidth to the leaf or peer that
sent it, since it is just one query?  Is an issuer something other
than the one node that made the query in the first place?

 
> Until LimeWire fixes their much too low lifetime for published alt-locs,
> DHT publishing will also cost a lot to nodes so many nodes will just not
> publish their SHA1, thereby defeating the purpose of having DHT
searches.
> But I'm confident the LimeWire folks will realize the problem this
poses and
> will fix it, hopefully following the proposal for lifetime
management that I
> have outlined here last Fall.


Keep reminding them.  It took a few years to realize I wasn't mistaken
when I told them their 64K DHTs were 100% saturated more often than
not. ;]

How low is it, by the way?