[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/05 08:59:25

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

Log message:
        Approach evaluation

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

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.115 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.116
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.115      Wed Mar 
 5 06:57:58 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Wed Mar  5 
08:59:25 2003
@@ -115,7 +115,7 @@
 Peer-to-Peer functionality. We evaluate existing Peer-to-Peer approaches and
 choose the best alternative to our needs. We discover that Storm, xanalogical 
model and
 tightly structured Peer-to-Peer approach all have similar method to deal with 
data,
-i.e., globally unique identifiers. Finally, we propose effective but yet simple
+i.e., globally unique identifiers. Finally, we propose yet simple but 
effective 
 algortihms to be used  with our Fenfire system in Peer-to-Peer environment. 
 
 To our knowledge, this thesis is the most comprehensive work with regard to 
summarizing 
@@ -1761,8 +1761,6 @@
 from Peer-to-Peer overlay network.  
 
 
-
-
 \section{Problem overview}
 
 As already mentioned in chapter 4, xanalogical document is a ''virtual
@@ -1784,6 +1782,16 @@
 \emph{direct} scroll block obtaining using globally unique identifier of Storm 
scroll block, 
 we also must support \emph{indirect} obtaining of Storm scroll block using 
pointer blocks.
 
+Obviously, our objectives are yet simple but hard to fulfil. First, as a 
prerequisite
+to implementing xanalogical storage model in Peer-to-Peer environment, system
+supporting data lookups must be able to perform \emph{global} scale lookups. 
Thus, 
+we must able to locate and fetch Storm scroll/pointer 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 data items, which are 
distributed 
+randomly throughout the overlay; if not efficient, construction of ''virtual 
file''
+may take reasonable amount time while rendering system very unusable. Third, 
Peer-to-Peer 
+infrasctructure has to be scalable and robust againts hostile attacks.
+
 Some research regarding to these problem has been made by Lukka et al. 
 \cite{lukka02freenetguids}. Authors' work is mainly based on insight of 
implementing
 xanalogical model in Peer-to-Peer enviroment with globally unique identifiers. 
Lukka et al.
@@ -1806,26 +1814,46 @@
 there are no hostile entities among participating peers.
 
 
-\section{Objectives}
+\section{Evaluation of Peer-to-Peer approaches with regard to Fenfire}
 
+In chapter 2 we discussed main differences between loosely and tightly 
structured 
+approaches. As stated, the most significant difference is that tighly 
structured 
+approach has logarithmical properties in all interal operations, while loosely 
+structured approach doesn't have always even linear properties. Furthermore, 
the
+data lookup model of tightly structured overlay scales much better than 
loosely 
+structured overlays; tightly structured overlay supports global data lookups
+in the overlay, whereas the data lookup model of loosely structured approach
+is limited to certain area of overlay\footnote{The area depends on where the 
query
+originator is located in the overlay.}.
+
+For Fenfire's special needs for locating data, the most important advantage of 
+tightly structured approach over loosely structured approach is that tightly 
+structured systems use location-independent, globally unique identifiers for 
+identifying data in the system. Indeed, this 
+feature is almost analogical to Fenfire's (and xanalogical storage model's) 
way of 
+handling data. Another key feature of tightly structured overlays is that they 
are able
+to provide general purpose \emph{interface} for Reference Resolution 
Services\footnote{
+Currently, Domain Name Service (DNS) \cite{rfc1101} is widely used RRS system 
in the Internet.}
+ (RRS) \cite{balakrishnan03semanticfree}. Authors argue that next generation 
RRS must be 
+application-independent and references itself should be \emph{unstructured} 
and 
+\emph{semantic free}. To summarize, these aspects may be the most important 
features 
+of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} 
hypermedia system.
+Thus, we see the tightly structured approach the best alternative to Fenfire's
+needs.
+
+Currently, there are open issues with tightly structured systems which have to 
be
+addressed, as described in chapter 3. The main concerns include decreased 
performance and fault 
+tolerance when system in flux-state, non-optimal distance functions in 
identifier space, 
+proximity routing, hostile entities and flexible search 
\cite{balakrishanarticle03lookupp2p}.
+Additionally, there is only little real world experiments yet with tightly 
structured systems
+(e.g., \cite{overneturl}, \cite{edonkey2kurl}). Therefore, we can't say for 
sure, how well these 
+systems would perform in real Peer-to-Peer environment. However, we believe 
that issues are 
+solved, since there is a strong and wide research community towards to tightly 
structured 
+overlays \cite{projectirisurl}.
 
-\section{Requirements}
+  
 
-Storm (and therefore Fenfire) has several unique features which postulates 
-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.
+\section{Fetching data} 
 
 Since Storm uses SHA-1 hash function for creating globally unique
 identifiers, if necessary, we can check the integrity of a scroll
@@ -1846,53 +1874,6 @@
 or sound is stored under Storm storage model. However, further research is
 required.
 
-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.
-
       
 \section{Analysis}
 
@@ -1990,6 +1971,8 @@
 -'get me block XYZ'
 -there is no reply, how do we are able to know if this was a spam attack, or 
the
 data really no exist in the system ?
+
+-search engine ?
 
 -digital signature on messages (no spam attacks) ?
 -lack of working PKI architecture