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 |
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, |
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 |
|
|