72 |
|
|
73 |
\section{Research problems} |
\section{Research problems} |
74 |
|
|
75 |
|
a)* Mist? riippuu ja kuinka nopeaa nykyisill? algoritmeilla |
76 |
|
on tietyn storm-blokin haku mist? tahansa? |
77 |
|
|
78 |
|
--> Distributed hash, esim. CAN, Chord jne. (Overview) |
79 |
|
|
80 |
|
- summarize current research, specifically on problems |
81 |
|
where we cannot trust any servers, and where |
82 |
|
probability distributions for the blocks are used. |
83 |
|
Bibtex references. |
84 |
|
|
85 |
|
b)* Mist? riippuu ja kuinka nopeaa nykyisill? algoritmeilla |
86 |
|
on tiettyyn urn-5 -nimeen liitetyn uusimman blokin haku |
87 |
|
(jossa uusin blokki allekirjoitettu annetulla avaimella) |
88 |
|
|
89 |
|
c)* Mist? riippuu ja kuinka nopeaa nykyisill? algoritmeilla |
90 |
|
on tiettyyn urn-5 -nimeen liitetyn annettuna aikana |
91 |
|
olleen blokin haku ("Hesarin etusivu 3.6.-02")? |
92 |
|
(jossa blokki allekirjoitettu annetulla avaimella) |
93 |
|
|
94 |
|
*=Näiden jälkeen voidaan miettiä, voidaanko systeemiä tehdä |
95 |
|
ilman hierarkiaa (Tumbler). |
96 |
|
|
97 |
|
"Mistä riippuu" = Skaalautuvuus (verkokoko, datamäärä, levinneisyys, verkon kytkeytyvyys) |
98 |
|
|
99 |
|
|
100 |
\section{Thesis overview} |
\section{Thesis overview} |
101 |
|
|
102 |
definition \cite{p2pworkinggroup} |
definition \cite{p2pworkinggroup} |
136 |
-a service request is totally based on centralized index |
-a service request is totally based on centralized index |
137 |
-system doe find the service, if it exists |
-system doe find the service, if it exists |
138 |
|
|
139 |
|
-These kind of systems have a constantly updated database/directory |
140 |
|
which is hosted at central locations. |
141 |
|
-Nodes in the p2p networks performs a requests to the central directory |
142 |
|
server to find other nodes and/or files |
143 |
|
-Do not scale well |
144 |
|
-Have a single point of failure |
145 |
|
-Example: Napster |
146 |
|
|
147 |
\subsection{Formal definition} |
\subsection{Formal definition} |
148 |
|
|
175 |
-system doesn't have *any* knowledge, where service is located (opposite to centralized and decentralized but structured) (Gnutellas) |
-system doesn't have *any* knowledge, where service is located (opposite to centralized and decentralized but structured) (Gnutellas) |
176 |
-system doesn't not necessary find the service, if it exists |
-system doesn't not necessary find the service, if it exists |
177 |
|
|
178 |
|
-Gnutella: Uses a breadt-First traversal (BFS) with depth limit L, where L is the system-wide |
179 |
|
maximum TTL of a message in hops. Every node receiving a query will forward the message |
180 |
|
to all of its neighbour nodes, unless the message has reached the TTL limit |
181 |
|
-Freenet: a depth-first traversal (DFS) with depth limit L. Each node forwards the query |
182 |
|
to a single neighbor (determined by ID) and waits for a definite response from the neighbor |
183 |
|
before forwarding the query to another neighbor (if query not ok), or forwarding results back |
184 |
|
to the query source (if query ok) |
185 |
|
|
186 |
|
BFS |
187 |
|
-Search results are fast, because BFS sends queries to every possible nodes |
188 |
|
-Wastes resources, because BFS sends queries to every possible nodes |
189 |
|
|
190 |
|
|
191 |
|
DFS |
192 |
|
-Poor response time, beecause each node processes the query sequentially... |
193 |
|
-...and thereby minimazing cost |
194 |
|
|
195 |
|
|
196 |
\begin{figure} |
\begin{figure} |
197 |
\centering |
\centering |
198 |
\includegraphics[width=6cm, height=6cm]{gnutella_overlay.eps} |
\includegraphics[width=6cm, height=6cm]{gnutella_overlay.eps} |
875 |
|
|
876 |
|
|
877 |
\subsection{Efficient data lookup} |
\subsection{Efficient data lookup} |
878 |
|
|
879 |
|
-Object's popularity: studies have shown that Napster, Gnutella and Web |
880 |
|
queries follow Zipf-like distributions (1/2, 1/3, 1/4 etc.) |
881 |
|
|
882 |
|
|
883 |
|
Proposals (Yand et all): |
884 |
|
|
885 |
|
Iterative Deepening |
886 |
|
In Iterative Deepening, multiple BFS are initiated with successively larger |
887 |
|
depths limits, until either they query is satisfied, or the maximum depth L |
888 |
|
has been reached |
889 |
|
|
890 |
|
Directed BFS |
891 |
|
Implements a strategy where a source sends a query messages to just a subset |
892 |
|
of neighbours and selecting neighbors through which nides with many quality results |
893 |
|
may be reached. Node may select a neighbor that has produced or forwarded many |
894 |
|
many quality results in the past, on the premise that past performance is a good |
895 |
|
indication of future performance. |
896 |
|
|
897 |
|
Local Indices |
898 |
|
In this method, each node N maintains an index over the data of all nodes within h hops |
899 |
|
of itself, where h is a system-wide variable known as radius of the index (h=0 is th BFS case). |
900 |
|
When a node receives a query message, it can process the query on behalf of every node within |
901 |
|
r hops. |
902 |
|
|
903 |
|
|
904 |
\cite{ratnasamy02routing} |
\cite{ratnasamy02routing} |
905 |
\cite{hildrum02distributedobject} |
\cite{hildrum02distributedobject} |
906 |
\cite{adamic02localsearch} |
\cite{adamic02localsearch} |
1465 |
-uses SHA-1 for checking data integrity (suits for us very well!) |
-uses SHA-1 for checking data integrity (suits for us very well!) |
1466 |
-we don't have to create 'mini-blocks' for Gzz p2p, since bitTorrent itself partitions data into several blocks for us |
-we don't have to create 'mini-blocks' for Gzz p2p, since bitTorrent itself partitions data into several blocks for us |
1467 |
|
|
1468 |
|
5.1 The Merkle Hash Tree |
1469 |
|
|
1470 |
|
The Merkle Hash Tree, invented by Ralph Merkle, is a hash construct that has very nice properties for |
1471 |
|
verifying the integrity of files and file subranges in an incremental or out-of-order fashion. This |
1472 |
|
document describes a binary serialization format for hash trees that is compact and optimized for both |
1473 |
|
sequential and random access. This memo has two goals: |
1474 |
|
|
1475 |
|
1. To describe Merkle Hash Trees and how they are used for file integrity verification. |
1476 |
|
2. To describe a serialization format for storage and transmission of hash trees. |
1477 |
|
|
1478 |
\section{Overview} |
\section{Overview} |
1479 |
|
|
1480 |
-need to make Gzz distributed system |
-need to make Gzz distributed system |