[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: |
Thu, 06 Mar 2003 05:08:41 -0500 |
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
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., (continued)
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/05
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/05
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/05
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/05
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/05
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/05
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/05
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/06
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...,
Hermanni Hyytiälä <=
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/06
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/06
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/06
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/06
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/07
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/07
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/07
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/12
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/12
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/12