[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...

[Hermanni Hyytiälä]

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}