Re: Re: DHT usage and requirement lists

Arne Babenhauserheide <[email protected]> Wed, 6 Aug 2008 23:30:51 +0200
Newsgroups gmane.network.gnutella.devel
Message-ID <[email protected]>
Am Mittwoch 06 August 2008 22:14:12 schrieb Michael Rogers:
> > A way of clustering I'd think interesting would be to cluster by
> > similarity in the query routing tables -> similar shared files.
>
> Interesting idea! It might be vulnerable to spammers, though (fill your
> QRT with certain keywords in order to cluster with users who are
> interested in those keywords).

ouch, yes. 

And that's an already present pollution. 

But I think it will only do harm as long as the spammers share similarly to 
the searchers, and spammers often share only one specific type of stuff, or 
try to respond to everything. 

It could even push current spammers to the edges, because those need to fill 
their QRTs to make sure they get every keyword request so they can reply with 
their keyword spam. 

It could enable spammers to more selectively spam one type of content, but 
would make plain spam attacks harder. 

> I think we should focus on "proven" relationships - for example, X knows
> Y in real life, so X trusts Y not to be a spammer even if they don't
> share the same taste in files, or X has downloaded good files from Y in
> the past, so X trusts Y to have good files even if they might not like
> each other in real life!

Sounds good. 

How about using a metric which accounts for the amound of data as well as the 
number of files? 

Something like 

preferencing_value = num_of_downloaded_files * avg_data_per_file

with num_files and avg_data only updated when a download completes (so hosts 
which serve files which can't complete don't get preferenced). 

Updating would be damned easy: 
num_files += 1
avg_data += (mb_downloaded_for_completed_dl - avg_data) / num_files

The value for longlived and reliable sharers then slowly increases. 

To make it not rise too much (and to keep a limit on the amount of data which 
needs to be tracked), num_files could be reduced by one every few weeks, 
every time total_uptime crosses another multiple of a week, or a multiple of 
sqrt(avg_data) days or similar (faster) and the data about the uploader could 
be removed once the value reaches 0. 

Best wishes, 
Arne

-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- 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]