/[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.116 by hemppah, Wed Mar 5 13:59:25 2003 UTC revision 1.117 by hemppah, Wed Mar 5 14:56:29 2003 UTC
# Line 382  peer identifier is gradually ''closer'' Line 382  peer identifier is gradually ''closer''
382  in the identifier space. Distance can be measured by numerical  in the identifier space. Distance can be measured by numerical
383  difference between identifiers (e.g., Chord \cite{stoica01chord}), the number of  difference between identifiers (e.g., Chord \cite{stoica01chord}), the number of
384  same prefix bits between identifiers (e.g., Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry}),  same prefix bits between identifiers (e.g., Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry}),
385  bit-wise exclusive or (XOR) (e.g., Kademlia \cite{maymounkov02kademlia}). However, in all  bit-wise exclusive or (XOR) (e.g., Kademlia \cite{maymounkov02kademlia}).
386  previously schemes each hop in the overlay shortens the path  Because of XOR-metric, Kademlia's distance function is both unidirectional
387  between current peer working with query and the key which was  (for a given point $p_i$ in the identifier space and distance $d$ > 0, there
388  looked up.  is exactly one point $p_j$ in way that the distance between $p_i$ and $p_j$
389    is $d$) and symmetric (the distance from $p_i$ to $p_j$ is same as the
390    distance from $p_j$ to $p_i$) \cite{maymounkov02kademlia}. On the other
391    hand, Chord's \cite{stoica01chord} distance function does have the property
392    of unidirection, but doesn't have symmetry. Pastry's \cite{rowston01pastry} distance
393    function supports symmetry, but doesn't support unidirection. As a concequence,
394    Kademlia's \cite{maymounkov02kademlia} XOR-based metric doesn't need
395    stabilization (like in Chord \cite{stoica01chord}) and backup links
396    (like in Pastry \cite{rowston01pastry}) \cite{balakrishanarticle03lookupp2p}.
397    However, in all previously schemes each
398    hop in the overlay shortens the distance between current peer working with query
399    and the key which was looked up in the identifier space.
400    
401  Skip Graphs and Swan employ a key space very similar to a tightly structured  Skip Graphs and Swan employ a key space very similar to a tightly structured
402  overlay, but in which queries are routed  to \emph{keys}. In these systems  overlay, but in which queries are routed  to \emph{keys}. In these systems
# Line 1826  in the overlay, whereas the data lookup Line 1837  in the overlay, whereas the data lookup
1837  is limited to certain area of overlay\footnote{The area depends on where the query  is limited to certain area of overlay\footnote{The area depends on where the query
1838  originator is located in the overlay.}.  originator is located in the overlay.}.
1839    
1840  For Fenfire's special needs for locating data, the most important advantage of  For Fenfire's special needs for \emph{locating} data, the most important advantage of
1841  tightly structured approach over loosely structured approach is that tightly  tightly structured approach over loosely structured approach is that tightly
1842  structured systems use location-independent, globally unique identifiers for  structured systems use location-independent, globally unique identifiers for
1843  identifying data in the system. Indeed, this  identifying data in the system. Indeed, this
1844  feature is almost analogical to Fenfire's (and xanalogical storage model's) way of  feature is almost analogical to Fenfire's (and xanalogical storage model's) way of
1845  handling data. 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
1846  to provide general purpose \emph{interface} for Reference Resolution Services\footnote{  to provide general purpose \emph{interface} for Reference Resolution Services (RRS)\footnote{
1847  Currently, Domain Name Service (DNS) \cite{rfc1101} is widely used RRS system in the Internet.}  Currently, Domain Name System (DNS) \cite{rfc1101} is widely used RRS system in the Internet.}
1848   (RRS) \cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be   \cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be
1849  application-independent and references itself should be \emph{unstructured} and  application-independent and references itself should be \emph{unstructured} and
1850  \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
1851  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.
1852  Thus, we see the tightly structured approach the best alternative to Fenfire's  Thus, we see the tightly structured approach the best alternative to Fenfire's
1853  needs.  needs.
1854    
1855    Once located, for \emph{fetching} Fenfire related data from the overlay, we can use reqular
1856    TCP/IP-protocols, such as Hypertext Transfer protocol (HTTP) \cite{rfc2068}. However, HTTP-protocol may
1857    not be optimal, when obtaining large amounts of data from the Peer-to-Peer overlay, for
1858    instance videos, images or music. In this case, multisource downloads can be very useful
1859    for better efficiency \cite{maymounkov03ratelesscodes}, \cite{bittorrenturl}. Furthermore,
1860    multisource downloads can be used for decreasing load of certain peer, thus avoiding query
1861    hotspots in the system \cite{ratnasamy02routing}. Current mplementation of Fenfire uses
1862    standard single source downloads (HTTP) and SHA-1 \cite{fips-sha-1} cryptographic content
1863    hash for verifying the integrity of data by recomputing the content hash
1864    for a scroll block. In face of multisource downloads, Fenfire must support
1865    tree-based hash\footnote{With multisource downloads, tree based hash functions can be used
1866    to verify fixed length segments of data. If hash value of data segment is incorrect,
1867    we need only to fetch \emph{segment} of data (instead of whole data, e.g., a file) from
1868    other source.}, such as \cite{merkle87hashtree}, \cite{mohr02thex} for reliable and efficient
1869    data validation.
1870    
1871  Currently, there are open issues with tightly structured systems which have to be  Currently, there are open issues with tightly structured systems which have to be
1872  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
1873  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,
# Line 1851  systems would perform in real Peer-to-Pe Line 1878  systems would perform in real Peer-to-Pe
1878  solved, since there is a strong and wide research community towards to tightly structured  solved, since there is a strong and wide research community towards to tightly structured
1879  overlays \cite{projectirisurl}.  overlays \cite{projectirisurl}.
1880    
     
   
 \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  
 block by re-computing hash value for a scroll block, once fetched  
 form the network. Indeed, all scroll blocks' identifiers are  
 self-certifying. However, this not very efficient if we want to  
 obtain large amounts of data. One possibility is to use tree-based  
 hash techiques (e.g., \cite{merkle87hashtree}, \cite{mohr02thex}),  
 which makes possible multisource downloads. Tree based hash functions can be used  
 to verify fixed length segments of data file, instead of whole data file.  
 Currently, Shareaza \cite{shareazaurl}, Overnet \cite{overneturl} and  
 eDonkey2000 \cite{edonkey2kurl} uses tree based hashing for validating  
 segments of a data file. Another option, for more efficient data  
 fething, is use to standard multisource downloading \cite{bittorrenturl} and  
 online codes \cite{maymounkov03ratelesscodes}.  
   
 Multisource downloads can be very useful when media such as video, images  
 or sound is stored under Storm storage model. However, further research is  
 required.  
   
1881                
1882  \section{Analysis}  \section{Analysis}
1883    

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

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