Re: Re: Using the DHT to find download sources

Am Freitag 25 Juli 2008 17:10:28 schrieb vvpng:
> That makes sense! So if we can stop advertising spammers' spams on
> popular files, then spams on rare files will disappear too because
> advertising spammers will go out of business.

That's what I hope :) 

At least spam will be reduced to plain honest attacks on the network :) 
 
> > Long story short: They don't seem very applyable to p2p spam.
>
> Good research!

Thanks for the praise! 
(reading your words felt good)

I hope I didn't oversee anything. 

> For rare files, there is big chance that none of the files are within
> 3 hops from you, then QRP wont help, right? If so, the requests cannot
> "only travel where they might find results".

It will still help, since QRP works on the last three hops, so it will reduce 
the cost of the most expensive part of the search. 

For popular files, that expensive part can be avoided altogether (stopping the 
search early with Dynamic Querying), but for rare files it becomes much less 
expensive due to the Query routing protocol. 

> > So I'd rephrase that first requirement to
> > 1) A good user experience and low overhead.
>
> Fast is better than slow, as long as we still have low overhead. :-)
> The question is again "how to figure out popularity"

Jupp :) 

Maybe Ultrapeers could just check the query with their combined query routing 
table. If there can't be a result in the QRP horizon, the query might be a 
rare query, since it isn't available within 2 hops from the checking UP. 

(I'm not really sure if that holds true in real life. Could someone to a test 
for that?)

But maybe we could altogether avoid keyword queries in the DHT, keeping it 
optimized for Hash queries. 

The reasoning is, that a hash query is a different task than a keywork query, 
and so each task should be done by a different tool which can be optimized 
for the task. 

Luckily Gnutella is heavily optimized for Keyword queries, and Kademlia can do 
Hash queries very well, so we already have two specialized tools. 

One tool for one task, and a GUI to bind them together, so users don't have to 
know that there are two tools, just that the program can do both tasks 
exceptionally well (nothing keeps you from telling your users what you do, 
though, as long as it fits with your GUI policy). 

> > Could you post an updated version of the requirements list?
>
> Will do.

Thanks! 

Best wishes, 
Arne

-- Weblog: http://blog.draketo.de
-- 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]