[p2p-hackers] Actual availability of P2P systems
Wolfgang Müller
wolfgang.mueller at wiai.uni-bamberg.de
Thu Jan 5 12:32:06 UTC 2006
Hi, Daniel,
> One could argue that unreachable peers are not actually part of the
> network, and therefore this happens 0% of the time. ;-)
Yes, and Gnutella is best, when you share just with yourself. You do not even
need a network, then :-D .
> I know what you mean, though: how often are a significant fraction of
> peers which are running the P2P software unreachable from the largest
> connected component?
Thanks for improving the precision of my request. Let me go one step further.
I think it is rather
<quote>
How many times there is a significant set of peers D such that for all d\in D
the following conditions hold:
- d was connected (in the sense of successful initial introduction) to the
largest connected component (LCC) within the time interval \delta_t
- d now *is* disconnected from the LCC
- d's user did not launch any leave operation to disconnect d from the LCC
- d's is connected to the internet, i.e. knowing the IP address of current
members of the LCC, it could connect to the LCC. d has been connected to the
internet in this sense all through \delta_t
</quote>
Suggestions for improvement welcome.
> I'm not aware of any measurement studies on this topic (perhaps partly
> because it's difficult to measure).
I guess so, yes, but before I say there is none, I would prefer to know. This
is why I ask.
> Are you thinking of DHT
> applications or "unstructured" P2P systems such as Gnutella? In the
> later case, significant fragmentation is very unlikely due to the high
> out-degree of most peers.
Both.
> > How high is the percentage of requests that fail (in the sense that they
> > return a faulty result) in existing fielded DHT applications?
> I do not think this question (as stated) is sufficiently
> well-defined.
Parts of the lack of definition is due to my wish to improve recall ;-) . I
would prefer to receive some suggestions that do not fit rather than
discourage suggestions that would have fit.
> What would you consider a faulty result, and (for the
> purposes of designing a measurement study) how would you can you tell
> if a result is faulty?
I would consider a faulty result the event that a key/value pair that has been
inserted within the last \delta_t is not reported to be present by a
retrieval request.
How I could tell? By being the inserter myself. If you want a larger basis
(i.e. not just one petty peer in the network as a probe) you can consider
using PlanetLab if this is consistent with PlanetLab's rules.
> Which fielded DHT applications are you thinking of?
Overnet or some others I am not aware of.
Cheers, and thanks for your thoughts,
Wolfgang
--
Dr. Wolfgang Müller
LS Medieninformatik
Universität Bamberg
Check out the SIG MM web site http://www.sigmm.org
More information about the P2p-hackers
mailing list