[p2p-hackers] How to solve the "Britney problem"?
em at em.no-ip.com
Thu Dec 30 01:23:52 UTC 2004
Thanks everybody for your helpful replies. Here is what I'm trying to
My interest in DHT's originates primarily from my desire of building a
decentralized (serverless) communications system able to handle both text
IM and VoIP; I first mentioned this goal nine months ago in a post
archived at http://zgp.org/pipermail/p2p-hackers/2004-March/001780.html .
At present, I'm thinking of implementing it as a daemon simulating a SIP
and RTP proxy bound to 127.0.0.1, so that any SIP/SIMPLE user agent (of
which there are many around) could be used for the actual user interface.
The daemon would then translate SIP messages and encapsulate the RTP flows
(adding security as well) in a way the UA would be blissfully unaware of.
This approach is similar to what I suggested at
http://zgp.org/pipermail/p2p-hackers/2004-July/002018.html to run SIP over
In order to take advantage from a large installed base, I decided to make
the DHT library interoperable with an existing and widely deployed
application, and I chose Overnet, the Kademlia-based protocol developed by
Metamachine for their eDonkey 1.0 (one of the reasons for that particular
choice is that Ethereal has a dissector for that protocol, making my life
easier during the debugging). That library is now released at
http://kadc.sourceforge.net/ , although in the current version it only
works in "leaf node" mode, accessing the DHT but not participating to it
(the "store" and "find" RPC's are issued, but ignored when received from
other nodes, as on the other hand NATted Overnet peers routinely do).
Of course, the choice of an existing protocol also imposes limitations: I
can play with the structure of keys and data (e.g., I can randomize some
bits of the hash used as key before performing a "store"), but I can't
modify the way records with a given key/value structure are handled by the
peers composing the DHT. Also, Kademlia does not forward requests as
Gnutella does, but uses a "redirection" model where the replies to
individual "find" operations point the requesting node to other peers ever
closer to the target. This prevents the use of application-level caching.
The first sample application I've written, a DNS extender implemented as
caching DNS proxy(http://kadc.sourceforge.net/apps.html#namecache ) is
immune from the "Britney problem" because the distribution of the pseudo
domain names stored in the DHT is likely to be relatively smooth, and as a
result it works fairly well. However, NATted peers in a P2P communications
system need not only a users directory, but also a way to discover
resources such as NAT-traversal helper servers (a' la STUN) or actual
proxies/reflectors (e.g., for SIP or RTP) that are advertised as locally
available by non-NATted nodes. And here lies the problem: the information
that those nodes need to publish has variable data ("my address is
22.214.171.124:5678") but a constant key ("I'm an available SIP proxy", "I'm an
available STUN server" etc.).
Of course, I could use a separate search protocol for those resources,
perhaps a Gnutella-like one based on bounded flooding (as fast
full-overlay-network searches are made unnecessary precisely by the
genericity of the key), or perhaps one allowing sorted access like P-Trees
or SkipGraphs to locate the nodes with the best available bandwidth; but
before building myself a new screwdriver, I'd like to be sure that I can't
somehow use the hammer I already have :-)
----- Original Message -----
From: "Michael J. Freedman" <mfreed at cs.nyu.edu>
To: "Peer-to-peer development." <p2p-hackers at zgp.org>
Sent: Thursday, December 30, 2004 4:13 AM
Subject: Re: [p2p-hackers] How to solve the "Britney problem"?
> This is exactly the problem for which "sloppy hashing" in Coral was
> designed. It can perform this load balancing at the DHT layer (not
> through aggressive app-layer caching like Freenet, CFS, PAST, etc.)
More information about the P2p-hackers