[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: |
Fri, 28 Feb 2003 05:24:54 -0500 |
CVSROOT: /cvsroot/gzz
Module name: gzz
Changes by: Hermanni Hyytiälä <address@hidden> 03/02/28 05:24:51
Modified files:
Documentation/misc/hemppah-progradu: masterthesis.tex
Log message:
Chapters 1 and ready. Abstract ready, future work and open issues
ready, conclusions ready.
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.95&tr2=1.96&r1=text&r2=text
Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.95
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.96
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.95 Fri Feb
28 04:09:15 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex Fri Feb 28
05:24:51 2003
@@ -520,21 +520,39 @@
\section{Summary}
-Measures:
-
-degree:
-
-hop count:
-
-fault-tolerance
-
-maintenance overhead
-
-load balance
-
+In this section we compare loosely structured approach and tightly structured
approach.
+We also summarize proposed Peer-to-Peer algorithms and their key properties
with regard
+to performance and scalability aspects.
\subsection{Differences}
+Even loosely structured and tightly structured approach are both Peer-to-Peer
schemes, they
+have very little in common. Indeed, the only thing they share is the fact that
no other peer is more
+important than other peer in the Peer-to-Peer network. Fault tolerance
\emph{may} may
+be an area, in which approaches have similar properties (e.g., single point of
failure).
+However, both approaches' fault-tolerance properties are currently only
initial calculations, or
+experimented in simulation environments. In real-life, measuring fault
tolerance is much more
+challenging task and requires more research to get reliable answers.
+
+Thus, there are significant differences between loosely structured and tightly
structured approaches.
+The most important aspect is the performance and scalability. While loosely
structured approach's performance
+is not always even linear, generally tightly structured approach can perform
all operations in
+$\Theta(\log{n})$\footnote{However, it is unknown whether all proposed
algorithms can preserve
+logarithmic properties in real-life applications or not.}.
+
+Another key point is the philosophy how overlay network is constructed and
maintained. While loosely
+structured approach gives much freedom to invidual peers to join and leave the
overlay network, tightly
+structured approach has certain features, in which participating peers have no
control at all
+(such as mapping of data items).
+
+To end user, biggest difference between these systems is how data lookups are
performed. Looselely
+structured systems provides much more richier and user friendly way of
searching data as they
+have support for keyword search and fuzzy search. On the other, tightly
structured systems support
+only exact key lookups as each data item is identified by unique keys.
+
+In the end, both systems have open problems and issues. We will discuss these
aspect more detail in
+chapter 3. Table \ref{table_comparison_approach} lists key differences between
loosely structured
+approach and tightly structured approach.
\scriptsize
@@ -543,8 +561,8 @@
\hline
\multicolumn{1}{|c|}{\textbf{Property}} &
-\multicolumn{1}{c|}{\textbf{Unstructured}} &
-\multicolumn{1}{c|}{\textbf{Structured}}
+\multicolumn{1}{c|}{\textbf{Loosely structured}} &
+\multicolumn{1}{c|}{\textbf{Tightly structured}}
\\ \hline
\endfirsthead
@@ -562,12 +580,18 @@
+\parbox{90pt}{Construction of overlay} &
+\parbox{100pt}{Uncontrolled} &
+\parbox{100pt}{Controlled}
+
+\\ \hline
+
\parbox{90pt}{Queries} &
\parbox{100pt}{Uncontrolled} &
\parbox{100pt}{Controlled}
\\ \hline
-\parbox{90pt}{A way for performing queries} &
+\parbox{90pt}{A way for performing data lookups} &
\parbox{100pt}{Keywords} &
\parbox{100pt}{Exact keys}
\\ \hline
@@ -634,11 +658,34 @@
\subsection{Algorithms}
+Table \ref{table_Peer-to-Peer_protocols} lists proposed Peer-to-Peer
algorithms
+and their key properties with regard to performance and scalability. List
+includes algorithms from two main approaches. However, majority of the
algorithms
+listed above belongs to tightly structured approach since there has been
active
+research being pursued lately. List doesn't include \emph{all} proposed
Peer-to-Peer
+systems, only the ones which already have been widely deployed in real-life, or
+the ones which may promising in the future's Peer-to-Peer systems.
+
+We decided to follow the guidelines from \cite{kaashoek03koorde} when
+measuring properties of different Peer-to-Peer systems. However, we dropped
+out fault tolerance and load balancing properties, since they are hard to
measure
+in face of real life requirements. Additionally, we decided to include
+the number of real network connections for each peer in the overlay.
+
+Here, we describe the listed properties of Peer-to-Peer algorihms:
+
+\begin{itemize}
+\item \textbf{Lookup}: Number of messages required when a data lookup is
performed
+\item \textbf{Space}: Number of neighbors which peers knows about (neighbors)
+\item \textbf{Insert/delete}: Number of messages required when a peer joins or
leaves the network
+ \item \textbf{Number of network connections}: Number of concurrent
\emph{network} connections required to maintain correct neighbor information
+\end{itemize}
+
\scriptsize
\begin{longtable}{|l|c|c|c|c|l|}
\hline
-\multicolumn{1}{|c|}{\textbf{Protocol}} &
+\multicolumn{1}{|c|}{\textbf{Algorithm}} &
\multicolumn{1}{c|}{\textbf{Insert/Delete}} &
\multicolumn{1}{c|}{\textbf{Space}} &
\multicolumn{1}{c|}{\textbf{Lookup}} &
@@ -813,10 +860,7 @@
\\ \hline
-\caption{Different Peer-to-Peer lookup protocols. In this table $n$ is the
number of peers in the system.
-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. Number of
network connections: number of concurrent
-network connections required to maintain correct neighbor information}
+\caption{Different Peer-to-Peer lookup protocols. In this table $n$ is the
number of peers in the system.}
\label{table_Peer-to-Peer_protocols}
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., (continued)
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/26
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/27
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/27
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/27
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/27
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/27
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/27
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/27
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/27
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/28
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...,
Hermanni Hyytiälä <=
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/28
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/28
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/02/28