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 |
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} |
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 |
|
|
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 |
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 ? |