[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/03/25 06:41:06

Modified files:
        Documentation/misc/hemppah-progradu: masterthesis.tex 
Added files:
        Documentation/misc/hemppah-progradu: method_overview.eps 

Log message:
        Obtain Storm block from the overlay: new figure

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/method_overview.eps?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.183&tr2=1.184&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.183 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.184
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.183      Tue Mar 
25 04:29:56 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Tue Mar 25 
06:41:05 2003
@@ -1880,15 +1880,15 @@
 Also, we don't respond to the security issues related to Peer-to-Peer systems, 
since there is no working solution
 available yet. Thus, we either assume that Fenfire has a reliable technique 
for identifying individual entities, or
 there are no hostile entities among participating peers, i.e.,  Storm blocks 
can be identified correctly (e.g., when
-performing searches). In the next section, we discuss security problems in 
more detail. 
+performing searches). In the next subsection, we discuss security problems in 
more detail. 
 
 
 \begin{itemize}
 \item Data lookup with a given identifier of Storm scroll block.
 \begin{enumerate}
 \item Submit the data lookup using scroll block's identifier.
-\item Each peer forwards the data lookup to a closer peer which hosts the 
given scroll block identifier in the overlay.
-\item The pointer peer returns value (e.g., the IP address of provider peer) 
to the query originator.
+\item Each peer forwards the data lookup to a closer peer which hosts the 
given scroll block identifier instructed by the overlay.
+\item The pointer peer returns value (e.g., the IP address of provider peer) 
to the query originator throughout the overlay.
 \item The query originator requests the provider peer to return the scroll 
block.
 \end{enumerate}
 \end{itemize}
@@ -1898,8 +1898,8 @@
 \item Data lookup with a given pointer returning most recent scroll block.
 \begin{enumerate}
 \item The query originator locally computes a hash over given pointer.
-\item Each peer forwards the data lookup to a closer peer which hosts the 
given hash of pointer in the overlay.
-\item The pointer peer returns most recent pointer block's key-value pair 
(e.g., the IP address of provider peer) to the query originator, using pointer 
block's own indexing schemes. 
+\item Each peer forwards the data lookup to a closer peer which hosts the 
given hash of pointer instructed by the overlay.
+\item The pointer peer returns most recent pointer block's key-value pair 
(e.g., the IP address of provider peer) to the query originator, using pointer 
block's own indexing schemes throughout the overlay. 
 \item The query originator requests the provider peer to return the scroll 
block.
 \end{enumerate}
 \end{itemize}
@@ -1908,8 +1908,8 @@
 \item Data lookup with a given pointer returning scroll block(s) for a given 
date or time range.
 \begin{enumerate}
 \item The query originator locally computes a hash over given pointer.
-\item Each peer forwards the data lookup to a closer peer which hosts the 
given hash of pointer in the overlay.
-\item Pointer peer returns pointer block's key-value pair(s) (e.g., the IP 
address of provider peer) to the query originator, using pointer block's own 
indexing schemes. 
+\item Each peer forwards the data lookup to a closer peer which hosts the 
given hash of pointer instructed by the overlay.
+\item Pointer peer returns pointer block's key-value pair(s) (e.g., the IP 
address of provider peer) to the query originator, using pointer block's own 
indexing schemes throughout the overlay. 
 \item The query originator requests the provider peer to return the scroll 
block.
 \end{enumerate}
 \end{itemize}
@@ -1917,28 +1917,34 @@
 
 Each of these algorithms can locate Fenfire blocks in $O(\log{n})$ time at 
application level overlay:
 $O(\log{n})$ time for query routing to pointer peer (Kademlia 
\cite{maymounkov02kademlia}) and constant time for 
-locating hosting peer with a given reference link.
+locating hosting peer with a given reference link. Figure 
\ref{fig:method_overview} illustrates the overall
+process of obtaining Storm block from the the tightly structured overlay using 
the DOLR abstraction.
+
+\begin{figure}
+\centering
+\includegraphics[width=12cm, height=8cm]{method_overview.eps}
+\caption{Method for obtaining Storm block from the tightly structured overlay 
using the DOLR abstraction.}
+\label{fig:method_overview}
+\end{figure}
 
 \subsection{Problems}
 
 Perhaps the most biggest issue in Peer-to-Peer systems is the non-maturity of
-security technologies. For instance, online entities cannot be identified 
-safely (e.g., the Sybil attack \cite{douceur02sybil}). For the Fenfire system, 
one
-security related problem occurs when a user wants to perform a global data 
lookup with a given
-pointer; how the user is able to verify the correctness
-of the search results, i.e.,  how she or he knows which one is the 
-correct Storm scroll block ? The Spam attack \cite{naor03simpledht} is a 
variation of previously
-mentioned problem; data lookup is performed by a user, but there is no reply
-from the system. How are we able to know if this was a spam attack, or the
-data really doesn't exist in the system ? Another problem related to the 
Fenfire's 
+security technologies. For the Fenfire system, one security related problem 
occurs when a user wants to 
+perform a global data lookup with a given pointer; how the user is able to 
verify 
+the correctness of the search results, i.e.,  how she or he knows which one is 
the 
+correct Storm scroll block ? Another problem related to the Fenfire's 
 security is that if a user downloads data from the network to local computer 
 and after a network disconnection, user wants to verify \emph{off line} the 
-authenticity of data. Obviously, optimal solution to all security issues would 
-be that digital signatures are included to every message sent to the system 
therefore 
-enabling peers to authenticate other peers safely. However, these problems are 
not 
-only limited to the Fenfire system as it concerns all Peer-to-Peer computer 
systems.
-
-As security technologies come more mature, we wish to apply these 
+authenticity of data. Finally, if a data lookup is performed by a user, but 
there is no reply
+from the Fenfire system, how are we able to know if this was the Spam attack 
\cite{naor03simpledht}, 
+or the data really doesn't exist in the system ?  
+However, these problems are not only limited to the Fenfire system as it 
+concerns all Peer-to-Peer computer systems.   
+
+Obviously, optimal solutions to all security issues would be that digital 
+signatures are included to every message which are sent to the system or the 
use of working PKI-based 
+certificate distribution. As security technologies come more mature, we wish 
to apply these 
 technologies with Fenfire, if applicable.
 
 \chapter{Conclusions and future work}
@@ -1948,24 +1954,21 @@
 we are able to classify \emph{all} systems either to loosely or tightly 
structured systems.  
 We have summarized open problems in Peer-to-Peer research domain. 
Specifically, we divided open 
 problems into the three sub-categories: security related problems,
-performance related problems and miscellaneous problems.  We point out that 
each of these
-sub-categories have number of open problems, in which there are no solutions
-yet, or solutions are only partial. 
+performance related problems and miscellaneous problems. 
 
-Then, we focused our attention to the Fenfire system. First, we gave a brief
-overview of the Fenfire system and xanalogical storage model. We also 
described Storm software module.
+Then we gave a brief overview of the Fenfire system and xanalogical storage 
model. We also 
+described Storm software module.
 
 In the last chapter, we evaluated existing Peer-to-Peer approaches with regard
 to Fenfire's needs. We see that the tightly structured approach is the
-best alternative to Fenfire's needs for the following reasons. First, Storm, 
xanalogical
-storage model and tightly structured systems use global unique identifiers
-for identifying data. Second, our Storm design uses \emph{semantic-free 
references} 
-(block identifiers and pointer random strings) for locating data in 
distributed 
+best alternative to Fenfire's needs for the following reasons. First, our 
Storm design uses \emph{semantic-free references} 
+(block identifiers and pointers) for locating data in distributed 
 networks. As the authors of \cite{balakrishnan03semanticfree},
 we also agree that references should be semantically-free in next-generation 
-reference resolution services. Third, by using 
-the DOLR abstraction of tightly structured overlay, we can minimize the lack 
-of locality in the tightly structured approach. Finally, we believe that 
issues 
+reference resolution services. Second, by using 
+the DOLR abstraction of tightly structured overlay and Sloppy hashing , we can 
+minimize the lack of locality in the tightly structured approach, i.e., we are 
able to locate nearby 
+data without looking up data from distant peers. Third, we believe that issues 
 related to tightly structured overlays are solved in the near future, because 
of
 wide and intensive co-operation among research groups.
 
@@ -1977,7 +1980,7 @@
 regarding Peer-to-Peer and database systems have already been
 presented in \cite{gribble01p2pdatabase}.  
 
-In the following months, we will implement a Fenfire Peer-to-Peer prototype. 
+We will implement a Fenfire Peer-to-Peer prototype in the near future. 
 
 \bibliographystyle{gradu}
 \bibliography{progradu}