/[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.63 by hemppah, Mon Feb 24 12:21:37 2003 UTC revision 1.64 by hemppah, Mon Feb 24 13:24:41 2003 UTC
# Line 1516  We start by giving an overview of Gzz Pe Line 1516  We start by giving an overview of Gzz Pe
1516  we define our objectives and special needs and consider possible  we define our objectives and special needs and consider possible
1517  benefits over existing Peer-to-Peer filesharing systems. Finally, we  benefits over existing Peer-to-Peer filesharing systems. Finally, we
1518  evaluate different peer-to-peer systems with regard to Gzz, make  evaluate different peer-to-peer systems with regard to Gzz, make
1519  initial analsysis and discuss possible problems.  initial analsysis and discuss possible problems. In the following
1520    sections, we don't respond security issues. In fact, we assume
1521    that system has a working distributed Public Key Infrastructure
1522    for identifying invidual entities.
1523    
1524    
1525  Fething videos, pictures, music and other media:  Fething videos, pictures, music and other media:
# Line 1548  sequential and random access. This memo Line 1550  sequential and random access. This memo
1550        
1551        
1552        
1553     \cite{mohr02thex}    
1554     \cite{overneturl}     \cite{overneturl}
1555     \cite{edonkey2kurl}     \cite{edonkey2kurl}
1556      
1557       \cite{bittorrenturl}
1558    \cite{maymounkov03ratelesscodes}
1559    
1560  \section{Overview}  \section{Overview}
1561    
# Line 1638  location independent routing), since Sto Line 1643  location independent routing), since Sto
1643  for identifying scroll blocks. Of course, Peer-to-Peer infrasctructure has to be  for identifying scroll blocks. Of course, Peer-to-Peer infrasctructure has to be
1644  scalable, efficient, adaptive, robust, self-organising and resistant againts DDoS  scalable, efficient, adaptive, robust, self-organising and resistant againts DDoS
1645  attacks. Additionally, if possible, it would be benefitial if Peer-to-Peer system  attacks. Additionally, if possible, it would be benefitial if Peer-to-Peer system
1646  would represent all named resources keys.  would represent all named resources as keys.
   
   
   
   
1647    
1648  Gzz's requirements  \section{Benefits over existing Peer-to-Peer file sharing systems}
 -append-and-delete (when a modification has been commited, a new version must be created)  
 -the same data block can be stored to many different locations (can we use 'How share a secret ?', like in Publius and Tangler ?)  
 -old version(s) must remain accessible in the network  
 -must support xanalogical structure  
 -links must work always  
 -*selective* replication/synking  
 -do we have a support for transcopyright ?  
   
   
   
   
 P2P network requirements  
 -system must find the service, if it exists in the network  
 -following properties: scalable, efficient, adaptive, robust, self-organising  
 -is possible, it would be benefitial if p2p system representing named resources as keys  
 -p2p system must support the use of block IDs (SHA-1) and urn-5s (random string) when obtaining data from the network  
 -one or more blocks are associated with a specific urn-5  
 -support for location independent routing (urn-5 -> block(s))  
 -data block can represent a link, document/part of document, transclusion  
 -must perform well under DDoS attacks  
1649    
1650  \cite{bittorrenturl}  Since Storm uses SHA-1 hash function for creating globally unique
1651  \cite{maymounkov03ratelesscodes}  identifiers, if necessary, we can check the integrity of a scroll
1652    block by re-computing hash value for a scroll block, once fetched
1653    form the network. Indeed, all scroll blocks' identifiers are
1654    self-certifying. However, this not very efficient when we want
1655    fetch large amounts of data. One possibility is to use tree-based
1656    hash techiques (e.g., \cite{merkle87hashtree}, \cite{\cite{mohr02thex})
1657    for more efficient data fetcing. Tree based hash functions can be used
1658    to verify fixed length segments of data file, instead of whole data file.
1659    Currently, Shareaza \cite{shareazaurl}, Overnet \cite{overneturl} and
1660    eDonkey2000 \cite{edonkey2kurl} uses tree based hashing for validating
1661    segments of a data file.
1662    
 \section{Benefits over existing Peer-to-Peer file sharing systems}  
1663    
1664  - Easy syncing:  - Easy syncing:
1665    - Just copy a bunch of blocks    - Just copy a bunch of blocks

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

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