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]