Re: Re: DHT usage and requirement lists

Am Montag 04 August 2008 23:03:28 schrieb pwang708:
> Yes, we search torrent files as we do for other files.

So the search for torrent files can be taken out - it is already included in 
regular keyword searches. 

> Good point! I am not sure about the cost. This is what I am thinking
> though: the DHT distributed tracker is a backup of a traditional
> tracker. Besides, once a peer connects to others in the swarm, they
> can start to use peer exchange protocol to learn more peers in the
> swarm. A distributed tracker can be sloppy in this case...  Need more
> analysis... Any idea?

I don't know how the "peer exchange protocol" works in BitTorrent, so I can't 
say much here. 

Could someone from LimeWire who implemented the torrent stuff comment on the 
load on torrent servers due to LimeWire? 

> Not true for my friends either. :-)
>
> How about we change it to all the friends + people from who we
> downloaded files before.

I would rather say: define a limit (for example: cluster a maximum of 50% of 
the connections as Michael suggested) and then try different clustering 
algorithms. 

The limit ensures, that the network stays operative. 

It would also be possible to let the users decide if and how to cluster. 

A way of clustering I'd think interesting would be to cluster by similarity in 
the query routing tables -> similar shared files. 

> Yes, lots of them are details in the clients. Some might not be. When
> lookuping up a key, a node A sends find_node requests to many nodes
> including say an intermediate node B and a replica root R. I think it
> make sense to allow A to specify the number of contacts that B and R
> need to return, since the purposes of the find_node requests are
> different. Another example, when a node uses parallelism = 1, it may
> want more contacts returned from a intermediate hop than when it uses
> parallelism = 3, so that the probability of stuck is small in both cases.

Could this be used to azzack the network? 

> > > > 11) Identification system.
> >
> > What exactly do you mean by that?
>
> To be able to authenticate a node. NodeID generated randomly or NodeID
> = hash(IP/port), or = hash(public key), or = hash(public key,
> IP/port), etc. It would be better if we can have a certificate
> authenticity. If I remembered correctly, Credence needs a certificate
> authenticity.

Credence only used a certificate (very weak: download a big files per 
client -> public and private key) to keep people from creating an unlimited 
number of bogus clients - there were already ideas to exchange that with CPU 
intensive cryptopuzzles to create the node keys. 

And for anything else, the certificate authority would be a single point of 
failure. 

For what exactly do we need to authenticate a node in a completely decentral 
system? 

And even when we might have use for one, can that be defined at a later stage 
by keeping the core protocol open enough to allow for custom queries? 

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]