115 |
Peer-to-Peer functionality. We evaluate existing Peer-to-Peer approaches and |
Peer-to-Peer functionality. We evaluate existing Peer-to-Peer approaches and |
116 |
choose the best alternative to our needs. We discover that Storm, xanalogical model and |
choose the best alternative to our needs. We discover that Storm, xanalogical model and |
117 |
tightly structured Peer-to-Peer approach all have similar method to deal with data, |
tightly structured Peer-to-Peer approach all have similar method to deal with data, |
118 |
i.e., globally unique identifiers. Finally, we propose effective but yet simple |
i.e., globally unique identifiers. Finally, we propose yet simple but effective |
119 |
algortihms to be used with our Fenfire system in Peer-to-Peer environment. |
algortihms to be used with our Fenfire system in Peer-to-Peer environment. |
120 |
|
|
121 |
To our knowledge, this thesis is the most comprehensive work with regard to summarizing |
To our knowledge, this thesis is the most comprehensive work with regard to summarizing |
1761 |
from Peer-to-Peer overlay network. |
from Peer-to-Peer overlay network. |
1762 |
|
|
1763 |
|
|
|
|
|
|
|
|
1764 |
\section{Problem overview} |
\section{Problem overview} |
1765 |
|
|
1766 |
As already mentioned in chapter 4, xanalogical document is a ''virtual |
As already mentioned in chapter 4, xanalogical document is a ''virtual |
1782 |
\emph{direct} scroll block obtaining using globally unique identifier of Storm scroll block, |
\emph{direct} scroll block obtaining using globally unique identifier of Storm scroll block, |
1783 |
we also must support \emph{indirect} obtaining of Storm scroll block using pointer blocks. |
we also must support \emph{indirect} obtaining of Storm scroll block using pointer blocks. |
1784 |
|
|
1785 |
|
Obviously, our objectives are yet simple but hard to fulfil. First, as a prerequisite |
1786 |
|
to implementing xanalogical storage model in Peer-to-Peer environment, system |
1787 |
|
supporting data lookups must be able to perform \emph{global} scale lookups. Thus, |
1788 |
|
we must able to locate and fetch Storm scroll/pointer block, if it exists in the |
1789 |
|
Peer-to-Peer overlay. Second, data lookups have to be efficient, since constructing |
1790 |
|
one ''virtual file'' may need obtaining several data items, which are distributed |
1791 |
|
randomly throughout the overlay; if not efficient, construction of ''virtual file'' |
1792 |
|
may take reasonable amount time while rendering system very unusable. Third, Peer-to-Peer |
1793 |
|
infrasctructure has to be scalable and robust againts hostile attacks. |
1794 |
|
|
1795 |
Some research regarding to these problem has been made by Lukka et al. |
Some research regarding to these problem has been made by Lukka et al. |
1796 |
\cite{lukka02freenetguids}. Authors' work is mainly based on insight of implementing |
\cite{lukka02freenetguids}. Authors' work is mainly based on insight of implementing |
1797 |
xanalogical model in Peer-to-Peer enviroment with globally unique identifiers. Lukka et al. |
xanalogical model in Peer-to-Peer enviroment with globally unique identifiers. Lukka et al. |
1814 |
there are no hostile entities among participating peers. |
there are no hostile entities among participating peers. |
1815 |
|
|
1816 |
|
|
1817 |
\section{Objectives} |
\section{Evaluation of Peer-to-Peer approaches with regard to Fenfire} |
1818 |
|
|
1819 |
|
In chapter 2 we discussed main differences between loosely and tightly structured |
1820 |
|
approaches. As stated, the most significant difference is that tighly structured |
1821 |
|
approach has logarithmical properties in all interal operations, while loosely |
1822 |
|
structured approach doesn't have always even linear properties. Furthermore, the |
1823 |
|
data lookup model of tightly structured overlay scales much better than loosely |
1824 |
|
structured overlays; tightly structured overlay supports global data lookups |
1825 |
|
in the overlay, whereas the data lookup model of loosely structured approach |
1826 |
|
is limited to certain area of overlay\footnote{The area depends on where the query |
1827 |
|
originator is located in the overlay.}. |
1828 |
|
|
1829 |
|
For Fenfire's special needs for locating data, the most important advantage of |
1830 |
|
tightly structured approach over loosely structured approach is that tightly |
1831 |
|
structured systems use location-independent, globally unique identifiers for |
1832 |
|
identifying data in the system. Indeed, this |
1833 |
|
feature is almost analogical to Fenfire's (and xanalogical storage model's) way of |
1834 |
|
handling data. Another key feature of tightly structured overlays is that they are able |
1835 |
|
to provide general purpose \emph{interface} for Reference Resolution Services\footnote{ |
1836 |
|
Currently, Domain Name Service (DNS) \cite{rfc1101} is widely used RRS system in the Internet.} |
1837 |
|
(RRS) \cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be |
1838 |
|
application-independent and references itself should be \emph{unstructured} and |
1839 |
|
\emph{semantic free}. To summarize, these aspects may be the most important features |
1840 |
|
of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} hypermedia system. |
1841 |
|
Thus, we see the tightly structured approach the best alternative to Fenfire's |
1842 |
|
needs. |
1843 |
|
|
1844 |
|
Currently, there are open issues with tightly structured systems which have to be |
1845 |
|
addressed, as described in chapter 3. The main concerns include decreased performance and fault |
1846 |
|
tolerance when system in flux-state, non-optimal distance functions in identifier space, |
1847 |
|
proximity routing, hostile entities and flexible search \cite{balakrishanarticle03lookupp2p}. |
1848 |
|
Additionally, there is only little real world experiments yet with tightly structured systems |
1849 |
|
(e.g., \cite{overneturl}, \cite{edonkey2kurl}). Therefore, we can't say for sure, how well these |
1850 |
|
systems would perform in real Peer-to-Peer environment. However, we believe that issues are |
1851 |
|
solved, since there is a strong and wide research community towards to tightly structured |
1852 |
|
overlays \cite{projectirisurl}. |
1853 |
|
|
1854 |
\section{Requirements} |
|
1855 |
|
|
1856 |
Storm (and therefore Fenfire) has several unique features which postulates |
\section{Fetching data} |
|
different kind of requirements for Peer-to-Peer system. First, Storm stores data |
|
|
as append-and-delete only blocks, which are immutable byte sequences. Second, Storm |
|
|
uses urn-5 random strings for binding concepts to data. Finally, all data is identified |
|
|
by globally unique identifiers. |
|
|
|
|
|
With regard to Storm, the most important requirement for Peer-to-Peer system |
|
|
is to capability to performa a global scale data lookup, since xanalogical |
|
|
model assumes that scroll blocks are fetched from a global block repository. |
|
|
Moreover, Peer-to-Peer system has to support location-independent identifiers (and |
|
|
location independent routing), since Storm uses SHA-1 based identifiers |
|
|
for identifying scroll blocks. Of course, Peer-to-Peer infrasctructure has to be |
|
|
scalable, efficient, adaptive, robust, self-organising and resistant againts DDoS |
|
|
attacks. Additionally, if possible, it would be benefitial if Peer-to-Peer system |
|
|
would represent all named resources as keys. |
|
1857 |
|
|
1858 |
Since Storm uses SHA-1 hash function for creating globally unique |
Since Storm uses SHA-1 hash function for creating globally unique |
1859 |
identifiers, if necessary, we can check the integrity of a scroll |
identifiers, if necessary, we can check the integrity of a scroll |
1874 |
or sound is stored under Storm storage model. However, further research is |
or sound is stored under Storm storage model. However, further research is |
1875 |
required. |
required. |
1876 |
|
|
|
For more detailed discussion about Storm's storage model, see |
|
|
\cite{fallenstein03storm}. |
|
|
|
|
|
\section{Evaluation} |
|
|
|
|
|
There are major differences between loosely and tightly structured approaches. |
|
|
Perhaps the most significant difference is that tighly structured approach |
|
|
has $\Theta\log{n}$ properties, where as loosely structured approach doesn't |
|
|
have always even linear properties. Moreover, tightly structured overlays |
|
|
scale much better than loosely structured overlays, since construction and |
|
|
maintenance of overlay is controlled. |
|
|
|
|
|
For Storm, the most important aspect in tightly structured overlays is |
|
|
that they use unique keys as identifying data in the network. This is almost |
|
|
analogical to Storm's (and xanalogical model's) way of handling data. Furthermore, |
|
|
as authors cite in \cite{balakrishnan03semanticfree}, tightly structured overlays |
|
|
provide general purpose \emph{interface} for Reference Resolution Services (RRS) |
|
|
(like DNS \cite{rfc1101}) and semantic-free referencing. Authors argue that next |
|
|
generation RRS must be application-independent and references itself should be |
|
|
\emph{unstructured} and \emph{semantic free}. Indeed, these cases are one of the |
|
|
objectives of our Storm design. |
|
|
|
|
|
On the other hand, however, tightly structured approach doesn't have large scale |
|
|
real world experiments yet. Therefore, we can't say for sure, how well tightly |
|
|
structured overlay would perform in every day use. The main concerns are decreased |
|
|
performance, support for heterogeneity and load balancing in system in flux (as |
|
|
cited in \cite{liben-nowell02observatorionsp2p}). Other issues of tighly structured |
|
|
approach are lack of richness (exact keys) when performing queries and locality |
|
|
(hashing). We don't see this as a problem. First, our Storm design uses unique |
|
|
identifiers (keys) for identifying data. This is Storm's natural (and xanalogical |
|
|
model's) way to refer a specific piece of data. Second, by using tightly structured |
|
|
approaches' DOLR method, we hash the \emph{pointers} of data not the data itself. This |
|
|
method allows data to be hosted on local computer (if wanted). Of course, for |
|
|
mirroring purposes for instance, Storm is able to use DHT method occasionally to |
|
|
move \emph{data} in the network. Finally, we believe that issues related to tightly |
|
|
structured approach are solved, since there is strong and wide commitment in |
|
|
research community tightly structured overlays \cite{projectirisurl}. Therefore, |
|
|
loosely structured overlays' good support for performing queries |
|
|
(keyword/fuzzy search) and locality properties are not important to our goals. |
|
|
|
|
|
For the previous mentioned reasons, we see tightly structured approach the |
|
|
better alternative to our needs. Both Storm and tightly structured overlays uses |
|
|
globally unique identifiers for locating data. Furthermore, tightly structured |
|
|
overlays provides guaranteed data lookup and has very efficient lookup algorithms, |
|
|
which are essential to xanalogical model to be usable in distributed environment. |
|
|
Table \ref{table_comparison_approach} lists the key feature of both approaches. |
|
|
|
|
1877 |
|
|
1878 |
\section{Analysis} |
\section{Analysis} |
1879 |
|
|
1972 |
-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 |
1973 |
data really no exist in the system ? |
data really no exist in the system ? |
1974 |
|
|
1975 |
|
-search engine ? |
1976 |
|
|
1977 |
-digital signature on messages (no spam attacks) ? |
-digital signature on messages (no spam attacks) ? |
1978 |
-lack of working PKI architecture |
-lack of working PKI architecture |
1979 |
|
|