# [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

> 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