[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Hermanni Hyytiälä <address@hidden>      03/03/25 02:51:51

Modified files:
        Documentation/misc/hemppah-progradu: masterthesis.tex 

Log message:
        Updates: started 5.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.180&tr2=1.181&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.180 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.181
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.180      Mon Mar 
24 11:16:49 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Tue Mar 25 
02:51:50 2003
@@ -1614,7 +1614,7 @@
 \item \textbf{LibVob}: a graphic library used for creating navigation 
interfaces in complex data views
 \end{itemize}
 
-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
 in the Fenfire system.
 
 \section{Xanalogical storage model}
@@ -1720,44 +1720,16 @@
 \chapter{Evaluation of Peer-to-Peer for Fenfire}
 
 In this chapter we evaluate Fenfire in Peer-to-Peer environment.
-We start by giving a problem overview when considering Fenfire in Peer-to-Peer
-environment. We define Fenfire's special needs and evaluate existing 
-Peer-to-Peer approaches in light of these requirements. After that, we propose 
a system
-model for Fenfire and present simple methods to perform data 
-lookups in Peer-to-Peer environment. In the end of this chapter, we discuss 
possible problems of using Fenfire
+We start by giving a problem overview. Then, we define Fenfire's special needs 
and evaluate existing 
+Peer-to-Peer approaches in light of these requirements. After that, we propose 
a combination
+of Peer-to-Peer techniques reviewed in this thesis to be used with 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
 in Peer-to-Peer environment.
 
 
 \section{Problem overview}
 
-As already mentioned in chapter 4, xanalogical document is a ''virtual
-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. 
+Some research regarding to Peer-to-Peer technologies and hypermedia systems 
have been made by Lukka et al. 
 \cite{lukka02freenetguids}. Authors' work is mainly based on the insight of 
implementing  
 xanalogical storage model in Peer-to-Peer environment with globally unique 
identifiers. Lukka et al.
 use Freenet \cite{clarke00freenet} as an example Peer-to-Peer system 
supporting 
@@ -1770,7 +1742,26 @@
 \cite{thompson01hypermedia} have studied locating documents and links in 
Peer-to-Peer
 environment. At the Hypertext '02 panel, moderated by Wiil 
\cite{wiil02p2phypertext},
 participants responded whether Peer-to-Peer systems are suitable for hypermedia
-publishing or not. 
+publishing or not.
+
+
+In Peer-to-Peer environment, our objectives are simple but yet hard to fulfill.
+First, as discussed in chapter 4, xanalogical document is a ''virtual
+file'', in which parts of the document are fetched from a 
+\emph{global} data repository\footnote{Global repository is not a requirement. 
Locally constructed xanalogical
+documents are feasible and they can be assembled without any global data.}. 
Thus, system implementing xanalogical storage model \emph{must}
+support global data lookups order to assemble the ''virtual file'' from 
fragments of data. 
+Specifically, 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 once the construction of ''virtual'' file
+is resolved (i.e., we know what scroll blocks are required to assemble the 
''virtual file''). Also, 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 pointers.
+Second, we want that users' operations in Fenfire 
+are location transparent: 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.
 
 \section{Evaluation of Peer-to-Peer approaches with regard to Fenfire}
 
@@ -1785,11 +1776,10 @@
 originator is located in the overlay.}.
 
 For Fenfire's needs for \emph{locating} data, an important advantage of the 
-tightly structured approach over the loosely structured approach is that 
tightly 
-structured systems use location-independent, globally unique identifiers for 
-identifying data in the system. Indeed, this 
-feature is similar to Fenfire's (and xanalogical storage model's) way of 
-handling data. Another key feature of tightly structured overlays is that they 
are able
+tightly structured approach over the loosely structured approach is that both 
tightly 
+structured systems and Fenfire use similar methods for identifying data in the
+system, i.e., globally unique identifiers.
+Another key feature of tightly structured overlays is that they are able
 to provide general purpose \emph{interface} for Reference Resolution Services 
(RRS)\footnote{
 Domain Name System (DNS) \cite{rfc1101} is a widely used RRS system in the 
Internet.}
  \cite{balakrishnan03semanticfree}. Authors argue that next generation RRS 
must be