/[gzz]/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
ViewVC logotype

Diff of /gzz/Documentation/misc/hemppah-progradu/masterthesis.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.120 by hemppah, Thu Mar 6 09:16:41 2003 UTC revision 1.121 by hemppah, Thu Mar 6 10:08:37 2003 UTC
# Line 1723  from recent publications: for general di Line 1723  from recent publications: for general di
1723  see \cite{lukka02freenetguids}, and for detailed Storm design, see \cite{fallenstein03storm}.  see \cite{lukka02freenetguids}, and for detailed Storm design, see \cite{fallenstein03storm}.
1724    
1725  Storm (for \emph{STORage Module}) is a software module, which is used in Fenfire for  Storm (for \emph{STORage Module}) is a software module, which is used in Fenfire for
1726  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
1727  are immutable byte sequences. SHA-1\footnote{SHA-1 is considered a collision free  are immutable byte sequences. SHA-1\footnote{SHA-1 is considered a collision free
1728  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
1729  would have same identifier.} cryptographic content hash \cite{fips-sha-1} is used  would have same identifier.} cryptographic content hash \cite{fips-sha-1} is used
1730  for creating locatiotion-independent, globally unique identifiers for blocks. Additionally,  for creating locatiotion-independent, globally unique identifiers for blocks. Additionally,
1731  SHA-1 \cite{fips-sha-1} is used for verifying the integrity of scroll blocks. Storm  SHA-1 \cite{fips-sha-1} is used for verifying the integrity of scroll blocks. Storm
# Line 1874  solved, since there is a strong and wide Line 1874  solved, since there is a strong and wide
1874  overlays \cite{projectirisurl}.  overlays \cite{projectirisurl}.
1875    
1876                
1877  \section{Algorithm proposals}  \section{Fenfire system model in Peer-to-Peer enviroment}
1878    
1879  In this section we propose yet simple but effective algorithms for obtaining Fenfire data from  In this section present a proposal of Fenfire Peer-to-Peer system, which consists
1880  Peer-to-Peer environment. In the following subsections we assume that we know the structure of  of several techologies presented in this thesis.  Then, we introduce yet simple but
1881  ''virtual file'' before hand, i.e. when assmbling a ''virtual file'', we know all Storm  effective algorithms for obtaining Fenfire data from Peer-to-Peer environment.
1882  scroll/pointer blocks, which are required when building the ''virtual file''. Also, we don't  
1883  respond to security issues related to Peer-to-Peer systems, since there is no working solution  \subsection{System proposal}
 available yet; we either assume that Fenfire has a reliable techique for identifying invidual entities, or  
 there are no hostile entities among participating peers.  
1884    
1885  \subsection{System model}  We see Kademlia \cite{maymounkov02kademlia} as the best algorithm for
1886    locating data efficiently in the Peer-to-Peer overlay. There are two main
1887    reasons for this. First, Kamdelia's XOR-based distance function is superior
1888    over the distance functions of other systems. Second, there are already some
1889    real-life systems (e.g., \cite{overneturl}, \cite{edonkey2kurl}, \cite{kashmirurl}),
1890    which means that Kademlia's algorithm is simple and easy to implement.
1891    
1892    In top of Kademlia, we propose the usage of Sloppy hashing \cite{sloppy:iptps03} which
1893    optimized for DOLR abstraction of tightly structured overlays. With Sloppy hashing,
1894    we are able reduce of generation of query hotspots. Sloppy hashing enables to
1895    locate nearby data without looking up data from distant nodes. Moreover, authors'
1896    proposal for self-organizing clusters using network diameters may be useful,
1897    especially within small groups of working people. Thus, with Sloppy hashing
1898    we can provide locality properties for Fenfire.
1899    
1900    For better fault tolerance and self-monitoring for Fenfire, we propose techniques
1901    presented by Rowston et al. \cite{rowston03controlloingreliability}.  With these
1902    techniques, we can ensure the performance of Fenfire in a highly adverse environment, such
1903    as extreme heterogeneous, higly dynamic environment or network partition.
1904    
1905    Finally, for more efficient data transfer, we can use variable techniques for this purpose.
1906    For small amounts of data, HTTP can be used \cite{rfc2068}. For big downloads, we can use
1907    multisource downloads for better efficiency and reliability. Specifically, techology based
1908    on rateless erasure codes \cite{maymounkov03ratelesscodes} seems very promising.
1909    
1910    \subsection{Algorithms}
1911    
1912  We use DOLR model of tightly of structured approach, i.e. each participating peer hosts  We use DOLR model of tightly of structured approach, i.e. each participating peer hosts
1913  the data and overlay maintains only the \emph{pointers} to the data. We descided to use DOLR in our  the data and overlay maintains only the \emph{pointers} to the data. We descided to use DOLR in our
1914  model, since DOLR systems locate date without specifiying a storage policy explicity \cite{rhea03benchmarks}.  model, since DOLR systems locate date without specifiying a storage policy explicity \cite{rhea03benchmarks}.
1915  DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST \cite{rowstron01storage}, have  DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST \cite{rowstron01storage}, have
1916  critical problems with load balancing in highly heterogeneous environment. This is caused by peers which may not able  critical problems with load balancing in highly heterogeneous environment. This problem is caused by peers
1917  to store relative great amount of data with key/value pair, assigned randomly by mapping function of the overlay.  which may not able to store relative great amount of data with key/value pair, assigned randomly by
1918    mapping function of the overlay. Additionally, these systems wastes both storage and bandwidth, and
1919    are sensitive to certain attacks (e.g., DDoS attack).
1920    
1921    In the following subsections we assume that we know the structure of
1922    ''virtual file'' before hand, i.e. when assmbling a ''virtual file'', we know all Storm
1923    scroll/pointer blocks, which are required when building the ''virtual file''. Also, we don't
1924    respond to security issues related to Peer-to-Peer systems, since there is no working solution
1925    available yet; we either assume that Fenfire has a reliable techique for identifying invidual entities, or
1926    there are no hostile entities among participating peers.
1927    
1928  In our model, each peer maintains following data structures for local operations: data structure for listing all  In our model, each peer maintains following data structures for local operations: data structure for listing all
1929  key/value-pairs which peer maintains; data structure for listing all key/value-pair in  key/value-pairs which peer maintains; data structure for listing all key/value-pair in
1930  chronological order (the most recent block is topmost) which peer maintains. We use Storm blocks' identifiers  chronological order (the most recent block is topmost) which peer maintains. We use Storm blocks' identifiers
1931  as \emph{keys} of the overlay. Every key/value-pairs consists of either a hash of pointer random string  as \emph{keys} of the overlay. Every key/value-pairs consists of either a hash of pointer random string
1932  (pointer blocks), or a hash of block's content (scroll blocks) as a key. Value is always a reference to a hosting  (pointer blocks), or a hash of block's content (scroll blocks) as a key. Value is always a reference to a hosting
1933  peer (e.g. IP address). Finally, we assume that all local operations can be done in a constant time.  peer (e.g. IP address). We use Kademlia's \cite{maymounkov02kademlia} algorihm for locating data in the overlay.
1934    Finally, we assume that all local operations can be done in a constant time.
 \subsection{Algorithms}  
1935    
1936    
1937  \begin{itemize}  \begin{itemize}
# Line 1943  Figure \ref{fig:storm_query_urn5} illust Line 1974  Figure \ref{fig:storm_query_urn5} illust
1974  in a tightly structured overlay using DOLR method, where urn-5 is known.  in a tightly structured overlay using DOLR method, where urn-5 is known.
1975    
1976  Each of these algortihms can locate Fenfire related data in $\Theta(\log{n})$ time:  Each of these algortihms can locate Fenfire related data in $\Theta(\log{n})$ time:
1977  $(\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
1978  locating hosting peer with a given reference link. Time required for transferring  locating hosting peer with a given reference link. Time required for transferring
1979  the data is not included.  the data is not included.
1980    
# Line 1962  the data is not included. Line 1993  the data is not included.
1993  \label{fig:storm_query_urn5}  \label{fig:storm_query_urn5}
1994  \end{figure}  \end{figure}
1995    
1996    
1997    
1998  \chapter{Open issues and future work}  \chapter{Open issues and future work}
1999    
2000  One of the most important issues in Peer-to-Peer networks is the fact that  One of the most important issues in Peer-to-Peer networks is the fact that
# Line 1976  based computer systems. However, we beli Line 2009  based computer systems. However, we beli
2009  future as Peer-to-Peer networks will come more and more important in  future as Peer-to-Peer networks will come more and more important in
2010  computing world.  computing world.
2011    
2012    -benefis over p2p filesharing programs
2013    
2014  -'get me block XYZ'  -'get me block XYZ'
2015  -there is no reply, how do we are able to know if this was a spam attack, or the  -there is no reply, how do we are able to know if this was a spam attack, or the
2016  data really no exist in the system ?  data really no exist in the system ?

Legend:
Removed from v.1.120  
changed lines
  Added in v.1.121

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26