/[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.180 by hemppah, Mon Mar 24 16:16:49 2003 UTC revision 1.181 by hemppah, Tue Mar 25 07:51:50 2003 UTC
# Line 1614  Fenfire is a free software and it is lic Line 1614  Fenfire is a free software and it is lic
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}
# Line 1720  planned in future versions of Storm.} Line 1720  planned in future versions of Storm.}
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
# Line 1770  Peer-to-Peer can be used in non-xanalogi Line 1742  Peer-to-Peer can be used in non-xanalogi
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    
# Line 1785  is limited to a certain area of the over Line 1776  is limited to a certain area of the over
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

Legend:
Removed from v.1.180  
changed lines
  Added in v.1.181

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