[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...
|
From: |
Hermanni Hyytiälä |
|
Subject: |
[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert... |
|
Date: |
Wed, 19 Feb 2003 08:58:17 -0500 |
CVSROOT: /cvsroot/gzz
Module name: gzz
Changes by: Hermanni Hyytiälä <address@hidden> 03/02/19 08:58:16
Modified files:
Documentation/misc/hemppah-progradu: masterthesis.tex
progradu.bib
Log message:
Added refs to thesis doc
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.48&tr2=1.49&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/progradu.bib.diff?tr1=1.73&tr2=1.74&r1=text&r2=text
Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.48
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.49
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.48 Wed Feb
19 05:55:30 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex Wed Feb 19
08:58:16 2003
@@ -27,9 +27,9 @@
\tyyppi{pro gradu-tutkielma}
-\keywords{Peer-to-Peer, P2P, networking, distributen computing}
+\keywords{Peer-to-Peer, Peer-to-Peer, networking, distributen computing}
-\avainsanat{Vertaisverkot, P2P, tietoverkot, hajautetut järjestelmät}
+\avainsanat{Vertaisverkot, Peer-to-Peer, tietoverkot, hajautetut järjestelmät}
\contactinformation{\\
Hermanni Hyytiälä\\
@@ -55,635 +55,412 @@
\chapter{Introduction}
-Peer-to-Peer (P2P) systems can be characterized as distributed systems in
which all
+Peer-to-Peer (Peer-to-Peer) systems can be characterized as distributed
systems in which all
communication is symmetric and all participants have identical capabilities
and responsabilities.
Each participant may contribute data or computing resources (such as unused
storage) to the overall
system, and the welfare of the community can scale with ne number of
participants. Therefore each
participant rely on one another services and resources, rather than solely
relying on dedicated
centralized infracstructure.
-P2P systems have recently received significant attention in both academia and
industry for a number
-of reasons. First, the lack of decentralization means that participants can
form a P2P system without any
-investment to high-priced hardware to coordinate it. Moreover, P2P systems
provides aggregation of enormous
-resources and way to achieve interoperability. Finally, the distributed nature
of P2P improves scalability
+Peer-to-Peer systems have recently received significant attention in both
academia and industry for a number
+of reasons. First, the lack of decentralization means that participants can
form a Peer-to-Peer system without any
+investment to high-priced hardware to coordinate it. Moreover, Peer-to-Peer
systems provides aggregation of enormous
+resources and way to achieve interoperability. Finally, the distributed nature
of Peer-to-Peer improves scalability
and reliability againts certain kinds of faults, e.g. single point of failure.
-\chapter{Terminology}
+\cite{p2pworkinggroup}
+\cite{graham02lecture}
+\cite{winer00whatisp2p}
+
+\chapter{Peer-to-Peer approaches}
+
+\section{General}
+
+\cite{levy90distributedfilesystems}
+\cite{339345}
+\cite{albert-02-statistical}
+\cite{albert-00-tolerance}
+\cite{balakrishanarticle03lookupp2p}
-\chapter{Overview of Peer-to-Peer}
-This section discusses briefly general aspects of P2P systems. A more detailed
general discussion can be found
-from \cite{milojicic02peertopeer, oram01harnessingpower}.
+\begin{figure}
+\centering
+\includegraphics[width=10cm, height=8cm]{application_level_overlay.eps}
+\caption{Peer-to-Peer Application Level Overlay}
+\label{fig:application_level}
+\end{figure}
-\section{What is Peer-to-Peer ?}
-
-\subsection{Definition}
-Altough the exact definition of "peer-to-peer" (P2P) is debatable, these
systems typically lack dedicated, centralized
-infrastructure, resources and services depends on the voluntary participation
of peers. Because of that, the
-challenge of such systems is to determine a archictecure for deploying
participants in a such way so that they
-can efficiently cooperate to provide services and resources to the entire
system. The resources comprise of
-computing power, data (content and storage), network bandwidth, and presence
(human resources). Typical P2P
-systems reside on the edge of the Internet or in ad-hoc networks. As cited in
\cite{milojicic02peertopeer},
-"P2P enables valuable externalities, by aggregating resources through low-cost
interoperability, the whole
-is made greater than the sum of its parts".
-
-Many defitions of P2P have been proposed in P2P community. The Intel P2P
Working Group \cite{p2pworkinggroup}
-defines P2P as "the sharing of computer resources and services by direct
exchange between systems". Ross Lee
-Graham \cite{graham02lecture} defines P2P through three requirements: 1)
System has an operational computer
-of server quality; 2) System has an addressing system independent of DNS; 3)
System is able
-to cope with variable connectivity. O'Reilly's Clay Shirky proposes that "P2P
is a class of applications
-that takes advantage of resources - storage, cycles, content, human presence -
available at the edges
-of the Internet. Because accessing the decentralized resources means operating
in a environment of unstable
-connectivity and unpredictable IP addresses, P2P nodes must operate outside
the DNS system and have significant
-or total autonomy from central servers". Finally Dave Winer
\cite{winer00whatisp2p} cites P2P as "A network
-app that doesn't run in a web browser...the user's machine is a client and a
server...networks with other
-users, creating a community".
-
-Sharing is an essential part of P2P community. Every participant gives to and
obtains resources from the community.
-For example, in Gnutella \cite {gnutellaurl} case, sharing is about offering
data resources to the rest of the community
-and getting other data in return. On the another hand, P2P is way to aggregate
tremendous amounts of computer power,
-storage, and connectivity from the different kind of computers around the
world. address@hidden \cite{setiurl} is an
-obvious an example of this approach. Based on definitions of P2P above, each
participant in P2P system can be referred
-as equal as others in the community. Therefore, P2P system is one in which
autonomous participant depend on other
-autonomous participants. Autonomy of participants, however, means that they
cannot trust each other and rely
-completely on the resources which other peers provides. Issues related to
scalability and profusion become
-more important than in centralized or traditional distributed systems.
-
-At the end, of course, P2P systems are an alternative to the centralized and
client-server types of computing,
-where there is typically a single server (or small cluster) and many clients.
See figure 1 for high-level difference
-of P2P versus centralized, client-server approach.
-
-[Figure 1. Insert picture]
-
-However, more detailed comparison of P2P systems and client-server approach is
significantly more complex
-because: "There is no clear border between a client-server and a P2P model.
Both models can be
-built on a spectrum of level of characteristics, functionality, organizations,
components, protocols etc. Furthermore,
-one mode can be built on top of the other or parts of the components can be
realized in one or the other model. Finally,
-both models can execute on different types of platforms and both can server as
an underlying base for traditional
-and new applications. Therefore, it should not be a surprise that there is so
much confusion about what P2P is
-and what it is not. It is extremely interwined with existing technologies"
[Morgan 2002 REFERENCE!!!].
-
-
-\subsection{History}
-
-The Internet has been originally established in the late 1960s. The objective
of the ARPANET-project was to
-share computers' resources around the United States. The most challenging
purpose of ARPANET was to
-integrate different kinds of existing network technologies with one common
network architecture. The
-ARPANET connected the first few hosts together not in client/server
relationship, but rather as
-equal networking peers. This could be seen as starting point both of P2P
systems and
-Internet \cite{oram01harnessingpower}.
-
-While most early distributed applications can be considered P2P, file transfer
protocol (FTP), Usenet and Telnet
-systems were probably the most extensively used. A Telnet client logged into a
server, and
-an FTP client downloaded and sent data to a file server. In the case of
Usenet, peer servers connected
-to other peers to deliver messages into the user's mail box or into a spool
box containing messages from
-the newsgroups. Altough single application could be seen as was client/server
relationship, the usage model as a
-whole were symmetric. Every computer on the ARPANET could create connections
to any other computer and use
-each other's resources. The symmetry is what made the ARPANET so novel. As a
implication, early ARPANET
-made possible to create more complex systems as DNS \cite{rfc1101}.
-
-In subsequent years, the Internet has become more restricted to client/server
based applications. In
-recent years, however, P2P systems have emerged a significant social and
technical phenomenon. It could
-be possible the Internet could revert to its initial symmetrical form. At the
end, FTP can be considered as
-a predecessor to today's file-sharing P2P systems. The Archie, global indexing
system, was developed to
-provide a central search infrastructure over existing FTP servers. Napster
\cite{napsterurl} is a good
-example of this kind of approach in modern P2P file-sharing systems.
-
-\subsection{Characteristics of Peer-to-Peer}
-
-Decentralization
-In traditional client-server relationship, resources is preserved in
centralized servers and distributed
-through network to client computers. P2P, however, takes a different approach;
there is no centralized
-server or authority for distributing resources in the P2P network. Perhaps one
of the most powerful ideas
-of decentralization is the stress on the participant's ownership and control
of resources. As a implication
-in a fully decentralized system, every peer is an equal participant of the
community.
-
-Scalability and Adaption
-Natural advantage of decentralization is improved scalability of the system.
In P2P, scalability is limited
-by factors such as centralized manageability that needs to be performed and
the amount of states need to be
-maintained. As cited in \cite{milojicic02peertopeer}, good scalability should
not be achieved by the expense
-of other desirable features, such as determinism and performance guarantees.
-
+\section{Centralized}
+\cite{napsterurl}
+\section{Unstructured}
-Anonymity and Autonomy\
-Self-organization\
-Cost Of ownership\
-ad-hoc connectivity\
-accountability\
-reputation\
+\begin{figure}
+\centering
+\includegraphics[width=6cm, height=6cm]{gnutella_overlay.eps}
+\caption{Gnutella overlay network}
+\label{fig:gnutella_overlay}
+\end{figure}
-\subsection{Adaptations of Peer-to-Peer}
+\subsection{Protocols}
-\subsection{Models of Peer-to-Peer}
+\cite{clarke00freenet}
+\cite{zhang02using}
+\cite{milgram67smallworld}
+\cite{adamic99small}
+\cite{ramanathan02goodpeers}
+\cite{kleinberg99small}
+\cite{watts00dynamics}
+\cite{nips02-Kleinberg}
+\cite{ganesan02yappers}
+\cite{gnutellaurl}
+\cite{gnutella2url}
+\cite{shareazaurl}
+\cite{fasttrackurl}
+\cite{morpheusurl}
+\cite{kazaaurl}
+\cite{jxtaurl}
+\cite{jxtaoverview}
+\cite{botros01jxtasearch}
+\cite{kato02gisp}
+\cite{alpineurl}
+\cite{joseph02neurogrid}
-\section{Peer-to-Peer file sharing architectures}
-\subsection{Flooding broadcast}
+\subsection{Super peers}
-\subsection{Distributed hash table}
+\begin{figure}
+\centering
+\includegraphics[width=8cm, height=6cm]{gnutella_overlay_supernodes.eps}
+\caption{Gnutella overlay network with super nodes}
+\label{fig:gnutella_overlay_supernodes}
+\end{figure}
-In Distributed Hash Table (DHT) approach, each value is associated with a
unique key (e.g. SHA-1 \cite{fips-sha-1})in an m-bit virtual address space. The
virtual
-address space is partitioned into sections, which form adjoining regions of
this address space. In general,
-either a single computer or multiple computers is assigned to each section of
the virtual address space. Each
-computer is assigned one or more sections, and they maintains copies of those
key-value bindings whose key values
-lie within its assigned cell. This means, in general, that computer that hosts
corresponding key-value pair,
-is not owned by the user that decided to provide the resource to the netowork.
Moreover, the allocation of the address
-space and the assigment of computers to sections is dynamic. Therefore,
everytime when a node joins or
-leaves the network, the address space is reallocated.
+\subsection{Super peer clusters}
-\subsection{Hybrid architecture}
+\begin{figure}
+\centering
+\includegraphics[width=10cm, height=6cm]{gnutella_overlay_clusters.eps}
+\caption{Gnutella overlay network with 2-redundant super node clusters}
+\label{fig:gnutella_overlay_cluster}
+\end{figure}
-\subsection{Tree based architecture}
-\subsection{Small World Networks}
+\begin{figure}
+\centering
+\includegraphics[width=8cm, height=6cm]{gnutella_query.eps}
+\caption{Basic Gnutella query}
+\label{fig:gnutella_query}
+\end{figure}
-\subsection{Social discovery architecture}
-\section{Open problems in Peer-to-Peer file sharing}
+\section{Structured}
-\subsection{Scalability}
+\cite{aspnes02faultrouting}
+\cite{ratnasamy02ght}
+\cite{236713}
+\cite{258660}
-\subsection{Resource discovery}
+\cite{fips-sha-1}
-\subsection{Performance}
+\subsection{Protocols}
-\subsection{Security}
+\cite{zhao01tapestry}
-\subsection{Interoperability}
+\cite{rowston01pastry}
+\cite{stoica01chord}
+\cite{ratnasamy01can}
-\chapter{Summary of existing Peer-to-Peer systems}
+\cite{maymounkov02kademlia}
-This section reviews briefly existing algorithms used in existing Peer-to-Peer
systems. Note that this section
-is not meant to be an exhaustive survey of Peer-to-Peer systems. Instead, this
section introduces a few systems
-from each architectural perspective.
+\cite{freedman02trie}
-\section{Plaxton}
-Plaxton \cite{plaxton97accessingnearby} developed the first routing algorithm,
which can be used with DHTs.
-The algorithm is not designed to be used in dynamic distributed systems,
because Plaxton algorithm
-assumes a proportional static node population. However, algorithm provides
very efficient routing for search
-lookups. In Plaxton's approach, the routing works as follows: if a node number
e.g. 88768 received a lookup with key
-88797, which matches the first three digits, then the routing algorithm
forwards the query to a node which matches
-the first four digits. To accomplish this, a each node forwards a packet to a
neighbor whose label matches (from left
-to right) incrementally the destination label in one more digit than its own
label does. For a system with $n$ nodes,
-Plaxton's algorithm routes in $O(log n)$ hops and requires a routing table
size of $O(log n)$.
-
+\cite{plaxton97accessingnearby}
-\section{Tapestry}
-Tapestry \cite{zhao01tapestry} is a adaption of Plaxton's algorithm
\cite{plaxton97accessingnearby}. As in Plaxton's approach,
-each node has a identifier. In addition to Plaxton algorithm, Tapestry has
better fault handling and support for dynamic
-peers. In Tapestry, using IP addresses as node identifiers make the overlay
network topology rather similar to the real
-network topology, because IP addresses ``enough close'' to each other share
some length of the same prefix. Therefore,
-the latency of the query (messages) hop is minimal. Tapestry routes queries
with path lengths of $O(log n)$, and each node,
-for a systems with $n$ nodes, maintains routing table size of $O(log n)$. When
a node leaves or joins to network,
-$O(log^2 n)$ messages are required.
+\cite{malkhi02viceroy}
-\section{Pastry}
-In Pastry \cite{rowston01pastry}, the key space is considered as a virtual
circle. Each node is responsible for keys
-which are closest numerically. The neighbors consist of leaf set, which is the
set of $|L|$ closest nodes. In addition,
-Pastry has another set of neighbors randomly spread out in the key space for
more efficient routing. As in Plaxton approach,
-Pastry also forwards the query to the neighbor which have the longest shared
prefix of the key. Pastry routes within
-the pathlength of $O(log n)$, each node has $O(log n)$ neighbors and departure
or joining of node requires $(log^2 n)$ messages.
+\cite{bonsma02swan}
-\section{CAN}
-In the CAN model \cite{ratnasamy01can}, nodes are mapped into a virtual
$d$-dimensional coordinate key space. Each node
-is associated with a hypercubal blocks of this keyspace and every block keeps
information on its immediate hypercubal
-neighbors. In CAN, nodes have $O(d)$ neighbors and expected pathlengths are
$O(dn^\frac{1}{d})$. Node insertion or deletion affects
-$O(number of dimensions)$ existing nodes. Setting $d = log_2(n)/2$, CAN
provides similar scalability as Plaxton approach.
+\cite{AspnesS2003}
+\cite{78977}
-\section{Chord}
-Chord \cite{stoica01chord} uses virtual circle as the key space. As Pastry,
Chord also threats node's neighbors as leaf sets.
-However, in Chord, there are two sets of neighbors: each node has a successor
list of k nodes which immediately follows the node
-in the key space. For better efficiency, each node has additional finger list
of $O(log n)$ nodes placed around the key space.
-In a $n$ node network, each node maintains information about $O(log n)$
neighbors, and a lookup is performed within $O(log n)$
-hops. Additionally in Chord, a node join or leave requires $O(log^2 n)$
messages.
-
+\cite{gurmeet03symphony}
-\section{Kademlia}
+\cite{eriksson03peernet}
-Kademlia \cite{maymounkov02kademlia} is based on a XOR-based metric topology.
In this approach, every query (message) exchanged conveys
-useful contact information. Furthermore, Kademlia uses this information to
send parallel query messages. XOR-metrics are used to calculate
-distances between points in key space. XOR is symmetric, allowing nodes to
receive lookup queries from the same distribution of nodes
-contained in the key space. Routing table contains ``contact buckets'', which
allows to accommodate temporarily used nodes more
-efficiently than other DHT approaches. For a system with $n$ nodes, Kademlia's
algorithm routes in $O(log n)$ hops and requires
-a routing table size of $O(log n)$.
-
-\section{Coral}
-
-Coral [NOTYETPUBLISHED] is based on a new abstraction called distributed
sloppy hash table (DSHT) and is a layer on existing
-lookup systems, such as Chord, CAN, Kademlia, Pastry and Tapestry. In contrast
to original DHTs, Coral provides a lookup, which
-is based on name (instead of hash value). Furthermore, Coral aims to avoid
DHTs' hot spots and to find nearby data without querying
-distant nodes. DSHTs sacrifice the consistency of DHTs to support both
frequent fetches and frequent stores of the same hash table
-key. Moreover, the fundamental observation is that a node doesn't need to
know every replicated location of a resource---it only
-needs a single nearby copy.
-
-\section{Gnutella}
-Gnutella \cite{gnutellaurl} is a flooding broadcast file-sharing system which
treats all nodes in the network functionally equivalent. Each peer tries to
maintain
-a small number of active connections to its neighbor. These peers are selected
from a locally maintained host catcher list, which contains
-the addresses of the neighbor peers. Gnutella uses a Breadt-First-Search (BFS)
traversal with depth limit L, where L is the system-wide maximum TTL
-of a message in hops. Every node receiving a query will forward the message to
all of its neighbour nodes, unless the message has
-reached the TTL limit. Therefore query results are fast, because BFS sends
queries to every possible nodes. However, this approach wastes
-resources, since BFS sends queries to every possible neighbor nodes.
-
-\section{Gnutella2}
-Gnutella2 \cite{gnutella2url} is a second generation flooding broadcast
file-sharing system. As FasTrack, Gnutella2 uses ``Super nodes'' for better
scalability. In contrast
-to FastTrack, Gnutella2 is an open techology. The Gnutella2 system contains
four logical levels: new protocol, new data transport architecture, new base
services
-(including search) and an implementation standard. Unfortunately, currently
there are no full specifications about Gnutella2 available yet. However,
-Shareaza \cite{shareazaurl} file-sharing application supports Gnutella2
technology. More text needed !?!?
-
-
-\section{YAPPERS}
-YAPPERS (Yet Another Peer-to-Peer System) \cite{ganesan02yappers} is hybrid
peer-to-peer system. YAPPERS operates on top of an arbitrary overlay network
-, such as Gnutella, while providing DHT-like search efficiency. Furthermore,
in YAPPERS approach, many small DHTs are built instead
-of one imposing DHT structure. YABBERS divides a large overlay network into
many small neighborhoods. The data within each neighborhood is partiotioned
among
-other neighbors like a regular DHT. Lookup queries relies on forwarding
mechanism, similar to Gnutella-style flooding, to traverse all the small
-DHTs in the network. Specifically, within node's immediate neighborhood,
YAPPERS behaves like a DHTs. When using extended lookup outside of immediate
-neighborhood, YAPPERS behaves like Gnutella, but with more intelligence.
-
-
-\section{FastTrack}
-FastTrack \cite{fasttrackurl} is another hybrid peer-to-peer system. FastTrack
is based on flooding broadcast technique, but in contrast to Gnutella,
-it solves some of the Gnutella's scalability issues by introducing ``Super
nodes''. A SuperNode acts like a local hub, building an index
-of the resources being shared by each node connected to it and proxying lookup
queries on behalf of other nodes. This kind of structure reduces
-network traffic in comparison to a original broadcast query algorithm employed
on the Gnutella system. There are many peer-to-peer file-sharing applications
-which uses FastTrack, such as Morpheus and Kazaa \cite{morpheusurl, kazaaurl}.
-
-\section{JXTA}
-JXTA \cite{jxtaurl} is an open colloboration platform which supports a wide
range of distributed applications. The goal of JXTA is provide a general
-network programming infrastructure. JXTA consists of multiple layers,
including core mechanisms, higher level services and number of
-basic applications. Additionally, at the highest abstraction level, JXTA is a
set of protocols. Each protocol is defined by one or more messages
-exchanged among partisipants of the protocol. Furthermore, each message has
also a predefined format, and may include various data fields
\cite{jxtaoverview}.
-
-\section{SWAN}
-SWAN (Small World Adaptive Networks) \cite{bonsma02swan} relies heavily on
Small World Networks (SWN) \cite{kleinberg99small, nips02-Kleinberg}. SWAN
systems consists of
-named resources which all have an address. In addition to address, each named
resource has a binary identity associated with it, which is independent of its
address.
-Each named resource has a unique position in a k-dimensional identity space,
based on identity's value.
-
-In SWAN, euclidean distance is used to calculate distances in the identity
space. As required by SWN theory for proper link distribution, each node has
several links
-to other nodes. All links are uni-directional and are created locally, storing
the the identity and address of another named resource. For a systems with $n$
nodes,
-SWAN's algorithm routes in $O(log n)$ hops and the total number of links per
named resource does not depend on $n$.
-
-\section{Freenet}
-Freenet \cite{clarke00freenet} is an example of selective forwarding
architecture. In this approach, Milgram's \cite{milgram67smallworld}
small-world
-phenomenon is a fundamental factor. Freenet lookup queries are forwarded from
one node to the next according node's local decisions. The decision is based on
-which one of node's neighbors make the most progress towards target node. For
the lookup algorithm to work proprely, two properties must hold
\cite{oram01harnessingpower}.
-First, the Freenet overlay network graph must connected in that way, so that
any query eventually reach at least one node where the resource is located.
-Second, regardless of the number of nodes, short links must exist between any
two arbitrary nodes. This makes possible to pass queries between nodes in
-reasonable of hops in small-world networks, as proposed by Kleingberg
\cite{kleinberg99small, nips02-Kleinberg}, Adamic \cite{adamic99small}
-and others \cite{zhang02using}.
-
-\section{Alpine}
-ALPINE \cite{alpineurl} uses an adaptive social discovery mechanism to
implement lookup queries. In Alpine network, nodes (users) continually discover
-new nodes to communicate with and determine which properties each node have.
More important, every node has a total control over the connections in the
-network. With every lookup query, a node determines how proficient a given
node is to another node's objectives. The resource discovery in Alpine is
-performed by sending queries only nodes who have a connection to a source
node. To better lookup efficiency, profile operation associated with each node
-is used to evaluate the order in which each is sent a query. As in real social
life, nodes who have returned relevant results in the past, will have a high
-quality value in future query lookups.
-
-
-\section{Future directions}
-
-Since peer-to-peer concept was reinvented by Napster \cite{napsterurl} a few
years ago, great amount of peer-to-peer systems have been introduced.
-Furthermore, the majority of these systems are unable to interoperate
together. According to recent seminar \cite{uclaseminar}, held in the
University of UCLA,
-there are few projects that analyse systems' different approaches. However,
the most important question is that how existing approaches can be combined
into one
-practical and high performance approach, currently known as ``Gnutella++''.
+\cite{harvey03skipnet2}
-\chapter{Open Problems in P2P}
+\cite{garciamolina03sil}
-\scriptsize
-\begin{longtable}{|l|l|l|l|}
-\caption[Security problems in P2P]{Security problems in P2P}
\label{table_security_problems_p2p} \\
+\cite{rowston03controlloingreliability}
+\cite{Bhattacharjee03resultcache}
+\cite{byers03dhtbalancing}
-\hline
-\multicolumn{1}{|c|}{\textbf{Problem}} &
-\multicolumn{1}{c|}{\textbf{Problem description}} &
-\multicolumn{1}{c|}{\textbf{Solutions}} &
-\multicolumn{1}{c|}{\textbf{Comments/Status}}
-\\ \hline
-\endfirsthead
+\cite{pias03lighthouse}
-\multicolumn{4}{c}%
-{{\tablename\ \thetable{} -- continued from previous page}} \\
-\hline \multicolumn{1}{|c|}{\textbf{Problem}} &
-\multicolumn{1}{c|}{\textbf{Problem description}} &
-\multicolumn{1}{c|}{\textbf{Solutions}} &
-\multicolumn{1}{c|}{\textbf{Comments/Status}}
-\\ \hline
-\endhead
+\cite{naor03simpledht}
-\endfoot
+\cite{gupta03kelips}
+\cite{kaashoek03koorde}
+\cite{debruijn46graph}
-\parbox{90pt}{Query routing} &
-\parbox{110pt}{Incorrect forwarding (hostile), incorrect routing (hostile)} &
-\parbox{110pt}{Query monitoring, cross check routing tables, verify routing
tables, create routing table invariants} &
-\parbox{110pt}{Increases system complexity}
-\\ \hline
-\parbox{90pt}{DoS attack} &
-\parbox{110pt}{Distributed, controlled burden againts specific computer(s)} &
-\parbox{110pt}{Client puzzles, load balancing, traffic measurements, traffic
models, replication} &
-\parbox{110pt}{Only partial solutions, traffic models most effective}
-\\ \hline
+\subsection{Distributed Hash Table (DHT)}
+\cite{Gribble:2000:SDD}
-\parbox{90pt}{Sybil attack} &
-\parbox{110pt}{Single hostile entity present multiple entities} &
-\parbox{110pt}{Identify all nodes simultaneously across the system, collect
pool of nodes which are validated, distributed node ID creation} &
-\parbox{110pt}{Not practically realizable, research focused on persistence,
not on identity distinction}
-\\ \hline
+\cite{dabek01widearea}
+\cite{iyer02squirrel}
-\parbox{90pt}{Spam attack} &
-\parbox{110pt}{Hostile entity creates false versions of data} &
-\parbox{110pt}{Do not trust to single entity, get information from multiple
entities, trust on majority's opinion} &
-\parbox{110pt}{Easy to implement, creates more network traffic}
-\\ \hline
+\cite{harrisoncircle}
+\cite{rowstron01storage}
-\parbox{90pt}{Resource spoofing} &
-\parbox{110pt}{Hostile entity gives wrong information about the data which
entity is responsible for/knows about} &
-\parbox{110pt}{Do not trust to single entity, get information from multiple
entities, trust on majority's opinion} &
-\parbox{110pt}{Easy to implement, creates more network traffic}
-\\ \hline
+\subsection{Decentralized Object Location and Routing Networks (DOLR)}
+\cite{kubiatowicz00oceanstore}
-\parbox{90pt}{Entity identification} &
-\parbox{110pt}{Identify participating entities reliably and efficiently
} &
-\parbox{110pt}{Digital signatures, key infrastructure} &
-\parbox{110pt}{Not practically realizable}
-\\ \hline
+\begin{figure}
+\centering
+\includegraphics[width=14cm, height=8cm]{structured_overlay.eps}
+\caption{Generation of structured overlay network}
+\label{fig:structured_hashing}
+\end{figure}
-\parbox{90pt}{Data integrity/authenticity} &
-\parbox{110pt}{Integrity/originality of data is unknown} &
-\parbox{110pt}{Cryptographic content hashes, key architectures} &
-\parbox{110pt}{For data integrity, there are working solutions, but for data
authenticity, some of the solutions are partial, which may be practically
realizable}
-\\ \hline
+\begin{figure}
+\centering
+\includegraphics[width=8cm, height=6cm]{structured_query.eps}
+\caption{Simplified structured system's query}
+\label{fig:structured_query}
+\end{figure}
-\parbox{90pt}{Anonymity} &
-\parbox{110pt}{Anonymity cannot be provided in all cases} &
-\parbox{110pt}{Remailers, pre-routing} &
-\parbox{110pt}{Total anonymity cannot be provided yet}
-\\ \hline
+\section{Summary}
-\parbox{90pt}{Malicious nodes} &
-\parbox{110pt}{How to identify malicious nodes in the system} &
-\parbox{110pt}{Create invariants for node behaviour, verify invariants,
self-certifying data} &
-\parbox{110pt}{Partial solutions, self-certifying data most realiable}
-\\ \hline
-\parbox{90pt}{Access Control} &
-\parbox{110pt}{Can we define access control levels in peer-to-peer network ?} &
-\parbox{110pt}{Schema-based rules} &
-\parbox{110pt}{Some initial experiences, need more research}
-\\ \hline
-\parbox{90pt}{Inconsistent behaviour} &
-\parbox{110pt}{Hostile node could act correctly with its neighbors, but
incorrectly with others} &
-\parbox{110pt}{Public keys, digital signatures} &
-\parbox{110pt}{Not practical approach/working proposal created yet}
-\\ \hline
-\parbox{90pt}{Hostile groups} &
-\parbox{110pt}{Joining node may join parallel network, formed a group of
hostile nodes, hostile node(s) controls the construction of the network} &
-\parbox{110pt}{Use trusted nodes, based on history information, Cryptography,
key infrastructure} &
-\parbox{110pt}{Not 100\% sure if Centreal Authority (CA) is missing, not
practical approach/working proposal created yet}
-\\ \hline
-\parbox{90pt}{External security threats} &
-\parbox{110pt}{Viruses, trojans, sniffers} &
-\parbox{110pt}{Data integrity/authenticity, distributed antivirus software} &
-\parbox{110pt}{Not much research has been done on this}
-\\ \hline
-\end{longtable}
+\subsection{Protocols}
-
-\begin{longtable}{|l|l|l|l|}
-\caption[Performance and usability problems in P2P]{Performance and usability
problems in P2P} \label{table_performanceusability_problems_p2p} \\
+\scriptsize
+\begin{longtable}{|l|c|c|c|c|l|}
+\caption[Different Peer-to-Peer lookup protocols]{Different Peer-to-Peer
lookup protocols}
+\label{table_Peer-to-Peer_protocols} \\
-\hline
-\multicolumn{1}{|c|}{\textbf{Problem}} &
-\multicolumn{1}{c|}{\textbf{Problem description}} &
-\multicolumn{1}{c|}{\textbf{Solutions}} &
-\multicolumn{1}{c|}{\textbf{Comments/Status}}
-\\ \hline
+\hline
+\multicolumn{1}{|c|}{\textbf{Protocol}} &
+\multicolumn{1}{c|}{\textbf{Insert/Delete}} &
+\multicolumn{1}{c|}{\textbf{Space}} &
+\multicolumn{1}{c|}{\textbf{Lookup}} &
+\multicolumn{1}{c|}{\textbf{\# of network connections}} &
+\multicolumn{1}{c|}{\textbf{Notes}}
+\\ \hline
\endfirsthead
-\multicolumn{4}{c}%
+\multicolumn{6}{c}%
{{\tablename\ \thetable{} -- continued from previous page}} \\
-\hline \multicolumn{1}{|c|}{\textbf{Problem}} &
-\multicolumn{1}{c|}{\textbf{Problem description}} &
-\multicolumn{1}{c|}{\textbf{Solutions}} &
-\multicolumn{1}{c|}{\textbf{Comments/Status}}
+\hline
+\multicolumn{1}{|c|}{\textbf{Protocol}} &
+\multicolumn{1}{c|}{\textbf{Insert/Delete}} &
+\multicolumn{1}{c|}{\textbf{Space}} &
+\multicolumn{1}{c|}{\textbf{Lookup}} &
+\multicolumn{1}{c|}{\textbf{\# of network connections}} &
+\multicolumn{1}{c|}{\textbf{Notes}}
\\ \hline
\endhead
\endfoot
-
-\parbox{90pt}{Searching} &
-\parbox{110pt}{Efficient searching requires exploiting of previous queries} &
-\parbox{110pt}{View trees, bloom filters and its variations} &
-\parbox{110pt}{Effective, but not flexible}
-\\ \hline
-
-\parbox{90pt}{Efficient data discovery} &
-\parbox{110pt}{Find resources efficiently, if resource exists (broadcasting)} &
-\parbox{110pt}{Super nodes, node clusters, caching techiques} &
-\parbox{110pt}{More efficient, less network traffic, not comparable to DHT's
efficiency}
+\parbox{37pt}{CAN} &
+\parbox{37pt}{$O$($d$)} &
+\parbox{37pt}{$O$($d$)} &
+\parbox{37pt}{$O(dn^{\frac{1}{d}})$} &
+\parbox{85pt}{2$d$} &
+\parbox{85pt}{System's performance may decrease if nodes are not homogeneous
and nodes join and leave the system in a dynamic manner, where $d$ is the
dimension of virtual key space}
\\ \hline
-
-\parbox{90pt}{Richness of queries} &
-\parbox{110pt}{Query languages should be more powerful} &
-\parbox{110pt}{SQL-like queries} &
-\parbox{110pt}{Hard to implement, increases system complexity, not much
research has been done}
+\parbox{37pt}{Chord} &
+\parbox{37pt}{$O(\log^2{n})$} &
+\parbox{37pt}{$O(\log{n}$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{2$(\log{n})$} &
+\parbox{85pt}{System's performance may decrease if nodes are not homogeneous
and nodes join and leave the system in a dynamic manner}
\\ \hline
-\parbox{90pt}{Robustness} &
-\parbox{110pt}{How well system performs under hostile attacks/in the case of
severe failure ?} &
-\parbox{110pt}{Self-tuning, backup links, use diverse routing paths, power-law
networks/properties} &
-\parbox{110pt}{Working solutions}
+\parbox{37pt}{Freenet} &
+\parbox{37pt}{$O(1)$} &
+\parbox{37pt}{$O(1)$} &
+\parbox{37pt}{$O(n)$} &
+\parbox{85pt}{Typical configuration e.g., {4--150}} &
+\parbox{85pt}{Average lookup performance is $O(\log{n})$ with tens of
thousands concurrent users, beyond that, the performace is $O(n)$}
\\ \hline
-\parbox{90pt}{Quality of Service} &
-\parbox{110pt}{The system can only provide (at most) best effort services)} &
-\parbox{110pt}{Use network proximity for better network performance
(bandwidth, latency, jitter, packet loss)} &
-\parbox{110pt}{Increases system complexity, some initial experiences, need
more research}
+\parbox{37pt}{Gnutella} &
+\parbox{37pt}{$O(1)$} &
+\parbox{37pt}{$O(1)$} &
+\parbox{37pt}{$O(n)$} &
+\parbox{85pt}{Typical configuration is 5 connections (2*5=10 total), however,
depends on implementation} &
+\parbox{85pt}{Number of messages can grow as fast as $O(n^{2})$}
\\ \hline
-\parbox{90pt}{Data availability/persistency} &
-\parbox{110pt}{Data might be temporarily unavailable, or lost permanently} &
-\parbox{110pt}{Data caching, data replication} &
-\parbox{110pt}{Working solutions, but creates more traffic and overhead per
node}
+\parbox{37pt}{Kademlia} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{$2(\log{n})$} &
+\parbox{85pt}{There is no action required when nodes leaves the system}
\\ \hline
-\parbox{90pt}{Network proximity} &
-\parbox{110pt}{Can we take account the underlying network's properties better
when forming overlay network (network-awareness for performance) ?} &
-\parbox{110pt}{Global Network Positioning, Lighthouse technique, trianqulated
heuristics} &
-\parbox{110pt}{Increases system complexity, no real world experience in a wide
scale, proposed solutions are susceptible to single point of failure}
+\parbox{37pt}{Kelips} &
+\parbox{37pt}{$O(2(\sqrt{n}*(log^2{n})) + (\sqrt{n} + (log^3{n})))$} &
+\parbox{37pt}{$O$($\sqrt{n}$)} &
+\parbox{37pt}{$O(1)$} &
+\parbox{85pt}{$\frac{n}{\sqrt{n}} + c*(\sqrt{n}-1) + \frac{Totalnumber of
files}{\sqrt{n}}$, where n is the number of nodes and c the number of
contacts/foreign affinity group} &
+\parbox{85pt}{Insert/delete overhead is constant and performed background,
System's performance may decrease if nodes are not homogeneous and nodes join
and leave the system in a dynamic manner}
\\ \hline
-
-\parbox{90pt}{Locality} &
-\parbox{110pt}{Could DHTs exploit locality properties better ?} &
-\parbox{110pt}{Constrained Load Balancing, using network properties for
nearest neighbor selection, self-organizing clusters} &
-\parbox{110pt}{Working solutions}
+\parbox{37pt}{Koorde} &
+\parbox{37pt}{$O(\log^2{n})$} &
+\parbox{37pt}{$O(1)$ or $O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$ or $O(\frac{\log{n}}{\log{}\log{n}})$} &
+\parbox{85pt}{$2(\log{n})$} &
+\parbox{85pt}{Based on Chord protocol, uses de Bruijn graphs for better
efficiency/fault-tolerance}
\\ \hline
-
-\parbox{90pt}{Hotspots} &
-\parbox{110pt}{What will happen if some resource is extremely popular and only
one node is hosting it ?} &
-\parbox{110pt}{Caching, multisource downloads, replication, load balancing,
sloppy hashing} &
-\parbox{110pt}{For query hotspots, caching and multisource downloads
efficiently reduces hotspots, for routing hotspots, benefits are smaller}
+\parbox{37pt}{ODHDHT} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{$2(\log{n})$} &
+\parbox{85pt}{There are two lookup algorithms. The other is $O(\log{n})$,
which is robus under random deletion. The second is $O(\log^2{n})$, which is
also robust under spam generating model}
+\\ \hline
+
+
+\parbox{37pt}{Pastry} &
+\parbox{37pt}{$O(\log^2{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable
parameter for tuning digit-fixing properties (routing table)} &
+\parbox{85pt}{System's performance may decrease if nodes are not homogeneous
and nodes join and leave the system in a dynamic manner, based on Plaxton's
algorithm}
\\ \hline
-\parbox{90pt}{Scalability} &
-\parbox{110pt}{Broadcasting doesn't scale when performing searches} &
-\parbox{110pt}{Super peers, peer clusters, mutual index caching} &
-\parbox{110pt}{Better scalability, but not comparable to DHTs}
-\\ \hline
-
-\parbox{90pt}{Load balancing} &
-\parbox{110pt}{Random (but uniformly distributed) identifier selection could
cause systen imbalance among participants with different capabilities} &
-\parbox{110pt}{Caching, virtual server transfers} &
-\parbox{110pt}{Effective, more research required in fully dynamic environment}
-\\ \hline
-
-\parbox{90pt}{System in flux} &
-\parbox{110pt}{Nodes join and leave system constantly. What about load
balancing and performance ?} &
-\parbox{110pt}{Half-life phenomenon (for analysis), simple overlay maintenance
and construction protocol} &
-\parbox{110pt}{Initial theoretical analysis have been created, but not
comprehensive model for analysing different system states and its variations
(e.g. complex usage patterns)}
-\\ \hline
-
-
-\end{longtable}
-
-
-\begin{longtable}{|l|l|l|l|}
-\caption[Miscellaneous problems in P2P]{Miscellaneous problems in P2P}
\label{table_Miscellaneous_problems_p2p} \\
-
-
-\hline
-\multicolumn{1}{|c|}{\textbf{Problem}} &
-\multicolumn{1}{c|}{\textbf{Problem description}} &
-\multicolumn{1}{c|}{\textbf{Solutions}} &
-\multicolumn{1}{c|}{\textbf{Comments/Status}}
-\\ \hline
-\endfirsthead
-
-\multicolumn{4}{c}%
-{{\tablename\ \thetable{} -- continued from previous page}} \\
-\hline \multicolumn{1}{|c|}{\textbf{Problem}} &
-\multicolumn{1}{c|}{\textbf{Problem description}} &
-\multicolumn{1}{c|}{\textbf{Solutions}} &
-\multicolumn{1}{c|}{\textbf{Comments/Status}}
-\\ \hline
-\endhead
-
-\endfoot
-
-
-\parbox{90pt}{Sudden network partition} &
-\parbox{110pt}{Sub network is isolated from other network because of network
disconnection} &
-\parbox{110pt}{Self-tuning, environment observatorion, localized network
connection for minimun latency (backup connections)} &
-\parbox{110pt}{Creates more overhead/space requirements per node}
-\\ \hline
-
-\parbox{90pt}{Fail Stop} &
-\parbox{110pt}{A faulty node stops working} &
-\parbox{110pt}{Failure detectors, informing protocols} &
-\parbox{110pt}{Creates more network traffics, node's information can be
outdated, failure detectors not reliable}
+\parbox{37pt}{PeerNet} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{$O(\log{n})$} &
+\parbox{85pt}{Operates at network layer}
\\ \hline
-
-\parbox{90pt}{Byzantine faults} &
-\parbox{110pt}{Faulty nodes may behave arbitrarily} &
-\parbox{110pt}{Byzantine replication protocols -> get information from
multiple entities, trust majority's opinion} &
-\parbox{110pt}{Much research has been done on this field, practical solutions,
decreases system's, performance slighly}
+\parbox{37pt}{Plaxton} &
+\parbox{37pt}{No support} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{$O(\log{n})$} &
+\parbox{85pt}{Plaxton's algortihm is designed to operate in static environment
(e.g., web cache)}
\\ \hline
-
-\parbox{90pt}{Mutual distrust} &
-\parbox{110pt}{Nobody trusts anybody} &
-\parbox{110pt}{Reputation methods, key infrastructures} &
-\parbox{110pt}{Resource demanding, not practical to implement/not working
solutions, no real world experience in a wide scale}
+\parbox{37pt}{Skip Graphs} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{$4r(\log{n}) + (\log{n})$, where r=number of resources
provided)} &
+\parbox{85pt}{In this approach, node is treated as 'named resource'; in this
approach, \emph{resources} self-organise (opposite to DHTs)}
\\ \hline
-
-\parbox{90pt}{Lack of motivation to cooperate} &
-\parbox{110pt}{All participants do not behave like they should be, instead
they go for own profit} &
-\parbox{110pt}{Different reputation methods} &
-\parbox{110pt}{No real world experience in a wide scale}
+\parbox{37pt}{SkipNet} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{$2(\log{n})$} &
+\parbox{85pt}{Partially supports underlying network's locality properties}
\\ \hline
-
-\parbox{90pt}{Heterogeneity} &
-\parbox{110pt}{There are different kind of nodes in the system, in light of
bandwidth and computing power} &
-\parbox{110pt}{Super peers (broadcasting), cluster (broadcasting) additional
layer upon DHTs, structural simplicity (DHTs)} &
-\parbox{110pt}{Working solutions, increases system complexity (additional
layer)}
+\parbox{37pt}{Social} &
+\parbox{37pt}{$O(1)$} &
+\parbox{37pt}{$O(1)$} &
+\parbox{37pt}{$O(n)$} &
+\parbox{85pt}{Can be 1-10000 connections (aka social connections, connections
are permament)} &
+\parbox{85pt}{Connection number depends on node's memory/network capabilities}
\\ \hline
-
-\parbox{90pt}{Programming guidelines} &
-\parbox{110pt}{Set of programming guidelines/frameworks is needed for better
interoperability between different systems} &
-\parbox{110pt}{Common frameworks and APIs} &
-\parbox{110pt}{Common framework/API is still missing, a few proposals have
been made (DHTs)}
+\parbox{37pt}{Symphony} &
+\parbox{37pt}{$O(\log^2{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{$2k+2+f$, where k = long range connections, 2 = node's
neighbors, f = fault-tolerance connections)} &
+\parbox{85pt}{Space can be also $O(1)$. Additional space of $space^2$ can be
used as a lookahead list for better performance, not necessarily fault-tolerant
because of constant degree of neighbors}
\\ \hline
-
-\parbox{90pt}{Comprehensive simulations/analysis of peer-to-peer network} &
-\parbox{110pt}{Ability to simulate whole p2p network's usage patterns, network
traffics, flux state etc} &
-\parbox{110pt}{Use same techniques as simulating/analysing the Internet} &
-\parbox{110pt}{Only small subset of peer-to-peer networks has been able to
analyse, because of ad hoc properties of network, more poweful solutions needed}
+\parbox{37pt}{SWAN} &
+\parbox{37pt}{$O(1)$} &
+\parbox{37pt}{$O(1)$} &
+\parbox{37pt}{$O(\log^2{n})$} &
+\parbox{85pt}{$r(2b+2s+2l)$ (where r=number of resources provided, b=boot
connections, s=short range connections, l=long range connections), typical
connection configuration: 2*(6+7+8)=36} &
+\parbox{85pt}{In this approach, node is treated as 'named resource'; in this
approach, \emph{resources} self-organise (opposite to DHTs)}
\\ \hline
-\parbox{90pt}{Overlay management and health monitoring} &
-\parbox{110pt}{System is self-capable to monitor it's status and health for
better performance} &
-\parbox{110pt}{Build a metadata overlay atop of structured overlay (such as
SOMO for structured overlays), make local decisions about overlay
(unstrucured)} &
-\parbox{110pt}{For structured overlays, efficient and simple to implement,
fault-tolerance unknowns, for unstructured, not necessarily efficient because
decisions are based on local knowledge}
+\parbox{37pt}{Tapestry} &
+\parbox{37pt}{$O(\log^2{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable
parameter for tuning digit-fixing properties (routing table)} &
+\parbox{85pt}{System's performance may decrease if nodes are not homogeneous
and nodes join and leave the system in a dynamic manner, based on Plaxton's
algorithm}
\\ \hline
-\parbox{90pt}{Locating peer-to-peer network} &
-\parbox{110pt}{How old peers or new peers are able to locate peer-to-peer
network, if it exists} &
-\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com),
peer's history information} &
-\parbox{110pt}{Depends on implementation and purpose of the system, for mobile
ad hoc networks more research is needed}
+\parbox{37pt}{Viceroy} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{37pt}{$O(1)$} &
+\parbox{37pt}{$O(\log{n})$} &
+\parbox{85pt}{11} &
+\parbox{85pt}{System's performance may decrease if nodes are not homogeneous
and nodes join and leave the system in a dynamic manner, not necessarily
fault-tolerant because of constant degree of neighbors}
\\ \hline
\end{longtable}
+Insert/Delete:
+Number of messages when a node joins or leaves the network.
+
+Space:
+Space required for a node's neighbors
+Search:
+Number of messages when an object lookup is performed
+\subsection{Differences}
+\scriptsize
\begin{longtable}{|l|l|l|}
\caption[Comparison of Broadicasting and Structured approaches]{Comparison of
Broadicasting and Structured approaches}
\label{table_comparison_approach} \\
@@ -774,248 +551,495 @@
-\begin{longtable}{|l|c|c|c|c|l|}
-\caption[Different peer-to-peer lookup protocols]{Different peer-to-peer
lookup protocols}
-\label{table_p2p_protocols} \\
-\hline
-\multicolumn{1}{|c|}{\textbf{Protocol}} &
-\multicolumn{1}{c|}{\textbf{Insert/Delete}} &
-\multicolumn{1}{c|}{\textbf{Space}} &
-\multicolumn{1}{c|}{\textbf{Lookup}} &
-\multicolumn{1}{c|}{\textbf{\# of network connections}} &
-\multicolumn{1}{c|}{\textbf{Notes}}
-\\ \hline
-\endfirsthead
+\chapter{Open Problems in Peer-to-Peer}
-\multicolumn{6}{c}%
-{{\tablename\ \thetable{} -- continued from previous page}} \\
-\hline
-\multicolumn{1}{|c|}{\textbf{Protocol}} &
-\multicolumn{1}{c|}{\textbf{Insert/Delete}} &
-\multicolumn{1}{c|}{\textbf{Space}} &
-\multicolumn{1}{c|}{\textbf{Lookup}} &
-\multicolumn{1}{c|}{\textbf{\# of network connections}} &
-\multicolumn{1}{c|}{\textbf{Notes}}
-\\ \hline
-\endhead
+\section{Security problems in Peer-to-Peer}
-\endfoot
+\section{Miscellaneous problems in Peer-to-Peer}
-\parbox{37pt}{CAN} &
-\parbox{37pt}{$O$($d$)} &
-\parbox{37pt}{$O$($d$)} &
-\parbox{37pt}{$O(dn^{\frac{1}{d}})$} &
-\parbox{85pt}{2$d$} &
-\parbox{85pt}{System's performance may decrease if nodes are not homogeneous
and nodes join and leave the system in a dynamic manner, where $d$ is the
dimension of virtual key space}
-\\ \hline
+\section{Performance and usability problems in Peer-to-Peer}
-\parbox{37pt}{Chord} &
-\parbox{37pt}{$O(\log^2{n})$} &
-\parbox{37pt}{$O(\log{n}$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{2$(\log{n})$} &
-\parbox{85pt}{System's performance may decrease if nodes are not homogeneous
and nodes join and leave the system in a dynamic manner}
-\\ \hline
+\cite{harren02complex}
+\cite{ratnasamy02routing}
-\parbox{37pt}{Freenet} &
-\parbox{37pt}{$O(1)$} &
-\parbox{37pt}{$O(1)$} &
-\parbox{37pt}{$O(n)$} &
-\parbox{85pt}{Typical configuration e.g., 4-150} &
-\parbox{85pt}{Average lookup performance is $O(\log{n})$ with tens of
thousands concurrent users, beyond that, the performace is $O(n)$}
-\\ \hline
+\cite{hildrum02distributedobject}
+\cite{oram01harnessingpower}
-\parbox{37pt}{Gnutella} &
-\parbox{37pt}{$O(1)$} &
-\parbox{37pt}{$O(1)$} &
-\parbox{37pt}{$O(n)$} &
-\parbox{85pt}{Typical configuration is 5 connections (2*5=10 total), however,
depends on implementation} &
-\parbox{85pt}{Number of messages can grow as fast as $O(n^{2})$}
-\\ \hline
+\cite{sloppy:iptps03}
+\cite{yang02improvingsearch}
-\parbox{37pt}{Kademlia} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{$2(\log{n})$} &
-\parbox{85pt}{There is no action required when nodes leaves the system}
-\\ \hline
+\cite{daswani03openproblems}
+\cite{sit02securitycons}
-\parbox{37pt}{Kelips} &
-\parbox{37pt}{$O(2(\sqrt{n}*(log^2{n})) + (\sqrt{n} + (log^3{n})))$} &
-\parbox{37pt}{$O$($\sqrt{n}$)} &
-\parbox{37pt}{$O(1)$} &
-\parbox{85pt}{$\frac{n}{\sqrt{n}} + c*(\sqrt{n}-1) + \frac{Totalnumber of
files}{\sqrt{n}}$, where n is the number of nodes and c the number of
contacts/foreign affinity group} &
-\parbox{85pt}{Insert/delete overhead is constant and performed background,
System's performance may decrease if nodes are not homogeneous and nodes join
and leave the system in a dynamic manner}
-\\ \hline
+\cite{lv02searchreplication}
-\parbox{37pt}{Koorde} &
-\parbox{37pt}{$O(\log^2{n})$} &
-\parbox{37pt}{$O(1)$ or $O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$ or $O(\frac{\log{n}}{\log{}\log{n}})$} &
-\parbox{85pt}{$2(\log{n})$} &
-\parbox{85pt}{Based on Chord protocol, uses de Bruijn graphs for better
efficiency/fault-tolerance}
-\\ \hline
+\cite{libennowell01observations}
-\parbox{37pt}{ODHDHT} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{$2(\log{n})$} &
-\parbox{85pt}{There are two lookup algorithms. The other is $O(\log{n})$,
which is robus under random deletion. The second is $O(\log^2{n})$, which is
also robust under spam generating model}
-\\ \hline
-
-
-\parbox{37pt}{Pastry} &
-\parbox{37pt}{$O(\log^2{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable
parameter for tuning digit-fixing properties (routing table)} &
-\parbox{85pt}{System's performance may decrease if nodes are not homogeneous
and nodes join and leave the system in a dynamic manner, based on Plaxton's
algorithm}
-\\ \hline
+\cite{krishnamurthy01earlymeasurements}
+\cite{golle01incentivesp2p}
-\parbox{37pt}{PeerNet} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{$O(\log{n})$} &
-\parbox{85pt}{Operates at network layer}
-\\ \hline
+\cite{karger02findingnearest}
-\parbox{37pt}{Plaxton} &
-\parbox{37pt}{No support} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{$O(\log{n})$} &
-\parbox{85pt}{Plaxton's algortihm is designed to operate in static environment
(e.g., web cache)}
-\\ \hline
+\cite{cornelli02reputableservents}
-\parbox{37pt}{Skip Graphs} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{$4r(\log{n}) + (\log{n})$, where r=number of resources
provided)} &
-\parbox{85pt}{In this approach, node is treated as 'named resource'; in this
approach, \emph{resources} self-organise (opposite to DHTs)}
+\cite{aberer01trust}
+
+\cite{adamic02localsearch}
+
+\cite{adamic01powerlawsearch}
+
+\cite{saroiu02measurementstudyp2p}
+
+\cite{ripeanu02mappinggnutella}
+
+\cite{kronfol02fasdsearch}
+
+\cite{brinkmann02compactplacement}
+
+\cite{ajmani02conchord}
+
+\cite{362692}
+
+\cite{CuencaAcuna2002DSIWorkshop}
+
+\cite{reiter98crowds}
+
+\cite{352607}
+
+\cite{293447}
+
+\cite{tarzan:ccs9}
+
+\cite{pub00}
+
+\cite{rhea02probabilistic}
+
+\cite{502002}
+
+%dup
+\cite{castro02securitystructured}
+\cite{castro02securerouting}
+
+\cite{zhao02brocade}
+
+\cite{datar02butterflies}
+
+\cite{crespo02semanticoverlay}
+
+\cite{lv02gnutellascalable}
+
+\cite{keleher-02-p2p}
+
+\cite{saia02dynamicfaultcontentnetwork}
+
+\cite{yang02efficientsearch}
+
+%dup
+\cite{liben-nowell02observatorionsp2p}
+\cite{571863}
+
+\cite{lynch02atomicdataaccess}
+
+\cite{yang02comparinghybrid}
+
+\cite{ledlie02selfp2p}
+
+\cite{frise02p2pframework}
+
+\cite{joseph02p2players}
+
+\cite{andrzejak02rangequeries}
+
+\cite{babaoglu02anthill}
+
+\cite{fiat02censorship}
+
+\cite{hearn02mojonation}
+
+\cite{osokine02distnetworks}
+
+\cite{harvey03skipnet1}
+
+\cite{ansaryefficientbroadcast03}
+
+\cite{ng02predicting}
+
+\cite{douceur02sybil}
+
+\cite{castro02networkproximity}
+
+\cite{296824}
+
+\cite{juels99clientpuzzles}
+\cite{357176}
+
+\cite{grahamp2psecurity}
+
+\cite{zhao03api}
+
+\cite{nejdl03accesscontrol}
+
+\cite{bhagwan03availability}
+
+\cite{li03feasibility}
+
+\cite{zhang03somo}
+
+\cite{rao03loadbalancing}
+
+\cite{rhea03benchmarks}
+
+\cite{chord:om_p-meng}
+
+\section{Summary}
+
+\scriptsize
+\begin{longtable}{|l|l|l|l|}
+\caption[Security problems in Peer-to-Peer]{Security problems in Peer-to-Peer}
\label{table_security_problems_Peer-to-Peer} \\
+
+
+
+\hline
+\multicolumn{1}{|c|}{\textbf{Problem}} &
+\multicolumn{1}{c|}{\textbf{Problem description}} &
+\multicolumn{1}{c|}{\textbf{Solutions}} &
+\multicolumn{1}{c|}{\textbf{Comments/Status}}
+\\ \hline
+\endfirsthead
+
+\multicolumn{4}{c}%
+{{\tablename\ \thetable{} -- continued from previous page}} \\
+\hline \multicolumn{1}{|c|}{\textbf{Problem}} &
+\multicolumn{1}{c|}{\textbf{Problem description}} &
+\multicolumn{1}{c|}{\textbf{Solutions}} &
+\multicolumn{1}{c|}{\textbf{Comments/Status}}
+\\ \hline
+\endhead
+
+\endfoot
+
+
+
+\parbox{90pt}{Query routing} &
+\parbox{110pt}{Incorrect forwarding (hostile), incorrect routing (hostile)} &
+\parbox{110pt}{Query monitoring, cross check routing tables, verify routing
tables, create routing table invariants} &
+\parbox{110pt}{Increases system complexity}
\\ \hline
-\parbox{37pt}{SkipNet} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{$2(\log{n})$} &
-\parbox{85pt}{Partially supports underlying network's locality properties}
+
+\parbox{90pt}{DoS attack} &
+\parbox{110pt}{Distributed, controlled burden againts specific computer(s)} &
+\parbox{110pt}{Client puzzles, load balancing, traffic measurements, traffic
models, replication} &
+\parbox{110pt}{Only partial solutions, traffic models most effective}
+\\ \hline
+
+
+\parbox{90pt}{Sybil attack} &
+\parbox{110pt}{Single hostile entity present multiple entities} &
+\parbox{110pt}{Identify all nodes simultaneously across the system, collect
pool of nodes which are validated, distributed node ID creation} &
+\parbox{110pt}{Not practically realizable, research focused on persistence,
not on identity distinction}
+\\ \hline
+
+
+\parbox{90pt}{Spam attack} &
+\parbox{110pt}{Hostile entity creates false versions of data} &
+\parbox{110pt}{Do not trust to single entity, get information from multiple
entities, trust on majority's opinion} &
+\parbox{110pt}{Easy to implement, creates more network traffic}
\\ \hline
-\parbox{37pt}{Social} &
-\parbox{37pt}{$O(1)$} &
-\parbox{37pt}{$O(1)$} &
-\parbox{37pt}{$O(n)$} &
-\parbox{85pt}{Can be 1-10000 connections (aka social connections, connections
are permament)} &
-\parbox{85pt}{Connection number depends on node's memory/network capabilities}
+
+\parbox{90pt}{Resource spoofing} &
+\parbox{110pt}{Hostile entity gives wrong information about the data which
entity is responsible for/knows about} &
+\parbox{110pt}{Do not trust to single entity, get information from multiple
entities, trust on majority's opinion} &
+\parbox{110pt}{Easy to implement, creates more network traffic}
\\ \hline
-\parbox{37pt}{Symphony} &
-\parbox{37pt}{$O(\log^2{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{$2k+2+f$, where k = long range connections, 2 = node's
neighbors, f = fault-tolerance connections)} &
-\parbox{85pt}{Space can be also $O(1)$. Additional space of $space^2$ can be
used as a lookahead list for better performance, not necessarily fault-tolerant
because of constant degree of neighbors}
+
+\parbox{90pt}{Entity identification} &
+\parbox{110pt}{Identify participating entities reliably and efficiently
} &
+\parbox{110pt}{Digital signatures, key infrastructure} &
+\parbox{110pt}{Not practically realizable}
\\ \hline
-\parbox{37pt}{SWAN} &
-\parbox{37pt}{$O(1)$} &
-\parbox{37pt}{$O(1)$} &
-\parbox{37pt}{$O(\log^2{n})$} &
-\parbox{85pt}{$r(2b+2s+2l)$ (where r=number of resources provided, b=boot
connections, s=short range connections, l=long range connections), typical
connection configuration: 2*(6+7+8)=36} &
-\parbox{85pt}{In this approach, node is treated as 'named resource'; in this
approach, \emph{resources} self-organise (opposite to DHTs)}
+
+\parbox{90pt}{Data integrity/authenticity} &
+\parbox{110pt}{Integrity/originality of data is unknown} &
+\parbox{110pt}{Cryptographic content hashes, key architectures} &
+\parbox{110pt}{For data integrity, there are working solutions, but for data
authenticity, some of the solutions are partial, which may be practically
realizable}
\\ \hline
-\parbox{37pt}{Tapestry} &
-\parbox{37pt}{$O(\log^2{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable
parameter for tuning digit-fixing properties (routing table)} &
-\parbox{85pt}{System's performance may decrease if nodes are not homogeneous
and nodes join and leave the system in a dynamic manner, based on Plaxton's
algorithm}
+\parbox{90pt}{Anonymity} &
+\parbox{110pt}{Anonymity cannot be provided in all cases} &
+\parbox{110pt}{Remailers, pre-routing} &
+\parbox{110pt}{Total anonymity cannot be provided yet}
\\ \hline
-\parbox{37pt}{Viceroy} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{37pt}{$O(1)$} &
-\parbox{37pt}{$O(\log{n})$} &
-\parbox{85pt}{11} &
-\parbox{85pt}{System's performance may decrease if nodes are not homogeneous
and nodes join and leave the system in a dynamic manner, not necessarily
fault-tolerant because of constant degree of neighbors}
+
+\parbox{90pt}{Malicious nodes} &
+\parbox{110pt}{How to identify malicious nodes in the system} &
+\parbox{110pt}{Create invariants for node behaviour, verify invariants,
self-certifying data} &
+\parbox{110pt}{Partial solutions, self-certifying data most realiable}
+\\ \hline
+
+
+\parbox{90pt}{Access Control} &
+\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} &
+\parbox{110pt}{Schema-based rules} &
+\parbox{110pt}{Some initial experiences, need more research}
+\\ \hline
+
+
+\parbox{90pt}{Inconsistent behaviour} &
+\parbox{110pt}{Hostile node could act correctly with its neighbors, but
incorrectly with others} &
+\parbox{110pt}{Public keys, digital signatures} &
+\parbox{110pt}{Not practical approach/working proposal created yet}
+\\ \hline
+
+
+\parbox{90pt}{Hostile groups} &
+\parbox{110pt}{Joining node may join parallel network, formed a group of
hostile nodes, hostile node(s) controls the construction of the network} &
+\parbox{110pt}{Use trusted nodes, based on history information, Cryptography,
key infrastructure} &
+\parbox{110pt}{Not 100\% sure if Centreal Authority (CA) is missing, not
practical approach/working proposal created yet}
+\\ \hline
+
+
+\parbox{90pt}{External security threats} &
+\parbox{110pt}{Viruses, trojans, sniffers} &
+\parbox{110pt}{Data integrity/authenticity, distributed antivirus software} &
+\parbox{110pt}{Not much research has been done on this}
\\ \hline
\end{longtable}
-Insert/Delete:
-Number of messages when a node joins or leaves the network.
+
+
+
+
+\begin{longtable}{|l|l|l|l|}
+\caption[Performance and usability problems in Peer-to-Peer]{Performance and
usability problems in Peer-to-Peer}
\label{table_performanceusability_problems_Peer-to-Peer} \\
+
+
+\hline
+\multicolumn{1}{|c|}{\textbf{Problem}} &
+\multicolumn{1}{c|}{\textbf{Problem description}} &
+\multicolumn{1}{c|}{\textbf{Solutions}} &
+\multicolumn{1}{c|}{\textbf{Comments/Status}}
+\\ \hline
+\endfirsthead
+
+\multicolumn{4}{c}%
+{{\tablename\ \thetable{} -- continued from previous page}} \\
+\hline \multicolumn{1}{|c|}{\textbf{Problem}} &
+\multicolumn{1}{c|}{\textbf{Problem description}} &
+\multicolumn{1}{c|}{\textbf{Solutions}} &
+\multicolumn{1}{c|}{\textbf{Comments/Status}}
+\\ \hline
+\endhead
+
+\endfoot
+
+\parbox{90pt}{Searching} &
+\parbox{110pt}{Efficient searching requires exploiting of previous queries} &
+\parbox{110pt}{View trees, bloom filters and its variations} &
+\parbox{110pt}{Effective, but not flexible}
+\\ \hline
+
+
+\parbox{90pt}{Efficient data discovery} &
+\parbox{110pt}{Find resources efficiently, if resource exists (broadcasting)} &
+\parbox{110pt}{Super nodes, node clusters, caching techiques} &
+\parbox{110pt}{More efficient, less network traffic, not comparable to DHT's
efficiency}
+\\ \hline
+
+
+\parbox{90pt}{Richness of queries} &
+\parbox{110pt}{Query languages should be more powerful} &
+\parbox{110pt}{SQL-like queries} &
+\parbox{110pt}{Hard to implement, increases system complexity, not much
research has been done}
+\\ \hline
+
+
+\parbox{90pt}{Robustness} &
+\parbox{110pt}{How well system performs under hostile attacks/in the case of
severe failure ?} &
+\parbox{110pt}{Self-tuning, backup links, use diverse routing paths, power-law
networks/properties} &
+\parbox{110pt}{Working solutions}
+\\ \hline
+
+
+\parbox{90pt}{Quality of Service} &
+\parbox{110pt}{The system can only provide (at most) best effort services)} &
+\parbox{110pt}{Use network proximity for better network performance
(bandwidth, latency, jitter, packet loss)} &
+\parbox{110pt}{Increases system complexity, some initial experiences, need
more research}
+\\ \hline
+
+
+\parbox{90pt}{Data availability/persistency} &
+\parbox{110pt}{Data might be temporarily unavailable, or lost permanently} &
+\parbox{110pt}{Data caching, data replication} &
+\parbox{110pt}{Working solutions, but creates more traffic and overhead per
node}
+\\ \hline
+
+
+\parbox{90pt}{Network proximity} &
+\parbox{110pt}{Can we take account the underlying network's properties better
when forming overlay network (network-awareness for performance) ?} &
+\parbox{110pt}{Global Network Positioning, Lighthouse technique, trianqulated
heuristics} &
+\parbox{110pt}{Increases system complexity, no real world experience in a wide
scale, proposed solutions are susceptible to single point of failure}
+\\ \hline
+
+
+\parbox{90pt}{Locality} &
+\parbox{110pt}{Could DHTs exploit locality properties better ?} &
+\parbox{110pt}{Constrained Load Balancing, using network properties for
nearest neighbor selection, self-organizing clusters} &
+\parbox{110pt}{Working solutions}
+\\ \hline
+
+
+\parbox{90pt}{Hotspots} &
+\parbox{110pt}{What will happen if some resource is extremely popular and only
one node is hosting it ?} &
+\parbox{110pt}{Caching, multisource downloads, replication, load balancing,
sloppy hashing} &
+\parbox{110pt}{For query hotspots, caching and multisource downloads
efficiently reduces hotspots, for routing hotspots, benefits are smaller}
+\\ \hline
+
+
+\parbox{90pt}{Scalability} &
+\parbox{110pt}{Broadcasting doesn't scale when performing searches} &
+\parbox{110pt}{Super peers, peer clusters, mutual index caching} &
+\parbox{110pt}{Better scalability, but not comparable to DHTs}
+\\ \hline
+
+\parbox{90pt}{Load balancing} &
+\parbox{110pt}{Random (but uniformly distributed) identifier selection could
cause systen imbalance among participants with different capabilities} &
+\parbox{110pt}{Caching, virtual server transfers} &
+\parbox{110pt}{Effective, more research required in fully dynamic environment}
+\\ \hline
+
+\parbox{90pt}{System in flux} &
+\parbox{110pt}{Nodes join and leave system constantly. What about load
balancing and performance ?} &
+\parbox{110pt}{Half-life phenomenon (for analysis), simple overlay maintenance
and construction protocol} &
+\parbox{110pt}{Initial theoretical analysis have been created, but not
comprehensive model for analysing different system states and its variations
(e.g. complex usage patterns)}
+\\ \hline
+
+
+\end{longtable}
+
+
+
+
+\begin{longtable}{|l|l|l|l|}
+\caption[Miscellaneous problems in Peer-to-Peer]{Miscellaneous problems in
Peer-to-Peer} \label{table_Miscellaneous_problems_Peer-to-Peer} \\
+
+
+\hline
+\multicolumn{1}{|c|}{\textbf{Problem}} &
+\multicolumn{1}{c|}{\textbf{Problem description}} &
+\multicolumn{1}{c|}{\textbf{Solutions}} &
+\multicolumn{1}{c|}{\textbf{Comments/Status}}
+\\ \hline
+\endfirsthead
+
+\multicolumn{4}{c}%
+{{\tablename\ \thetable{} -- continued from previous page}} \\
+\hline \multicolumn{1}{|c|}{\textbf{Problem}} &
+\multicolumn{1}{c|}{\textbf{Problem description}} &
+\multicolumn{1}{c|}{\textbf{Solutions}} &
+\multicolumn{1}{c|}{\textbf{Comments/Status}}
+\\ \hline
+\endhead
+
+\endfoot
+
+
+\parbox{90pt}{Sudden network partition} &
+\parbox{110pt}{Sub network is isolated from other network because of network
disconnection} &
+\parbox{110pt}{Self-tuning, environment observatorion, localized network
connection for minimun latency (backup connections)} &
+\parbox{110pt}{Creates more overhead/space requirements per node}
+\\ \hline
+
+\parbox{90pt}{Fail Stop} &
+\parbox{110pt}{A faulty node stops working} &
+\parbox{110pt}{Failure detectors, informing protocols} &
+\parbox{110pt}{Creates more network traffics, node's information can be
outdated, failure detectors not reliable}
+\\ \hline
+
+
+\parbox{90pt}{Byzantine faults} &
+\parbox{110pt}{Faulty nodes may behave arbitrarily} &
+\parbox{110pt}{Byzantine replication protocols -> get information from
multiple entities, trust majority's opinion} &
+\parbox{110pt}{Much research has been done on this field, practical solutions,
decreases system's, performance slighly}
+\\ \hline
+
+
+\parbox{90pt}{Mutual distrust} &
+\parbox{110pt}{Nobody trusts anybody} &
+\parbox{110pt}{Reputation methods, key infrastructures} &
+\parbox{110pt}{Resource demanding, not practical to implement/not working
solutions, no real world experience in a wide scale}
+\\ \hline
+
+
+\parbox{90pt}{Lack of motivation to cooperate} &
+\parbox{110pt}{All participants do not behave like they should be, instead
they go for own profit} &
+\parbox{110pt}{Different reputation methods} &
+\parbox{110pt}{No real world experience in a wide scale}
+\\ \hline
+
+
+\parbox{90pt}{Heterogeneity} &
+\parbox{110pt}{There are different kind of nodes in the system, in light of
bandwidth and computing power} &
+\parbox{110pt}{Super peers (broadcasting), cluster (broadcasting) additional
layer upon DHTs, structural simplicity (DHTs)} &
+\parbox{110pt}{Working solutions, increases system complexity (additional
layer)}
+\\ \hline
+
+
+\parbox{90pt}{Programming guidelines} &
+\parbox{110pt}{Set of programming guidelines/frameworks is needed for better
interoperability between different systems} &
+\parbox{110pt}{Common frameworks and APIs} &
+\parbox{110pt}{Common framework/API is still missing, a few proposals have
been made (DHTs)}
+\\ \hline
+
+
+\parbox{90pt}{Comprehensive simulations/analysis of Peer-to-Peer network} &
+\parbox{110pt}{Ability to simulate whole Peer-to-Peer network's usage
patterns, network traffics, flux state etc} &
+\parbox{110pt}{Use same techniques as simulating/analysing the Internet} &
+\parbox{110pt}{Only small subset of Peer-to-Peer networks has been able to
analyse, because of ad hoc properties of network, more poweful solutions needed}
+\\ \hline
+
+
+\parbox{90pt}{Overlay management and health monitoring} &
+\parbox{110pt}{System is self-capable to monitor it's status and health for
better performance} &
+\parbox{110pt}{Build a metadata overlay atop of structured overlay (such as
SOMO for structured overlays), make local decisions about overlay
(unstrucured)} &
+\parbox{110pt}{For structured overlays, efficient and simple to implement,
fault-tolerance unknowns, for unstructured, not necessarily efficient because
decisions are based on local knowledge}
+\\ \hline
+
+\parbox{90pt}{Locating Peer-to-Peer network} &
+\parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer
network, if it exists} &
+\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com),
peer's history information} &
+\parbox{110pt}{Depends on implementation and purpose of the system, for mobile
ad hoc networks more research is needed}
+\\ \hline
+
+
+\end{longtable}
+
+
+
-Space:
-Space required for a node's neighbors
-Search:
-Number of messages when an object lookup is performed
-\begin{figure}
-\centering
-\includegraphics[width=10cm, height=8cm]{application_level_overlay.eps}
-\caption{P2P Application Level Overlay}
-\label{fig:application_level}
-\end{figure}
-\begin{figure}
-\centering
-\includegraphics[width=14cm, height=8cm]{structured_overlay.eps}
-%\includegraphics[width=14cm, height=8cm]{application_level_overlay.eps}
-\caption{Generation of structured overlay network}
-\label{fig:structured_hashing}
-\end{figure}
-\begin{figure}
-\centering
-\includegraphics[width=6cm, height=6cm]{gnutella_overlay.eps}
-\caption{Gnutella overlay network}
-\label{fig:gnutella_overlay}
-\end{figure}
-\begin{figure}
-\centering
-\includegraphics[width=8cm, height=6cm]{gnutella_overlay_supernodes.eps}
-\caption{Gnutella overlay network with super nodes}
-\label{fig:gnutella_overlay_supernodes}
-\end{figure}
-\begin{figure}
-\centering
-\includegraphics[width=10cm, height=6cm]{gnutella_overlay_clusters.eps}
-\caption{Gnutella overlay network with 2-redundant super node clusters}
-\label{fig:gnutella_overlay_cluster}
-\end{figure}
-\begin{figure}
-\centering
-\includegraphics[width=8cm, height=6cm]{gnutella_query.eps}
-\caption{Basic Gnutella query}
-\label{fig:gnutella_query}
-\end{figure}
-\begin{figure}
-\centering
-\includegraphics[width=8cm, height=6cm]{structured_query.eps}
-\caption{Simplified structured system's query}
-\label{fig:structured_query}
-\end{figure}
\begin{figure}
\centering
@@ -1032,25 +1056,26 @@
\end{figure}
-\chapter{Gzz System}
-
-\section{Overview of Gzz}
+\chapter{Overview of Gzz}
\section{Objectives}
-\section{Xanalogical model}
-
-\section{ZigZag hyperstructure}
+\cite{thompson01hypermedia}
+\cite{wiil02p2phypertext}
+\cite{bouvin02openhypermedia}
-\subsection{Cells}
+\section{Xanalogical model}
-\subsection{Dimensions}
+\cite{nelson99xanalogicalneeded}
\section{Storm}
-\subsection{Blocks}
+\cite{lukka02freenetguids}
+\subsection{Block storage}
+\cite{benja02urn5}
+\cite{balakrishnan03semanticfree}
\chapter{Evaluation of Peer-to-Peer for Gzz}
@@ -1062,10 +1087,14 @@
\section{Special needs}
+\cite{bittorrenturl}
+\cite{maymounkov03ratelesscodes}
+
\section{Existing file sharing systems and Gzz}
\section{Possible problems}
+\cite{gribble01p2pdatabase}
\chapter{Conclusion}
Index: gzz/Documentation/misc/hemppah-progradu/progradu.bib
diff -u gzz/Documentation/misc/hemppah-progradu/progradu.bib:1.73
gzz/Documentation/misc/hemppah-progradu/progradu.bib:1.74
--- gzz/Documentation/misc/hemppah-progradu/progradu.bib:1.73 Wed Feb 19
05:04:11 2003
+++ gzz/Documentation/misc/hemppah-progradu/progradu.bib Wed Feb 19
08:58:16 2003
@@ -193,7 +193,7 @@
%Problems related to p2p systems
@inproceedings{daswani03openproblems,
- author = {Daswani, Neil; Garcia-Molina, Hector; Yang, Beverly},
+ author = {Neil Daswani, Hector Garcia-Molina, Beverly Yang},
title = {Open Problems in Data-sharing Peer-to-peer Systems},
booktitle = {Proceedings of ICDT 2003},
abstract = { In a Peer-To-Peer (P2P) system, autonomous computers pool
their resources
@@ -228,6 +228,8 @@
howpublished = {http://www.shareaza.com}
}
+%WOW!
+
@misc{fasttrackurl,
key = {FastTrack},
title = {FastTrack},
@@ -542,7 +544,7 @@
%Search methods in p2p networks
@misc{adamic02localsearch,
- author = {Lada A. Adamic, Rajan M. Lukose, Bernardo A. Huberman},
+ author = {Lada A. Adamic and Rajan M. Lukose and Bernardo A. Huberman},
title = {Local Search in Unstructured Networks},
booktitle = {Review chapter to appear in: 'Handbook of Graphs and
Networks: From the Genome to the Internet},
year = {2002},
@@ -552,12 +554,14 @@
}
%Search methods in p2p networks (power law)
address@hidden,
- author = {Lada A. Adamic, Rajan M. Lukose, Amit R. Puniyani, Bernardo
A. Huberman},
- title = {Search in power-law networks},
- booktitle = {Phys. Rev. E 64, 046135},
address@hidden,
+ author = {Lada A. Adamic and Rajan M. Lukose and Amit R. Puniyani and
Bernardo A. Huberman},
+ title = {Search in power-law networks},
+ journal = {Physical Review E},
+ volume = {64},
+ number = {046135},
pages = {8},
- year = {2001},
+ year = {2001},
url = {http://www.hpl.hp.com/shl/papers/plsearch/PRE46135.pdf}
}
@@ -568,7 +572,7 @@
booktitle = {Proceedings of the Second Workshop on Infrastructure for
Agents, MAS and Scalable MAS at the Fourth International Conference on
Autonomous Agents (ICMAS2001)},
pages = {209-217},
year = {2001},
- url = {http://www.cs.cf.ac.uk/User/O.F.Rana/agents2001/
papers/13_gibbins_hall.pdf}
+ url =
{http://www.cs.cf.ac.uk/User/O.F.Rana/agents2001/papers/13_gibbins_hall.pdf}
}
%Analysis about p2p systems
@@ -591,7 +595,7 @@
isbn = {1-58113-099-6},
pages = {229--237},
location = {Atlanta, Georgia, United States},
- url = {http://www.cs.ucsd.edu/~savage/cse291/
papers/Harchol-Balter99.pdf},
+ url =
{http://www.cs.ucsd.edu/~savage/cse291/papers/Harchol-Balter99.pdf},
publisher = {ACM Press},
}
@@ -614,8 +618,7 @@
Volume = {6},
Number = {1},
Month = {Jan./Feb.},
- Year = {2002},
- Month = {Aug},
+ Year = {2002},
url = {http://www.cs.rice.edu/Conferences/IPTPS02/128.pdf}
}
@@ -631,11 +634,12 @@
}
%Search engine built on Freenet p2p system
address@hidden,
address@hidden,
author = {Amr Z. Kronfol},
- title = {FASD: A Fault-tolerant, Adaptive, Scalable, Distributed Search
Engine},
- year = {2002},
- howpublished = {http://freenetproject.org/twiki/Main/
FASD/kronfol_final_thesis.pdf}
+ title = {{FASD}: A Fault-tolerant, Adaptive, Scalable, Distributed
Search Engine},
+ school = {Princeton University},
+ month = {May},
+ year = {2002}
}
@@ -880,6 +884,7 @@
}
+%WOW!
%BitTorrent - tool
@misc{bittorrenturl,
key = {BitTorrent},
@@ -1011,7 +1016,7 @@
@inproceedings{gribble01p2pdatabase,
title = {What Can Peer-to-Peer Do for Databases, and Vice Versa?},
- author = {Steven Gribble, Alon Halevy, Zachary Ives, Maya Rodrig, and
Dan Suciu},
+ author = {Steven Gribble and Alon Halevy and Zachary Ives and Maya
Rodrig and Dan Suciu},
booktitle = {In Proceedings of the Fourth International Workshop on the
Web and Databases (WebDB'2001)},
year = {2001},
month = {may},
@@ -1024,7 +1029,7 @@
howpublished = {http://www.internet2.edu}
}
address@hidden dingledine00free,
address@hidden,
author = "Roger Dingledine and Michael J. Freedman and David Molnar",
title = "The Free Haven Project: Distributed Anonymous Storage Service",
booktitle = "Workshop on Design Issues in Anonymity and
Unobservability",
@@ -1047,7 +1052,7 @@
}
%Web anonymity
address@hidden reiter98crowds,
address@hidden,
author = "Michael K. Reiter and Aviel D. Rubin",
title = "Crowds: anonymity for {Web} transactions",
journal = "ACM Transactions on Information and System Security",
@@ -1086,7 +1091,7 @@
}
%Publius publishing system
address@hidden pub00,
address@hidden,
author = {Marc Waldman, Aviel D. Rubin and Lorrie Faith Cranor},
title = {Publius: A robust, tamper-evident, censorship-resistant,
web publishing system },
@@ -1120,7 +1125,7 @@
}
%The Small world problem
address@hidden adamic99small,
address@hidden,
author = "Lada A. Adamic",
title = "The Small World Web",
booktitle = "Proc. 3rd European Conf. Research and Advanced Technology
for Digital Libraries, {ECDL}",
@@ -1201,7 +1206,7 @@
%Security considerations for structured peer-to-peer overlay networks
@misc{castro02securitystructured,
title = "Security for structured peer-to-peer overlay networks",
- author = {M. Castro, P. Druschel, A. Ganesh, A. Rowstron, and D.
Wallach},
+ author = {M. Castro and P. Druschel and A. Ganesh and A. Rowstron and
and D. Wallach},
booktitle = {Fifth Symposium on Operating Systems Design and
Implementation (OSDI'02)},
location = {Boston, MA},
month = {December},
@@ -1342,14 +1347,14 @@
@inProceedings{saia02dynamicfaultcontentnetwork,
title = "Dynamically Fault-Tolerant Content Addressable Networks",
- author = "Jared Saia, Amos Fiat, Steven Gribble, Anna Karlin, Stefan
Saroiu",
+ author = "Jared Saia and Amos Fiat and Steven Gribble and Anna Karlin
and Stefan Saroiu",
booktitle = {The 1st International Workshop on Peer-to-Peer Systems
(IPTPS'02)},
month = {March},
year = {2002},
url = {http://www.cs.rice.edu/Conferences/IPTPS02/180.pdf}
}
address@hidden,
address@hidden,
title = "Efficient search in peer-to-peer networks.",
author = "Beverly Yang, Hector Garcia-Molina",
booktitle = {In Proceedings of the 22nd IEEE International Conference
on Distributed Computing Systems (ICDCS)},
@@ -1367,7 +1372,7 @@
url = {http://www.cs.rice.edu/Conferences/IPTPS02/187.pdf}
}
address@hidden,
address@hidden,
title = "Atomic Data Access in Content Addressable Networks",
author = "Nancy Lynch, Dahlia Malkhi and David Ratajczak",
booktitle = {The 1st International Workshop on Peer-to-Peer Systems
(IPTPS'02)},
@@ -1399,7 +1404,7 @@
@inProceedings{ledlie02selfp2p,
title = "Self-Organization in Peer-to-Peer Systems",
- author = "Jonathan Ledlie, Jacob Taylor, Laura Serban, Margo Seltzer",
+ author = "Jonathan Ledlie and Jacob Taylor and Laura Serban and Margo
Seltzer",
booktitle = {In Proceedings of the 10th ACM SIGOPS European Workshop},
location = {Saint-?milion, France},
month = {September},
@@ -1408,7 +1413,7 @@
}
@inProceedings{castro02securerouting,
- author = {Miguel Castro, Peter Druschel, Ayalvadi Ganesh, Antony
Rostron, Dan S. Wallach},
+ author = {Miguel Castro and Peter Druschel and Ayalvadi Ganesh and
Antony Rostron and Dan S. Wallach},
title = {Secure Routing for Structured Peer-to-Peer Overlay Networks},
booktitle = {Proceedings of the 5th Usenix Symposium on Operating
Systems Design and Implementation},
location = {Boston, MA},
@@ -1417,8 +1422,9 @@
url = {http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf}
}
+%WOW!
@inProceedings{frise02p2pframework,
- author = {T. Friese, B. Freisleben, S. Rusitschka, A. Southhall},
+ author = {T. Friese and B. Freisleben and S. Rusitschka and A.
Southhall},
title = {A Framework for Resource Management in Peer-to-Peer Networks},
booktitle = {In the Proceedings of NetObjectdays 2002},
month = {October},
@@ -1427,7 +1433,7 @@
}
@inProceedings{schlosser-scalable,
- author = "Mario Schlosser, Michael Sintek, Stefan Decker, Wolfgang
Nejdl",
+ author = "Mario Schlosser and Michael Sintek and Stefan Decker and
Wolfgang Nejdl",
title = "A Scalable and Ontology-Based P2P Infrastructure for Semantic
Web Services",
booktitle = "In Proceedings of the Second IEEE International Conference
on Peer-to-Peer Computing (P2P2002)",
month = {September},
@@ -1517,15 +1523,15 @@
@misc{urn-5,
key = {urn-5 namespace},
- title = {urn-5 namespace}
+ title = {urn-5 namespace},
howpublished = {http://www.iana.org/assignments/urn-informal/urn-5}
}
@inproceedings{AspnesS2003,
title="Skip Graphs",
author="James Aspnes and Gauri Shah",
- booktitle="Fourteenth Annual ACM-SIAM Symposium on Discrete Algorithms".
- month={12--14~} #jan,
+ booktitle="Fourteenth Annual ACM-SIAM Symposium on Discrete Algorithms",
+ month={12--14~},
year="2003",
address={Baltimore, MD, USA},
}
@@ -1574,14 +1580,6 @@
publisher = {ACM Press},
}
address@hidden,
- author = {Bryce Wilcox-O'Hearn},
- title = {Experiences Deploying a Large-Scale Emergent Network},
- booktitle = {The 1st International Workshop on Peer-to-Peer Systems
(IPTPS'02)},
- month = {March},
- year = {2002},
- url = {http://www.cs.rice.edu/Conferences/IPTPS02/188.pdf}
-}
@misc{osokine02distnetworks,
author = {Serguei Osokine},
@@ -1620,7 +1618,7 @@
@inproceedings{harvey03skipnet1,
- author = {Nicholas J. A. Harvey, Michael B. Jones, Marvin Theimer, Alec
Wolman},
+ author = {Nicholas J. A. Harvey and Michael B. Jones and Marvin Theimer
and Alec Wolman},
title = {Efficient Recovery From Organizational Disconnects in SkipNet},
booktitle = {The 2nd International Workshop on Peer-to-Peer Systems
(IPTPS'03)},
month = {Mar},
@@ -1629,7 +1627,7 @@
}
@inproceedings{ansaryefficientbroadcast03,
- author = {Sameh El-Ansary, Luc Onana Alima, Per Brand, Seif Haridi},
+ author = {Sameh El-Ansary and Luc Onana Alima and Per Brand and Seif
Haridi},
title = {Efficient Broadcast in Stuctured P2P Networks},
booktitle = {The 2nd International Workshop on Peer-to-Peer Systems
(IPTPS'03)},
month = {Mar},
@@ -1638,7 +1636,7 @@
}
@inproceedings{harvey03skipnet2,
- author = {Nicholas J.A. Harvey, Michael B. Jones, Stefan Saroiu, Marvin
Theimer, Alec Wolman},
+ author = {Nicholas J.A. Harvey and Michael B. Jones and Stefan Saroiu
and Marvin Theimer and Alec Wolman},
title = {SkipNet: A Scalable Overlay Network with Practical Locality
Properties},
booktitle = {In proceedings of the 4th USENIX Symposium on Internet
Technologies and System (USITS '03)},
month = {March},
@@ -1693,7 +1691,7 @@
}
@inproceedings{pias03lighthouse,
- author = {Marcelo Pias, Jon Crowcroft, Steve Wilbur, Tim Harris, Saleem
Bhatti},
+ author = {Marcelo Pias and Jon Crowcroft and Steve Wilbur and Tim
Harris and Saleem Bhatti},
title = {Lighthouses for Scalable Distributed Location},
booktitle = {The 2nd International Workshop on Peer-to-Peer Systems
(IPTPS'03)},
month = {February},
@@ -1711,7 +1709,7 @@
}
@inproceedings{gupta03kelips,
- author = {Indranil Gupta, Ken Birman, Prakash Linga, Al Demers, Robbert
van Renesse},
+ author = {Indranil Gupta and Ken Birman and Prakash Linga and Al Demers
and Robbert van Renesse},
title = {Kelips: Building an Efficient and Stable P2P DHT Through
Increased Memory and Background Overhead},
booktitle = {The 2nd International Workshop on Peer-to-Peer Systems
(IPTPS'03)},
month = {February},
@@ -1747,7 +1745,7 @@
}
@techreport{castro02networkproximity,
- author = {Miguel Castro, Peter Druschel, Y. Charlie Hu, Antony
Rowstron},
+ author = {Miguel Castro and Peter Druschel and Y. Charlie Hu and Antony
Rowstron},
title = {Exploiting network proximity in peer-to-peer overlay networks},
number = {MSR-TR-2002-82},
institution = {Microsoft Research},
@@ -1798,7 +1796,7 @@
}
@misc{zhao03api,
- author = "Frank Dabek, Ben Zhao, Peter Druschel, Ion Stoica",
+ author = "Frank Dabek and Ben Zhao and Peter Druschel and Ion Stoica",
title = "A Common API for Structured Peer to Peer Overlays",
howpublished = "Talk at OceanStore/ROC/Sahara Winter Retreat",
month = jan,
@@ -1808,11 +1806,11 @@
%Schema based access control
@misc{nejdl03accesscontrol,
- author = {Wolfgang Nejdl, Wolf Siberski, Martin Wolpers, Alexander
Löser},
+ author = {Wolfgang Nejdl and Wolf Siberski and Martin Wolpers and
Alexander Löser},
title = {Information Integration in Schema-Based Peer-To-Peer Networks},
booktitle = {Submitted at the 15th Conference On Advanced Information
Systems Engineering(CAiSE)},
year = {2003},
- location = {Klagenfurt/Velden Austria}
+ location = {Klagenfurt/Velden Austria},
howpublished =
{http://cis.cs.tu-berlin.de/~aloeser/gk/publications/Caise03_submission_Loeser_Nejdl_Wolpers_Siberski.PDF}
}
@@ -1836,7 +1834,7 @@
}
@inproceedings{li03feasibility,
- author = {Jinyang Li, Boon Thau Loo, Joe Hellerstein, Frans Kaashoek,
David R. Karger, Robert Morris},
+ author = {Jinyang Li and Boon Thau Loo and Joe Hellerstein and Frans
Kaashoek and David R. Karger and Robert Morris},
title = {On the Feasibility of Peer-to-Peer Web Indexing and Search},
booktitle = {The 2nd International Workshop on Peer-to-Peer Systems
(IPTPS'03)},
month = {February},
@@ -1872,7 +1870,7 @@
}
@inproceedings{rao03loadbalancing,
- author = {Ananth Rao, Karthik Lakshminarayanan, Sonesh Surana, Richard
Karp, Ion Stoica},
+ author = {Ananth Rao and Karthik Lakshminarayanan and Sonesh Surana and
Richard Karp and Ion Stoica},
title = {Load Balancing in Structured P2P Systems},
booktitle = {The 2nd International Workshop on Peer-to-Peer Systems
(IPTPS'03)},
month = {February},
@@ -1889,14 +1887,6 @@
url = {http://iptps03.cs.berkeley.edu/final-papers/benchmark.ps}
}
address@hidden,
- author = {Michael Freedman, David Mazieres},
- title = {Sloppy hashing and self-organizing clusters},
- booktitle = {The 2nd International Workshop on Peer-to-Peer Systems
(IPTPS'03)},
- month = {February},
- year = {2003},
- url = {http://iptps03.cs.berkeley.edu/final-papers/coral.pdf}
-}
@inproceedings{debruijn46graph,
author = {N.G. Bruijn},
@@ -1916,7 +1906,7 @@
}
@article{balakrishanarticle03lookupp2p,
- author = {Hari Balakrishnan, M. Frans Kaashoek, David Karger, Robert
Morris, Ion Stoica},
+ author = {Hari Balakrishnan and M. Frans Kaashoek and David Karger and
Robert Morris and Ion Stoica},
title = {Looking up data in P2P systems},
journal = {Communications of the ACM},
volume = {46},
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., (continued)
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/13
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/13
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/13
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/14
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/14
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/17
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/17
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/18
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/19
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/19
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...,
Hermanni Hyytiälä <=
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/19
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/21
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/24