/[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.119 by hemppah, Wed Mar 5 15:01:54 2003 UTC revision 1.120 by hemppah, Thu Mar 6 09:16:41 2003 UTC
# Line 888  to public, researchers' main concern has Line 888  to public, researchers' main concern has
888  approach. However, people often misunderstand the scalability problem of loosely structured  approach. However, people often misunderstand the scalability problem of loosely structured
889  approach; \emph{network} of loosely structured systems is scalable, but the \emph{query model} is not.  approach; \emph{network} of loosely structured systems is scalable, but the \emph{query model} is not.
890  The main concern of tightly structured system is to make overlay's data lookup  The main concern of tightly structured system is to make overlay's data lookup
891  routing more flexible againts hostile attacks. Another key problems in tightly structured  routing more flexible againts hostile attacks. Another key problem in tightly structured
892  approach are the lack of keyword searches and support for heterogeneous peers.  approach are the lack of keyword searches and support for heterogeneous peers.
893    
894  To make Peer-to-Peer systems even more popular (e.g., in industry), Peer-to-Peer domain  To make Peer-to-Peer systems even more popular (e.g., in industry), Peer-to-Peer domain
# Line 927  al \cite{296824}. Line 927  al \cite{296824}.
927  Spam generating attack is another known attack model againts Peer-to-Peer system. In Spam  Spam generating attack is another known attack model againts Peer-to-Peer system. In Spam
928  attack, hostile or faulty peer may produce false information of the data. Possible solution againts this attack  attack, hostile or faulty peer may produce false information of the data. Possible solution againts this attack
929  is that peer should not trust to single entity. Instead peer should get information from multiple entities and trust  is that peer should not trust to single entity. Instead peer should get information from multiple entities and trust
930  on majority's opinion. However, Spam attack is combined with Sybil attack, obviously previously mentioned solution  on majority's opinion. This methods requires more messages to be sent to network increasing the load of system.
931  won't work. Again, more research is required to solve this attack model reliability. Naor et al. \cite{naor03simpledht}  However, if Spam attack is combined with Sybil attack, obviously previously mentioned solution doesn't work.
932   has proposed a partial solution againts Spam attack with \emph{faulty} peers (not hostile).  Again, more research is required to solve this attack model reliability. Naor et al. \cite{naor03simpledht} has
933    proposed a partial solution againts Spam attack with \emph{faulty} peers (not hostile).
934    
935  Traditional overload of targeted peers is best known form of distrubuted Denial of Service attack (DDoS). For example,  Traditional overload of targeted peers is best known form of distrubuted Denial of Service attack (DDoS). For example,
936  hostile entity can attempt to burden targetted peers with garbage packets. As a implication, peers may act  hostile entity can attempt to burden targetted peers with garbage packets. As a implication, peers may act
# Line 1723  see \cite{lukka02freenetguids}, and for Line 1724  see \cite{lukka02freenetguids}, and for
1724    
1725  Storm (for \emph{STORage Module}) is a software module, which is used in Fenfire for  Storm (for \emph{STORage Module}) is a software module, which is used in Fenfire for
1726  implementing basic data storage operations. Storm stores all data as \emph{scroll blocks}, which  implementing basic data storage operations. Storm stores all data as \emph{scroll blocks}, which
1727  are immutable byte sequences. SHA-1 cryptographic content hash \cite{fips-sha-1} is used  are immutable byte sequences. SHA-1\footnote{SHA-1 is considered a collision free
1728  for creating locatiotion-independent, globally unique identifiers for blocks. Storm  hash function. Therefore, it is very unlikely that two different Storm scroll blocks
1729    would have same identifier.} cryptographic content hash \cite{fips-sha-1} is used
1730    for creating locatiotion-independent, globally unique identifiers for blocks. Additionally,
1731    SHA-1 \cite{fips-sha-1} is used for verifying the integrity of scroll blocks. Storm
1732  blocks have much in common with regular files, except Storm blocks are \emph{immutable} as  blocks have much in common with regular files, except Storm blocks are \emph{immutable} as
1733  any change to the byte sequence would the change block's hash value, i.e., unique  any change to the byte sequence would the change block's hash value, i.e., unique
1734  identifier. This mechanism creates a basis for implementing xanalogical model in our  identifier. This mechanism creates a basis for implementing xanalogical model in our
# Line 1783  from fragments of data. Line 1787  from fragments of data.
1787  In the xanalogical storage model, each fragment of data is identified by a globally  In the xanalogical storage model, each fragment of data is identified by a globally
1788  unique identifier. In Fenfire, data fragments are scroll blocks, generated by Storm storage module.  unique identifier. In Fenfire, data fragments are scroll blocks, generated by Storm storage module.
1789  As we discussed already in chapter 4, Fenfire's Storm design  As we discussed already in chapter 4, Fenfire's Storm design
1790  uses SHA-1 \footnote{SHA-1 is considered a collision free hash function. Therefore, it is  uses SHA-1 \cite{fips-sha-1} hash over the contents of a scroll block for creating globally unique
 very unlikely that two different Storm scroll blocks would have same identifier.}  
 \cite{fips-sha-1} hash over the contents of a scroll block for creating globally unique  
1791  identifiers for each scroll block.  In our scenario, fragments of data is distributed  identifiers for each scroll block.  In our scenario, fragments of data is distributed
1792  throughout the Peer-to-Peer overlay. Our task is to locate and fetch  throughout the Peer-to-Peer overlay. Our task is to locate and fetch
1793  (i.e. obtain) \emph{all} Storm scroll blocks, associated to a specific ''virtual  (i.e. obtain) \emph{all} Storm scroll blocks, associated to a specific ''virtual
# Line 1818  environment. At the Hypertext '02 panel, Line 1820  environment. At the Hypertext '02 panel,
1820  participants responded whether Peer-to-Peer systems are suitable for hypermedia  participants responded whether Peer-to-Peer systems are suitable for hypermedia
1821  publishing or not.  publishing or not.
1822    
 In the following sections we assume that we know the structure of ''virtual file'' before hand,  
 i.e. when assmbling a ''virtual file'', we know all Storm scroll/pointer blocks, which are required  
 when building the ''virtual file''. Also, we don't respond to security issues related to Peer-to-Peer  
 systems. We assume that Fenfire has a reliable techique for identifying invidual entities, or  
 there are no hostile entities among participating peers.  
   
   
1823  \section{Evaluation of Peer-to-Peer approaches with regard to Fenfire}  \section{Evaluation of Peer-to-Peer approaches with regard to Fenfire}
1824    
1825  In chapter 2 we discussed main differences between loosely and tightly structured  In chapter 2, we discussed main differences between loosely and tightly structured
1826  approaches. As stated, the most significant difference is that tighly structured  approaches. As stated, the most significant difference is that tighly structured
1827  approach has logarithmical properties in all interal operations, while loosely  approach has logarithmical properties in all interal operations, while loosely
1828  structured approach doesn't have always even linear properties. Furthermore, the  structured approach doesn't have always even linear properties. Furthermore, the
# Line 1849  Currently, Domain Name System (DNS) \cit Line 1844  Currently, Domain Name System (DNS) \cit
1844  application-independent and references itself should be \emph{unstructured} and  application-independent and references itself should be \emph{unstructured} and
1845  \emph{semantic free}. To summarize, these aspects may be the most important features  \emph{semantic free}. To summarize, these aspects may be the most important features
1846  of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} hypermedia system.  of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} hypermedia system.
1847  Thus, we see the tightly structured approach the best alternative to Fenfire's  Thus, we see the tightly structured approach the best alternative to locate data in Peer-to-Peer
1848  needs.  environment.
1849    
1850  Once located, for \emph{fetching} Fenfire related data from the overlay, we can use reqular  Once located, for \emph{fetching} Fenfire related data from the overlay, we can use reqular
1851  TCP/IP-protocols, such as Hypertext Transfer protocol (HTTP) \cite{rfc2068}. However, HTTP-protocol may  TCP/IP-protocols, such as Hypertext Transfer protocol (HTTP) \cite{rfc2068}. However, HTTP-protocol may
# Line 1868  we need only to fetch \emph{segment} of Line 1863  we need only to fetch \emph{segment} of
1863  other source.}, such as \cite{merkle87hashtree} and \cite{mohr02thex} for reliable and efficient  other source.}, such as \cite{merkle87hashtree} and \cite{mohr02thex} for reliable and efficient
1864  data validation.  data validation.
1865    
1866  Currently, there are open issues with tightly structured systems which have to be  Again, there are open issues with tightly structured systems which have to be
1867  addressed, as described in chapter 3. The main concerns include decreased performance and fault  addressed, as described in chapter 3. The main concerns include decreased performance and fault
1868  tolerance when system in flux-state, non-optimal distance functions in identifier space,  tolerance when system in flux-state, non-optimal distance functions in identifier space,
1869  proximity routing, hostile entities and flexible search \cite{balakrishanarticle03lookupp2p}.  proximity routing, hostile entities and flexible search \cite{balakrishanarticle03lookupp2p}.
# Line 1879  solved, since there is a strong and wide Line 1874  solved, since there is a strong and wide
1874  overlays \cite{projectirisurl}.  overlays \cite{projectirisurl}.
1875    
1876                
1877  \section{Analysis}  \section{Algorithm proposals}
1878    
1879    In this section we propose yet simple but effective algorithms for obtaining Fenfire data from
1880    Peer-to-Peer environment. In the following subsections we assume that we know the structure of
1881    ''virtual file'' before hand, i.e. when assmbling a ''virtual file'', we know all Storm
1882    scroll/pointer blocks, which are required when building the ''virtual file''. Also, we don't
1883    respond to security issues related to Peer-to-Peer systems, since there is no working solution
1884    available yet; we either assume that Fenfire has a reliable techique for identifying invidual entities, or
1885    there are no hostile entities among participating peers.
1886    
1887  In this section we analyse the costs of locating Storm block with a given identifier  \subsection{System model}
 and urn-5 random string.  
1888    
1889  \subsection{Assumptions}  We use DOLR model of tightly of structured approach, i.e. each participating peer hosts
1890  In our analysis, we use tightly structured ovelay's DOLR method. Each peer hosts the data,  the data and overlay maintains only the \emph{pointers} to the data. We descided to use DOLR in our
1891  overlay maintains only the \emph{pointers} to the data. Furthermore, each peer maintains  model, since DOLR systems locate date without specifiying a storage policy explicity \cite{rhea03benchmarks}.
1892  following data structures for local operations: one data structure for listing all  DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST \cite{rowstron01storage}, have
1893  key/value-pairs; one data structure for listing all key/value-pair in chronological order  critical problems with load balancing in highly heterogeneous environment. This is caused by peers which may not able
1894  (the most recent block is topmost). Every key/value-pairs consists of a hash of urn-5  to store relative great amount of data with key/value pair, assigned randomly by mapping function of the overlay.
1895  random string (pointer blocks) or a hash of block's content (scroll blocks) as a key.  
1896  Value is always a reference to a hosting peer (e.g. IP-address). Finally, we assume  In our model, each peer maintains following data structures for local operations: data structure for listing all
1897  that all local operations can be done in a constant time.  key/value-pairs which peer maintains; data structure for listing all key/value-pair in
1898    chronological order (the most recent block is topmost) which peer maintains. We use Storm blocks' identifiers
1899    as \emph{keys} of the overlay. Every key/value-pairs consists of either a hash of pointer random string
1900    (pointer blocks), or a hash of block's content (scroll blocks) as a key. Value is always a reference to a hosting
1901    peer (e.g. IP address). Finally, we assume that all local operations can be done in a constant time.
1902    
1903  \subsection{Algorithms}  \subsection{Algorithms}
1904    
1905    
1906  \begin{itemize}  \begin{itemize}
1907  \item Data lookup with a given scroll block's identifier  \item Data lookup with a given identifier of Storm scroll block.
1908  \begin{enumerate}  \begin{enumerate}
1909  \item Submit query using scroll block's identifier  \item Submit query using scroll block's identifier.
1910  \item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given scroll block identifier  \item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given scroll block identifier.
1911  \item Pointer peer returns most recent pointer block's value (e.g., hosting peer's IP-address) to query originator  \item Pointer peer returns most recent pointer block's value (e.g., hosting peer's IP-address) to query originator.
1912  \item Query originator requests hosting node to return the scroll block  \item Query originator requests hosting node to return the scroll block.
1913  \end{enumerate}  \end{enumerate}
1914  \end{itemize}  \end{itemize}
1915    
1916  Figure \ref{fig:storm_query_blockid} illustrates how scroll block is located  Figure \ref{fig:storm_query_blockid} illustrates how Storm scroll block is located
1917  in a tightly structured overlay using DOLR method, where scroll block's  in a tightly structured overlay using DOLR method, where identifier of Storm scroll
1918  identifier is known.  block is known.
1919    
1920    
1921  \begin{itemize}  \begin{itemize}
1922  \item Data lookup with a given urn-5 random string returning most recent scroll block  \item Data lookup with a given pointer random string returning most recent scroll block.
1923  \begin{enumerate}  \begin{enumerate}
1924    \item Query originator locally compute a hash for given urn-5 random string.
1925  \item Query originator locally compute a hash for given urn-5 random string  \item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of pointer random string.
1926  \item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of urn-5  \item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP-address) to query originator, using pointer block's own indexing schemes.
1927  \item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP-address) to query originator, using pointer block's own indexing schemes  \item Query originator requests hosting node to return the scroll block.
 \item Query originator requests hosting node to return the scroll block  
1928  \end{enumerate}  \end{enumerate}
1929  \end{itemize}  \end{itemize}
1930    
1931  \begin{itemize}  \begin{itemize}
1932  \item Data lookup with a given urn-5 random string returning scroll block(s) for a given date and time range  \item Data lookup with a given pointer random string returning scroll block(s) for a given date and time range.
1933  \begin{enumerate}  \begin{enumerate}
1934    
1935  \item Query originator locally compute a hash for given urn-5 random string  \item Query originator locally compute a hash for given urn-5 random string.
1936  \item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of urn-5  \item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of pointer random string.
1937  \item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP-addresses) to query originator, using pointer block's own indexing schemes  \item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP-addresses) to query originator, using pointer block's own indexing schemes.
1938  \item Query originator requests hosting node to return the scroll block  \item Query originator requests hosting node to return the scroll block.
1939  \end{enumerate}  \end{enumerate}
1940  \end{itemize}  \end{itemize}
1941    
1942  Figure \ref{fig:storm_query_urn5} illustrates how scroll block is located  Figure \ref{fig:storm_query_urn5} illustrates how Storm scroll block is located
1943  in a tightly structured overlay using DOLR method, where urn-5 is known.  in a tightly structured overlay using DOLR method, where urn-5 is known.
1944    
1945  Each of these algortihms can locate a specific scroll block in $\Theta(\log{n})$ time;  Each of these algortihms can locate Fenfire related data in $\Theta(\log{n})$ time:
1946  $\Theta(\log{n})$ time for query routing to pointer peer and constant time for  $(\log{n})$ time for query routing to pointer peer and constant time for
1947  locating hosting peer with a given reference link.        locating hosting peer with a given reference link. Time required for transferring
1948                    the data is not included.
   
1949    
1950    
1951  \begin{figure}  \begin{figure}

Legend:
Removed from v.1.119  
changed lines
  Added in v.1.120

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