[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/06 05:08:39

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

Log message:
        System proposal

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.120&tr2=1.121&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.120 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.121
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.120      Thu Mar 
 6 04:16:41 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Thu Mar  6 
05:08:37 2003
@@ -1723,9 +1723,9 @@
 see \cite{lukka02freenetguids}, and for detailed Storm design, see 
\cite{fallenstein03storm}.
 
 Storm (for \emph{STORage Module}) is a software module, which is used in 
Fenfire for
-implementing basic data storage operations. Storm stores all data as 
\emph{scroll blocks}, which
+implementing basic data storage operations. Storm stores all data as 
\emph{blocks}, which
 are immutable byte sequences. SHA-1\footnote{SHA-1 is considered a collision 
free 
-hash function. Therefore, it is very unlikely that two different Storm scroll 
blocks 
+hash function. Therefore, it is very unlikely that two different Storm data 
blocks 
 would have same identifier.} cryptographic content hash \cite{fips-sha-1} is 
used
 for creating locatiotion-independent, globally unique identifiers for blocks. 
Additionally,
 SHA-1 \cite{fips-sha-1} is used for verifying the integrity of scroll blocks. 
Storm
@@ -1874,33 +1874,64 @@
 overlays \cite{projectirisurl}.
 
       
-\section{Algorithm proposals}
+\section{Fenfire system model in Peer-to-Peer enviroment}
 
-In this section we propose yet simple but effective algorithms for obtaining 
Fenfire data from
-Peer-to-Peer environment. In the following subsections we assume that we know 
the structure of 
-''virtual file'' before hand, i.e. when assmbling a ''virtual file'', we know 
all Storm 
-scroll/pointer blocks, which are required when building the ''virtual file''. 
Also, we don't 
-respond to security issues related to Peer-to-Peer systems, since there is no 
working solution
-available yet; we either assume that Fenfire has a reliable techique for 
identifying invidual entities, or
-there are no hostile entities among participating peers.
+In this section present a proposal of Fenfire Peer-to-Peer system, which 
consists 
+of several techologies presented in this thesis.  Then, we introduce yet 
simple but 
+effective algorithms for obtaining Fenfire data from Peer-to-Peer environment. 
+ 
+\subsection{System proposal}
 
-\subsection{System model}
+We see Kademlia \cite{maymounkov02kademlia} as the best algorithm for
+locating data efficiently in the Peer-to-Peer overlay. There are two main
+reasons for this. First, Kamdelia's XOR-based distance function is superior
+over the distance functions of other systems. Second, there are already some 
+real-life systems (e.g., \cite{overneturl}, \cite{edonkey2kurl}, 
\cite{kashmirurl}), 
+which means that Kademlia's algorithm is simple and easy to implement.
+
+In top of Kademlia, we propose the usage of Sloppy hashing 
\cite{sloppy:iptps03} which
+optimized for DOLR abstraction of tightly structured overlays. With Sloppy 
hashing, 
+we are able reduce of generation of query hotspots. Sloppy hashing enables to 
+locate nearby data without looking up data from distant nodes. Moreover, 
authors' 
+proposal for self-organizing clusters using network diameters may be useful, 
+especially within small groups of working people. Thus, with Sloppy hashing
+we can provide locality properties for Fenfire.
+
+For better fault tolerance and self-monitoring for Fenfire, we propose 
techniques
+presented by Rowston et al. \cite{rowston03controlloingreliability}.  With 
these 
+techniques, we can ensure the performance of Fenfire in a highly adverse 
environment, such
+as extreme heterogeneous, higly dynamic environment or network partition.
+
+Finally, for more efficient data transfer, we can use variable techniques for 
this purpose.
+For small amounts of data, HTTP can be used \cite{rfc2068}. For big downloads, 
we can use
+multisource downloads for better efficiency and reliability. Specifically, 
techology based
+on rateless erasure codes \cite{maymounkov03ratelesscodes} seems very 
promising.
+
+\subsection{Algorithms}
 
 We use DOLR model of tightly of structured approach, i.e. each participating 
peer hosts 
 the data and overlay maintains only the \emph{pointers} to the data. We 
descided to use DOLR in our
 model, since DOLR systems locate date without specifiying a storage policy 
explicity \cite{rhea03benchmarks}. 
 DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST 
\cite{rowstron01storage}, have
-critical problems with load balancing in highly heterogeneous environment. 
This is caused by peers which may not able
-to store relative great amount of data with key/value pair, assigned randomly 
by mapping function of the overlay. 
+critical problems with load balancing in highly heterogeneous environment. 
This problem is caused by peers 
+which may not able to store relative great amount of data with key/value pair, 
assigned randomly by 
+mapping function of the overlay. Additionally, these systems wastes both 
storage and bandwidth, and
+are sensitive to certain attacks (e.g., DDoS attack).
+
+In the following subsections we assume that we know the structure of 
+''virtual file'' before hand, i.e. when assmbling a ''virtual file'', we know 
all Storm 
+scroll/pointer blocks, which are required when building the ''virtual file''. 
Also, we don't 
+respond to security issues related to Peer-to-Peer systems, since there is no 
working solution
+available yet; we either assume that Fenfire has a reliable techique for 
identifying invidual entities, or
+there are no hostile entities among participating peers. 
 
 In our model, each peer maintains following data structures for local 
operations: data structure for listing all 
 key/value-pairs which peer maintains; data structure for listing all 
key/value-pair in 
 chronological order (the most recent block is topmost) which peer maintains. 
We use Storm blocks' identifiers
 as \emph{keys} of the overlay. Every key/value-pairs consists of either a hash 
of pointer random string 
 (pointer blocks), or a hash of block's content (scroll blocks) as a key. Value 
is always a reference to a hosting 
-peer (e.g. IP address). Finally, we assume that all local operations can be 
done in a constant time.
-
-\subsection{Algorithms}
+peer (e.g. IP address). We use Kademlia's \cite{maymounkov02kademlia} algorihm 
for locating data in the overlay. 
+Finally, we assume that all local operations can be done in a constant time.
 
 
 \begin{itemize}
@@ -1943,7 +1974,7 @@
 in a tightly structured overlay using DOLR method, where urn-5 is known.
 
 Each of these algortihms can locate Fenfire related data in $\Theta(\log{n})$ 
time:
-$(\log{n})$ time for query routing to pointer peer and constant time for 
+$O(\log{n})$ time for query routing to pointer peer and constant time for 
 locating hosting peer with a given reference link. Time required for 
transferring
 the data is not included.
 
@@ -1962,6 +1993,8 @@
 \label{fig:storm_query_urn5}
 \end{figure}
 
+
+
 \chapter{Open issues and future work}
 
 One of the most important issues in Peer-to-Peer networks is the fact that
@@ -1975,6 +2008,8 @@
 based computer systems. However, we believe this problem is solved in a near 
 future as Peer-to-Peer networks will come more and more important in 
 computing world.
+
+-benefis over p2p filesharing programs
 
 -'get me block XYZ'
 -there is no reply, how do we are able to know if this was a spam attack, or 
the