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 |
|
|
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 |
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 |
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"." |
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 ?) |
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 |
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} |