888 |
approach. However, people often misunderstand the scalability problem of loosely structured |
approach. However, people often misunderstand the scalability problem of loosely structured |
889 |
approach; \emph{network} of loosely structured systems is scalable, but the \emph{query model} is not. |
approach; \emph{network} of loosely structured systems is scalable, but the \emph{query model} is not. |
890 |
The main concern of tightly structured system is to make overlay's data lookup |
The main concern of tightly structured system is to make overlay's data lookup |
891 |
routing more flexible againts hostile attacks. Another key problems in tightly structured |
routing more flexible againts hostile attacks. Another key problem in tightly structured |
892 |
approach are the lack of keyword searches and support for heterogeneous peers. |
approach are the lack of keyword searches and support for heterogeneous peers. |
893 |
|
|
894 |
To make Peer-to-Peer systems even more popular (e.g., in industry), Peer-to-Peer domain |
To make Peer-to-Peer systems even more popular (e.g., in industry), Peer-to-Peer domain |
927 |
Spam generating attack is another known attack model againts Peer-to-Peer system. In Spam |
Spam generating attack is another known attack model againts Peer-to-Peer system. In Spam |
928 |
attack, hostile or faulty peer may produce false information of the data. Possible solution againts this attack |
attack, hostile or faulty peer may produce false information of the data. Possible solution againts this attack |
929 |
is that peer should not trust to single entity. Instead peer should get information from multiple entities and trust |
is that peer should not trust to single entity. Instead peer should get information from multiple entities and trust |
930 |
on majority's opinion. However, Spam attack is combined with Sybil attack, obviously previously mentioned solution |
on majority's opinion. This methods requires more messages to be sent to network increasing the load of system. |
931 |
won't work. Again, more research is required to solve this attack model reliability. Naor et al. \cite{naor03simpledht} |
However, if Spam attack is combined with Sybil attack, obviously previously mentioned solution doesn't work. |
932 |
has proposed a partial solution againts Spam attack with \emph{faulty} peers (not hostile). |
Again, more research is required to solve this attack model reliability. Naor et al. \cite{naor03simpledht} has |
933 |
|
proposed a partial solution againts Spam attack with \emph{faulty} peers (not hostile). |
934 |
|
|
935 |
Traditional overload of targeted peers is best known form of distrubuted Denial of Service attack (DDoS). For example, |
Traditional overload of targeted peers is best known form of distrubuted Denial of Service attack (DDoS). For example, |
936 |
hostile entity can attempt to burden targetted peers with garbage packets. As a implication, peers may act |
hostile entity can attempt to burden targetted peers with garbage packets. As a implication, peers may act |
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{scroll blocks}, which |
1727 |
are immutable byte sequences. SHA-1 cryptographic content hash \cite{fips-sha-1} is used |
are immutable byte sequences. SHA-1\footnote{SHA-1 is considered a collision free |
1728 |
for creating locatiotion-independent, globally unique identifiers for blocks. Storm |
hash function. Therefore, it is very unlikely that two different Storm scroll blocks |
1729 |
|
would have same identifier.} cryptographic content hash \cite{fips-sha-1} is used |
1730 |
|
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 |
1732 |
blocks have much in common with regular files, except Storm blocks are \emph{immutable} as |
blocks have much in common with regular files, except Storm blocks are \emph{immutable} as |
1733 |
any change to the byte sequence would the change block's hash value, i.e., unique |
any change to the byte sequence would the change block's hash value, i.e., unique |
1734 |
identifier. This mechanism creates a basis for implementing xanalogical model in our |
identifier. This mechanism creates a basis for implementing xanalogical model in our |
1787 |
In the xanalogical storage model, each fragment of data is identified by a globally |
In the xanalogical storage model, each fragment of data is identified by a globally |
1788 |
unique identifier. In Fenfire, data fragments are scroll blocks, generated by Storm storage module. |
unique identifier. In Fenfire, data fragments are scroll blocks, generated by Storm storage module. |
1789 |
As we discussed already in chapter 4, Fenfire's Storm design |
As we discussed already in chapter 4, Fenfire's Storm design |
1790 |
uses SHA-1 \footnote{SHA-1 is considered a collision free hash function. Therefore, it is |
uses SHA-1 \cite{fips-sha-1} hash over the contents of a scroll block for creating globally unique |
|
very unlikely that two different Storm scroll blocks would have same identifier.} |
|
|
\cite{fips-sha-1} hash over the contents of a scroll block for creating globally unique |
|
1791 |
identifiers for each scroll block. In our scenario, fragments of data is distributed |
identifiers for each scroll block. In our scenario, fragments of data is distributed |
1792 |
throughout the Peer-to-Peer overlay. Our task is to locate and fetch |
throughout the Peer-to-Peer overlay. Our task is to locate and fetch |
1793 |
(i.e. obtain) \emph{all} Storm scroll blocks, associated to a specific ''virtual |
(i.e. obtain) \emph{all} Storm scroll blocks, associated to a specific ''virtual |
1820 |
participants responded whether Peer-to-Peer systems are suitable for hypermedia |
participants responded whether Peer-to-Peer systems are suitable for hypermedia |
1821 |
publishing or not. |
publishing or not. |
1822 |
|
|
|
In the following sections 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. We assume that Fenfire has a reliable techique for identifying invidual entities, or |
|
|
there are no hostile entities among participating peers. |
|
|
|
|
|
|
|
1823 |
\section{Evaluation of Peer-to-Peer approaches with regard to Fenfire} |
\section{Evaluation of Peer-to-Peer approaches with regard to Fenfire} |
1824 |
|
|
1825 |
In chapter 2 we discussed main differences between loosely and tightly structured |
In chapter 2, we discussed main differences between loosely and tightly structured |
1826 |
approaches. As stated, the most significant difference is that tighly structured |
approaches. As stated, the most significant difference is that tighly structured |
1827 |
approach has logarithmical properties in all interal operations, while loosely |
approach has logarithmical properties in all interal operations, while loosely |
1828 |
structured approach doesn't have always even linear properties. Furthermore, the |
structured approach doesn't have always even linear properties. Furthermore, the |
1844 |
application-independent and references itself should be \emph{unstructured} and |
application-independent and references itself should be \emph{unstructured} and |
1845 |
\emph{semantic free}. To summarize, these aspects may be the most important features |
\emph{semantic free}. To summarize, these aspects may be the most important features |
1846 |
of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} hypermedia system. |
of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} hypermedia system. |
1847 |
Thus, we see the tightly structured approach the best alternative to Fenfire's |
Thus, we see the tightly structured approach the best alternative to locate data in Peer-to-Peer |
1848 |
needs. |
environment. |
1849 |
|
|
1850 |
Once located, for \emph{fetching} Fenfire related data from the overlay, we can use reqular |
Once located, for \emph{fetching} Fenfire related data from the overlay, we can use reqular |
1851 |
TCP/IP-protocols, such as Hypertext Transfer protocol (HTTP) \cite{rfc2068}. However, HTTP-protocol may |
TCP/IP-protocols, such as Hypertext Transfer protocol (HTTP) \cite{rfc2068}. However, HTTP-protocol may |
1863 |
other source.}, such as \cite{merkle87hashtree} and \cite{mohr02thex} for reliable and efficient |
other source.}, such as \cite{merkle87hashtree} and \cite{mohr02thex} for reliable and efficient |
1864 |
data validation. |
data validation. |
1865 |
|
|
1866 |
Currently, there are open issues with tightly structured systems which have to be |
Again, there are open issues with tightly structured systems which have to be |
1867 |
addressed, as described in chapter 3. The main concerns include decreased performance and fault |
addressed, as described in chapter 3. The main concerns include decreased performance and fault |
1868 |
tolerance when system in flux-state, non-optimal distance functions in identifier space, |
tolerance when system in flux-state, non-optimal distance functions in identifier space, |
1869 |
proximity routing, hostile entities and flexible search \cite{balakrishanarticle03lookupp2p}. |
proximity routing, hostile entities and flexible search \cite{balakrishanarticle03lookupp2p}. |
1874 |
overlays \cite{projectirisurl}. |
overlays \cite{projectirisurl}. |
1875 |
|
|
1876 |
|
|
1877 |
\section{Analysis} |
\section{Algorithm proposals} |
1878 |
|
|
1879 |
|
In this section we propose yet simple but effective algorithms for obtaining Fenfire data from |
1880 |
|
Peer-to-Peer environment. In the following subsections we assume that we know the structure of |
1881 |
|
''virtual file'' before hand, i.e. when assmbling a ''virtual file'', we know all Storm |
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 |
1884 |
|
available yet; we either assume that Fenfire has a reliable techique for identifying invidual entities, or |
1885 |
|
there are no hostile entities among participating peers. |
1886 |
|
|
1887 |
In this section we analyse the costs of locating Storm block with a given identifier |
\subsection{System model} |
|
and urn-5 random string. |
|
1888 |
|
|
1889 |
\subsection{Assumptions} |
We use DOLR model of tightly of structured approach, i.e. each participating peer hosts |
1890 |
In our analysis, we use tightly structured ovelay's DOLR method. Each peer hosts the data, |
the data and overlay maintains only the \emph{pointers} to the data. We descided to use DOLR in our |
1891 |
overlay maintains only the \emph{pointers} to the data. Furthermore, each peer maintains |
model, since DOLR systems locate date without specifiying a storage policy explicity \cite{rhea03benchmarks}. |
1892 |
following data structures for local operations: one data structure for listing all |
DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST \cite{rowstron01storage}, have |
1893 |
key/value-pairs; one data structure for listing all key/value-pair in chronological order |
critical problems with load balancing in highly heterogeneous environment. This is caused by peers which may not able |
1894 |
(the most recent block is topmost). Every key/value-pairs consists of a hash of urn-5 |
to store relative great amount of data with key/value pair, assigned randomly by mapping function of the overlay. |
1895 |
random string (pointer blocks) or a hash of block's content (scroll blocks) as a key. |
|
1896 |
Value is always a reference to a hosting peer (e.g. IP-address). Finally, we assume |
In our model, each peer maintains following data structures for local operations: data structure for listing all |
1897 |
that all local operations can be done in a constant time. |
key/value-pairs which peer maintains; data structure for listing all key/value-pair in |
1898 |
|
chronological order (the most recent block is topmost) which peer maintains. We use Storm blocks' identifiers |
1899 |
|
as \emph{keys} of the overlay. Every key/value-pairs consists of either a hash of pointer random string |
1900 |
|
(pointer blocks), or a hash of block's content (scroll blocks) as a key. Value is always a reference to a hosting |
1901 |
|
peer (e.g. IP address). Finally, we assume that all local operations can be done in a constant time. |
1902 |
|
|
1903 |
\subsection{Algorithms} |
\subsection{Algorithms} |
1904 |
|
|
1905 |
|
|
1906 |
\begin{itemize} |
\begin{itemize} |
1907 |
\item Data lookup with a given scroll block's identifier |
\item Data lookup with a given identifier of Storm scroll block. |
1908 |
\begin{enumerate} |
\begin{enumerate} |
1909 |
\item Submit query using scroll block's identifier |
\item Submit query using scroll block's identifier. |
1910 |
\item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given scroll block identifier |
\item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given scroll block identifier. |
1911 |
\item Pointer peer returns most recent pointer block's value (e.g., hosting peer's IP-address) to query originator |
\item Pointer peer returns most recent pointer block's value (e.g., hosting peer's IP-address) to query originator. |
1912 |
\item Query originator requests hosting node to return the scroll block |
\item Query originator requests hosting node to return the scroll block. |
1913 |
\end{enumerate} |
\end{enumerate} |
1914 |
\end{itemize} |
\end{itemize} |
1915 |
|
|
1916 |
Figure \ref{fig:storm_query_blockid} illustrates how scroll block is located |
Figure \ref{fig:storm_query_blockid} illustrates how Storm scroll block is located |
1917 |
in a tightly structured overlay using DOLR method, where scroll block's |
in a tightly structured overlay using DOLR method, where identifier of Storm scroll |
1918 |
identifier is known. |
block is known. |
1919 |
|
|
1920 |
|
|
1921 |
\begin{itemize} |
\begin{itemize} |
1922 |
\item Data lookup with a given urn-5 random string returning most recent scroll block |
\item Data lookup with a given pointer random string returning most recent scroll block. |
1923 |
\begin{enumerate} |
\begin{enumerate} |
1924 |
|
\item Query originator locally compute a hash for given urn-5 random string. |
1925 |
\item Query originator locally compute a hash for given urn-5 random string |
\item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of pointer random string. |
1926 |
\item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of urn-5 |
\item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP-address) to query originator, using pointer block's own indexing schemes. |
1927 |
\item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP-address) to query originator, using pointer block's own indexing schemes |
\item Query originator requests hosting node to return the scroll block. |
|
\item Query originator requests hosting node to return the scroll block |
|
1928 |
\end{enumerate} |
\end{enumerate} |
1929 |
\end{itemize} |
\end{itemize} |
1930 |
|
|
1931 |
\begin{itemize} |
\begin{itemize} |
1932 |
\item Data lookup with a given urn-5 random string returning scroll block(s) for a given date and time range |
\item Data lookup with a given pointer random string returning scroll block(s) for a given date and time range. |
1933 |
\begin{enumerate} |
\begin{enumerate} |
1934 |
|
|
1935 |
\item Query originator locally compute a hash for given urn-5 random string |
\item Query originator locally compute a hash for given urn-5 random string. |
1936 |
\item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of urn-5 |
\item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of pointer random string. |
1937 |
\item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP-addresses) to query originator, using pointer block's own indexing schemes |
\item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP-addresses) to query originator, using pointer block's own indexing schemes. |
1938 |
\item Query originator requests hosting node to return the scroll block |
\item Query originator requests hosting node to return the scroll block. |
1939 |
\end{enumerate} |
\end{enumerate} |
1940 |
\end{itemize} |
\end{itemize} |
1941 |
|
|
1942 |
Figure \ref{fig:storm_query_urn5} illustrates how scroll block is located |
Figure \ref{fig:storm_query_urn5} illustrates how Storm scroll block is located |
1943 |
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. |
1944 |
|
|
1945 |
Each of these algortihms can locate a specific scroll block in $\Theta(\log{n})$ time; |
Each of these algortihms can locate Fenfire related data in $\Theta(\log{n})$ time: |
1946 |
$\Theta(\log{n})$ time for query routing to pointer peer and constant time for |
$(\log{n})$ time for query routing to pointer peer and constant time for |
1947 |
locating hosting peer with a given reference link. |
locating hosting peer with a given reference link. Time required for transferring |
1948 |
|
the data is not included. |
|
|
|
1949 |
|
|
1950 |
|
|
1951 |
\begin{figure} |
\begin{figure} |