/[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.62 by hemppah, Mon Feb 24 09:56:58 2003 UTC revision 1.63 by hemppah, Mon Feb 24 12:21:37 2003 UTC
# Line 504  load balance Line 504  load balance
504  {{\tablename\ \thetable{} -- continued from previous page}} \\  {{\tablename\ \thetable{} -- continued from previous page}} \\
505  \hline  \hline
506  \multicolumn{1}{|c|}{\textbf{Property}} &  \multicolumn{1}{|c|}{\textbf{Property}} &
507  \multicolumn{1}{c|}{\textbf{Unstructured}} &  \multicolumn{1}{c|}{\textbf{Loosely structured}} &
508  \multicolumn{1}{c|}{\textbf{Structured}}  \multicolumn{1}{c|}{\textbf{Tightly structured}}
509  \\ \hline  \\ \hline
510  \endhead  \endhead
511    
# Line 1511  that share text with the current documen Line 1511  that share text with the current documen
1511    
1512  \chapter{Evaluation of Peer-to-Peer for Gzz}  \chapter{Evaluation of Peer-to-Peer for Gzz}
1513    
1514    In this chapter we evaluate Gzz in Peer-to-Peer enviroment.
1515    We start by giving an overview of Gzz Peer-to-Peer system. Then,
1516    we define our objectives and special needs and consider possible
1517    benefits over existing Peer-to-Peer filesharing systems. Finally, we
1518    evaluate different peer-to-peer systems with regard to Gzz, make
1519    initial analsysis and discuss possible problems.
1520    
1521    
1522    
1523    Fething videos, pictures, music and other media:
1524    
1525  -BitTorrent is not a lookup system-- it's a tool for *distributing* data  -BitTorrent is not a lookup system-- it's a tool for *distributing* data
1526  -MIT License, written in Python  -MIT License, written in Python
# Line 1537  sequential and random access. This memo Line 1547  sequential and random access. This memo
1547     2. To describe a serialization format for storage and transmission of hash trees.     2. To describe a serialization format for storage and transmission of hash trees.
1548        
1549        
1550      
1551     \cite{mohr02thex}     \cite{mohr02thex}
1552     \cite{overneturl}     \cite{overneturl}
1553     \cite{edonkey2kurl}     \cite{edonkey2kurl}
1554    
1555  \section{Overview}  \section{Overview}
1556    
1557  -need to make Gzz distributed system  As we mentioned in previous chapter (ref), xanalogical document is a virtual
1558    document, in where parts of the document (i.e. scroll blocks) are fetched from a
1559    global, large scale data pool. To be practical and useful, system implementing
1560    xanalogical model have to be distributed.
1561    
1562    We have decided to use Peer-to-Peer network as a Gzz's communication layer. For
1563    motivations and discussion, see \cite{lukka02freenetguids, fallenstein03storm}.
1564    This paper's focus, however, is to evaluate existing Peer-to-Peer systems and their
1565    applicably with regard to Gzz's requirements. Anyhow, it must be feasible to perform
1566    efficient lookups to locate parts of the document from the global repository based on
1567    block's identifier. To be more specific, Gzz's Storm module has to support \emph{global scale}
1568    data lookup to locate and fetch scroll blocks by using \emph{location-independent}
1569    identifiers.
1570    
1571    Storm uses SHA-1 \cite{fips-sha-1} hash over the contents of a block for creating globally
1572    unique identifiers. SHA-1 is consired a collision free hash function, so it's very unlikely
1573    that two different scroll blocks would have same identifiers. Obviously, Storm has to
1574    efficiently find a specific scroll block if it is available in the network.
1575    
1576    
1577  \section{Objectives}  \section{Objectives}
1578    
1579    We use
1580    
1581  2.1  "Searching for a specific Storm block"  2.1  "Searching for a specific Storm block"
1582    
1583  2.1.1 Facts  2.1.1 Facts
# Line 1576  on the the block's ID Line 1607  on the the block's ID
1607  %-in every block's header, there is a timestamp for date&time  %-in every block's header, there is a timestamp for date&time
1608    
1609  2.2.2. Objectives  2.2.2. Objectives
1610    
1611  -Find the specific (and the most recent) Storm block as quicly as possible (and return it to the user) based on the given urn-5 with a block's ID  -Find the specific (and the most recent) Storm block as quicly as possible (and return it to the user) based on the given urn-5 with a block's ID
1612  -simple pseudo thinking: "find all Storm blocks from the network, which uses specific urn-5 name. Compare blocks and  -simple pseudo thinking: "find all Storm blocks from the network, which uses specific urn-5 name. Compare blocks and
1613  return the most recent block, if the signing key is "valid"."  return the most recent block, if the signing key is "valid"."
# Line 1592  return the most recent block, if the sig Line 1624  return the most recent block, if the sig
1624    
1625  \section{Special needs}  \section{Special needs}
1626    
1627    Storm (and therefore Gzz) has several unique features which postulates
1628    different kind of requirements for Peer-to-Peer system. First, Storm stores data
1629    as append-and-delete only blocks, which are immutable byte sequences. Second, Storm
1630    uses urn-5 random strings for binding concepts to data. Finally, all data is identified
1631    by globally unique identifiers.
1632    
1633    With regard to Storm, the most important requirement for Peer-to-Peer system
1634    is to capability to performa a global scale data lookup, since xanalogical
1635    model assumes that scroll blocks are fetched from a global block repository.
1636    Moreover, Peer-to-Peer system has to support location-independent identifiers (and
1637    location independent routing), since Storm uses SHA-1 based identifiers
1638    for identifying scroll blocks. Of course, Peer-to-Peer infrasctructure has to be
1639    scalable, efficient, adaptive, robust, self-organising and resistant againts DDoS
1640    attacks. Additionally, if possible, it would be benefitial if Peer-to-Peer system
1641    would represent all named resources keys.
1642    
1643    
1644    
1645    
1646    
1647  Gzz's requirements  Gzz's requirements
1648  -append-and-delete (when a modification has been commited, a new version must be created)  -append-and-delete (when a modification has been commited, a new version must be created)
1649  -the same data block can be stored to many different locations (can we use 'How share a secret ?', like in Publius and Tangler ?)  -the same data block can be stored to many different locations (can we use 'How share a secret ?', like in Publius and Tangler ?)
# Line 1602  Gzz's requirements Line 1654  Gzz's requirements
1654  -do we have a support for transcopyright ?  -do we have a support for transcopyright ?
1655    
1656    
 %[2003-02-21T12:40:48Z] <hemppah/#gzz> one question about pointers and pointer blocks:  
 %[2003-02-21T12:41:19Z] <hemppah/#gzz> In which order does urn-5 random string, pointer block and scroll block is created ?  
 %[2003-02-21T12:41:45Z] <hemppah/#gzz> or, to be more specific:  
 %[2003-02-21T12:42:22Z] <hemppah/#gzz> when one creates urn-5 random string, does storm automatically create a (dummy) pointer block, or  
 %[2003-02-21T12:42:47Z] <tuomasl2/#gzz> certainly not  
 %[2003-02-21T12:42:53Z] <hemppah/#gzz> when scroll block is created, associated with a given urn-5, then ?  
 %[2003-02-21T12:43:06Z] <tuomasl2/#gzz> yes  
 %[2003-02-21T12:43:08Z] <benja/#gzz> scroll blocks are not pointed to by pointer blocks  
 %[2003-02-21T12:43:16Z] <benja/#gzz> do you mean blocks containing documents?  
 %[2003-02-21T12:43:26Z] <hemppah/#gzz> yes, regular data blocks  
 %[2003-02-21T12:43:52Z] <benja/#gzz> then it's 1) urn-5, 2) document block, 3) pointer block  
 %[2003-02-21T12:44:14Z] <hemppah/#gzz> ok, that's way I thought it  
 %[2003-02-21T12:44:15Z] <benja/#gzz> and for the next version, only document block and then pointer block  
1657    
1658    
1659  P2P network requirements  P2P network requirements
# Line 1797  Please notice: In this approach, DHT doe Line 1836  Please notice: In this approach, DHT doe
1836          +blocks have unique IDs, they can be used as keys in DHT, it's a natural choice          +blocks have unique IDs, they can be used as keys in DHT, it's a natural choice
1837          +DHT will find a resource, if it exists in a network          +DHT will find a resource, if it exists in a network
1838          +for a specific urn-5, we could find all associated block information from a single peer          +for a specific urn-5, we could find all associated block information from a single peer
1839          -for every urn-5, there is one permanent ID          -for every urn-5, there is one permanent pointer block (with ID)
1840          -for every version of block, there is one permanent ID          -for every version of block, there is one permanent ID
1841          -for every version of xu link, there is one permanent ID (does transclusion have different versions ?)          
         -for every version xu transclusion, there is one permanent ID (does links have different versions ?)  
1842    
1843    
1844  \bibliographystyle{gradu}  \bibliographystyle{gradu}

Legend:
Removed from v.1.62  
changed lines
  Added in v.1.63

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