Re: Creating a Query for a SHA-1 Hash
[email protected] Sat, 3 Jan 2009 14:12:57 +0000 (UTC)
| Newsgroups | gmane.network.gnutella.devel |
|---|---|
| Organization | Home, Grenoble, France |
| Message-ID | <[email protected]> |
Quoting Aaron Walkhouse <[email protected]> from ml.gnutella.dev-forum: :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. I don't take any of this personally, so no worries. 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). 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. 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. Raphael