/[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.115 by hemppah, Wed Mar 5 11:57:58 2003 UTC revision 1.116 by hemppah, Wed Mar 5 13:59:25 2003 UTC
# Line 115  also describe briefly Storm software mod Line 115  also describe briefly Storm software mod
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
# Line 1761  to Fenfire, and propose initial algorihm Line 1761  to Fenfire, and propose initial algorihm
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
# Line 1784  file'', from Peer-to-Peer overlay as eff Line 1782  file'', from Peer-to-Peer overlay as eff
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.
# Line 1806  systems. We assume that Fenfire has a re Line 1814  systems. We assume that Fenfire has a re
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
# Line 1846  Multisource downloads can be very useful Line 1874  Multisource downloads can be very useful
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    
# Line 1991  computing world. Line 1972  computing world.
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    

Legend:
Removed from v.1.115  
changed lines
  Added in v.1.116

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