1614 |
\item \textbf{LibVob}: a graphic library used for creating navigation interfaces in complex data views |
\item \textbf{LibVob}: a graphic library used for creating navigation interfaces in complex data views |
1615 |
\end{itemize} |
\end{itemize} |
1616 |
|
|
1617 |
In this thesis, we focus on Storm module as it is a foundation for Peer-to-Peer functionality |
In this thesis, we focus on Storm and Alph modules as they are a foundation for Peer-to-Peer functionality |
1618 |
in the Fenfire system. |
in the Fenfire system. |
1619 |
|
|
1620 |
\section{Xanalogical storage model} |
\section{Xanalogical storage model} |
1720 |
\chapter{Evaluation of Peer-to-Peer for Fenfire} |
\chapter{Evaluation of Peer-to-Peer for Fenfire} |
1721 |
|
|
1722 |
In this chapter we evaluate Fenfire in Peer-to-Peer environment. |
In this chapter we evaluate Fenfire in Peer-to-Peer environment. |
1723 |
We start by giving a problem overview when considering Fenfire in Peer-to-Peer |
We start by giving a problem overview. Then, we define Fenfire's special needs and evaluate existing |
1724 |
environment. We define Fenfire's special needs and evaluate existing |
Peer-to-Peer approaches in light of these requirements. After that, we propose a combination |
1725 |
Peer-to-Peer approaches in light of these requirements. After that, we propose a system |
of Peer-to-Peer techniques reviewed in this thesis to be used with Fenfire and present simple methods to perform data |
1726 |
model for Fenfire and present simple methods to perform data |
lookups (data lookups are required by Alph module). In the end of this chapter, we discuss possible problems of using Fenfire |
|
lookups in Peer-to-Peer environment. In the end of this chapter, we discuss possible problems of using Fenfire |
|
1727 |
in Peer-to-Peer environment. |
in Peer-to-Peer environment. |
1728 |
|
|
1729 |
|
|
1730 |
\section{Problem overview} |
\section{Problem overview} |
1731 |
|
|
1732 |
As already mentioned in chapter 4, xanalogical document is a ''virtual |
Some research regarding to Peer-to-Peer technologies and hypermedia systems have been made by Lukka et al. |
|
file'', in which parts of the document are fetched from a |
|
|
\emph{global} data repository. Thus, system implementing xanalogical storage model \emph{must} |
|
|
support global data lookups efficiently in order to assemble the ''virtual file'' |
|
|
from fragments of data. |
|
|
|
|
|
In xanalogical storage model, each fragment of data is identified by a globally |
|
|
unique identifier. In the Fenfire system, data fragments are scroll blocks generated by Storm storage module. |
|
|
As we discussed already in chapter 4, Fenfire's Storm design |
|
|
uses SHA-1 \cite{fips-sha-1} hash over the contents of a scroll block for creating globally unique |
|
|
identifiers for each scroll block. In our scenario, fragments of data is distributed |
|
|
throughout the Peer-to-Peer overlay network. We want that user operations in Fenfire are location transparent. |
|
|
Therefore, our task is to locate and fetch (i.e. obtain) \emph{all} Storm scroll blocks, associated to a specific ''virtual |
|
|
file'' from the Peer-to-Peer overlay as efficiently as possible. In addition to the |
|
|
\emph{direct} scroll block obtaining using globally unique identifier of Storm scroll block, |
|
|
we also must support the \emph{indirect} obtaining of Storm scroll block using the pointer blocks. |
|
|
|
|
|
Our objectives are simple but yet hard to fulfill. First, as a prerequisite |
|
|
to implementing xanalogical storage model in Peer-to-Peer environment, a system |
|
|
supporting data lookups must be able to perform \emph{global} scale lookups. Thus, |
|
|
we must be able to obtain the Storm block, if it exists in the |
|
|
Peer-to-Peer overlay. Second, data lookups have to be efficient, since constructing |
|
|
one ''virtual file'' may need obtaining several Storm blocks, which are distributed |
|
|
randomly throughout the overlay; if not efficient, construction of the ''virtual file'' |
|
|
may take reasonable amount of time while rendering system very unusable. Third, Peer-to-Peer |
|
|
infrastructure has to be scalable and fault tolerant against hostile attacks. |
|
|
|
|
|
Some research regarding to these problems have been made by Lukka et al. |
|
1733 |
\cite{lukka02freenetguids}. Authors' work is mainly based on the insight of implementing |
\cite{lukka02freenetguids}. Authors' work is mainly based on the insight of implementing |
1734 |
xanalogical storage model in Peer-to-Peer environment with globally unique identifiers. Lukka et al. |
xanalogical storage model in Peer-to-Peer environment with globally unique identifiers. Lukka et al. |
1735 |
use Freenet \cite{clarke00freenet} as an example Peer-to-Peer system supporting |
use Freenet \cite{clarke00freenet} as an example Peer-to-Peer system supporting |
1742 |
\cite{thompson01hypermedia} have studied locating documents and links in Peer-to-Peer |
\cite{thompson01hypermedia} have studied locating documents and links in Peer-to-Peer |
1743 |
environment. At the Hypertext '02 panel, moderated by Wiil \cite{wiil02p2phypertext}, |
environment. At the Hypertext '02 panel, moderated by Wiil \cite{wiil02p2phypertext}, |
1744 |
participants responded whether Peer-to-Peer systems are suitable for hypermedia |
participants responded whether Peer-to-Peer systems are suitable for hypermedia |
1745 |
publishing or not. |
publishing or not. |
1746 |
|
|
1747 |
|
|
1748 |
|
In Peer-to-Peer environment, our objectives are simple but yet hard to fulfill. |
1749 |
|
First, as discussed in chapter 4, xanalogical document is a ''virtual |
1750 |
|
file'', in which parts of the document are fetched from a |
1751 |
|
\emph{global} data repository\footnote{Global repository is not a requirement. Locally constructed xanalogical |
1752 |
|
documents are feasible and they can be assembled without any global data.}. Thus, system implementing xanalogical storage model \emph{must} |
1753 |
|
support global data lookups order to assemble the ''virtual file'' from fragments of data. |
1754 |
|
Specifically, our task is to locate and fetch (i.e., obtain) \emph{all} Storm scroll blocks, associated to a specific ''virtual |
1755 |
|
file'' from the Peer-to-Peer once the construction of ''virtual'' file |
1756 |
|
is resolved (i.e., we know what scroll blocks are required to assemble the ''virtual file''). Also, in addition to the |
1757 |
|
\emph{direct} scroll block obtaining using globally unique identifier of Storm scroll block, |
1758 |
|
we also must support the \emph{indirect} obtaining of Storm scroll block using the pointers. |
1759 |
|
Second, we want that users' operations in Fenfire |
1760 |
|
are location transparent: data lookups have to be efficient, since constructing |
1761 |
|
one ''virtual file'' may need obtaining several Storm blocks, which are distributed |
1762 |
|
randomly throughout the overlay. If not efficient, construction of the ''virtual file'' |
1763 |
|
may take reasonable amount of time while rendering system very unusable. Third, Peer-to-Peer |
1764 |
|
infrastructure has to be scalable and fault tolerant against hostile attacks. |
1765 |
|
|
1766 |
\section{Evaluation of Peer-to-Peer approaches with regard to Fenfire} |
\section{Evaluation of Peer-to-Peer approaches with regard to Fenfire} |
1767 |
|
|
1776 |
originator is located in the overlay.}. |
originator is located in the overlay.}. |
1777 |
|
|
1778 |
For Fenfire's needs for \emph{locating} data, an important advantage of the |
For Fenfire's needs for \emph{locating} data, an important advantage of the |
1779 |
tightly structured approach over the loosely structured approach is that tightly |
tightly structured approach over the loosely structured approach is that both tightly |
1780 |
structured systems use location-independent, globally unique identifiers for |
structured systems and Fenfire use similar methods for identifying data in the |
1781 |
identifying data in the system. Indeed, this |
system, i.e., globally unique identifiers. |
1782 |
feature is similar to Fenfire's (and xanalogical storage model's) way of |
Another key feature of tightly structured overlays is that they are able |
|
handling data. Another key feature of tightly structured overlays is that they are able |
|
1783 |
to provide general purpose \emph{interface} for Reference Resolution Services (RRS)\footnote{ |
to provide general purpose \emph{interface} for Reference Resolution Services (RRS)\footnote{ |
1784 |
Domain Name System (DNS) \cite{rfc1101} is a widely used RRS system in the Internet.} |
Domain Name System (DNS) \cite{rfc1101} is a widely used RRS system in the Internet.} |
1785 |
\cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be |
\cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be |