|
1. Approaches |
|
1 |
|
|
|
Please notice: in this section + = pro, - = con |
|
2 |
|
|
3 |
There are five approaches when performing searches in p2p networks. |
1. Approaches |
4 |
|
|
5 |
|
-there are five approaches when performing searches in p2p networks. |
6 |
|
-please notice that in this section *all* the pros and cons are not mentioned |
7 |
|
-all characterizations do not apply to all examples which are given |
8 |
|
|
9 |
1.1. Distributed Hash Tables (DHT) |
1.1. Distributed Hash Tables (DHT) |
10 |
|
|
69 |
Kademlia: N/A O(log n) O(log n) |
Kademlia: N/A O(log n) O(log n) |
70 |
Viceroy: N/A 7 O(log n) |
Viceroy: N/A 7 O(log n) |
71 |
Small Worlds: N/A O(1) O(log^2 n) |
Small Worlds: N/A O(1) O(log^2 n) |
72 |
Flooding: N/A N/A No limit! |
Flooding: N/A O(1) "high" |
73 |
Hybrid: N/A N/A N/A |
Hybrid: N/A N/A N/A |
74 |
Social: N/A N/A N/A |
Social: N/A N/A N/A |
75 |
|
|
79 |
Number of messages when a node joins or leaves the network. |
Number of messages when a node joins or leaves the network. |
80 |
|
|
81 |
Space: |
Space: |
82 |
How many neighbour nodes each node maintains in routing table. |
Total amount of space required in a system for routing tables |
83 |
|
|
84 |
Search: |
Search: |
85 |
Number of messages when an object lookup is performed |
Number of messages when an object lookup is performed |
143 |
|
|
144 |
2.2.1. Facts |
2.2.1. Facts |
145 |
-urn-5 is random "unique keyword", e.g. "Front page of New York Times newspaper" |
-urn-5 is random "unique keyword", e.g. "Front page of New York Times newspaper" |
146 |
-urn-5 can be updated |
-urn-5 can't be udated, but we can associate a new block with the urn-5 name |
147 |
-urn-5 name is saved in the header of Storm block (|block urn-5: "Front page of New York Times newspaper"|) |
-urn-5 name is saved in the header of Storm block (|block urn-5: "Front page of New York Times newspaper"|) |
148 |
|
-urn-5 names can be created before Storm blocks |
149 |
-key signings are saved in separate Storm blocks |
-key signings are saved in separate Storm blocks |
150 |
-finding key blocks for data block can be performed locally (in logarithmic time) |
-finding key blocks for data block can be performed locally ("fast enough") |
151 |
-node has an internal index for key blocks and associated data blocks |
-node has an internal index for key blocks and associated data blocks |
152 |
-for every urn-5 name, there is zero, one or more Storm blocks associated with it |
-for every urn-5 name, there is zero, one or more Storm blocks associated with it |
153 |
|
-in every block's header, there is a timestamp for date&time |
154 |
|
|
155 |
2.2.2. Objectives |
2.2.2. Objectives |
156 |
-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 |
-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 |
157 |
-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 |
158 |
return the most recent block, if the signing key is "valid"." |
return the most recent block, if the signing key is "valid"." |
159 |
|
|
168 |
-one for urn-5 names, which are associated with block IDs |
-one for urn-5 names, which are associated with block IDs |
169 |
-is this approach too difficult to maintain ? |
-is this approach too difficult to maintain ? |
170 |
|
|
171 |
|
|
172 |
-is there possibility, in the specific urn-5 name, to maintain information about most recent block's ID for better search performance (or moreover, |
-is there possibility, in the specific urn-5 name, to maintain information about most recent block's ID for better search performance (or moreover, |
173 |
tree based structure for all blocks for specific urn-5 name) ? |
tree based structure for all blocks for specific urn-5 name) ? |
174 |
|
-How CAs' data should be saved ? |
175 |
|
|
176 |
|
|
177 |
2.3. "Searching for Storm blocks associated with specific urn-5 name, where |
2.3. "Searching for Storm blocks associated with specific urn-5 name, where |
179 |
has been signed with a given key" |
has been signed with a given key" |
180 |
|
|
181 |
2.3.1. Facts |
2.3.1. Facts |
182 |
-in addition to section 2.2.1, in every block's header, there is a timestamp for date&time |
-same as for 2.2.1. |
183 |
|
|
184 |
2.3.2. Objectives |
2.3.2. Objectives |
185 |
-Find the specific (most recent) Storm block as quicly as possible (and return it to the user) based on the given urn-5 |
-Find the specific (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 |
186 |
*and* a given date (range ?) |
*and* a given date (range ?) |
187 |
-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 |
188 |
return the most recent block, if the signing key and block's timestamp are "valid"." |
return the most recent block, if the signing key and block's timestamp are "valid"." |
200 |
|
|
201 |
-is there possibility, in the specific urn-5 name, to maintain information about most recent block's ID for better search performance (or moreover, |
-is there possibility, in the specific urn-5 name, to maintain information about most recent block's ID for better search performance (or moreover, |
202 |
tree based structure for all blocks for specific urn-5 name) ? |
tree based structure for all blocks for specific urn-5 name) ? |
203 |
|
-How CAs' data should be saved ? |
204 |
|
|
205 |
|
|
206 |
|
|
207 |
|
2.4. "How does search engine should work?" |
208 |
|
|
209 |
|
2.4.1 Facts |
210 |
|
-There might be vicious blocks (urn-5 names, Storm blocks) in the network |
211 |
|
|
212 |
|
2.4.2 Objectives |
213 |
|
-Search engine should only return the blocks which are genuine (is this possible at this level ??) |
214 |
|
-Should be fast |
215 |
|
-realtime (?): show search results as data is founded from the network |
216 |
|
-relevance of data (or not ?) |
217 |
|
-keyword/fuzzy search support |
218 |
|
-should be able to determine (somehow) is the returned data correct or not (CAs !?) |
219 |
|
|
220 |
|
2.4.3. Existing approaches and this specific research problem |
221 |
|
|
222 |
|
a) DHTs and SWNs |
223 |
|
-currently, there is no support for keyword/fuzzy searches |
224 |
|
-however, in Overnet (Kademlia), there is support for keyword searches. Here's one example of Overnet's protocol: |
225 |
|
ed2k://|file|file_name_his_here|file_size_is_here_in_bytes|file_hash_is_here| |
226 |
|
ed2k://|file|Threads_-_The_closest_youll_ever_want_to_come_to_nuclear_war.jpg|271725|94bee4ec22f5e5493081a3df0bdd1595| |
227 |
|
-Metadata ? |
228 |
|
|
229 |
|
b) FBNs |
230 |
|
-there is a support for keyword/fuzzy searches |
231 |
|
|
232 |
|
2.4.4. Open questions: |
233 |
|
-can we benefit from block's ID somehow? Could we use it for authenticating urn-5 names: check urn-5 name's most recent block's ID, |
234 |
|
and make decisions from that !? |
235 |
|
-should search engine return all data or only part of data, which is genuine ? |
236 |
|
-How we know if data is genuine or not ? |
237 |
|
-How CAs' data should be saved ? |
238 |
|
|
239 |
|
|
240 |
|
2.5. "Searching for all transclusions, which all refer into a specific point of specific document, from |
241 |
|
several blocks." |
242 |
|
|
243 |
|
2.5.1. Objectives |
244 |
|
-find and return all the transclusions from the network, which refer to specific point of specific document, if exists |
245 |
|
-simple pseudo thinking: "Find all blocks in the network and check if block refers to a specific part of specific |
246 |
|
document. If ok, return it." |
247 |
|
|
248 |
|
|
249 |
|
2.5.2. Facts |
250 |
|
-transclusion is a part of a document (with block-id X) that says: "here, use 20 bytes of block Y offset 52" |
251 |
|
|
252 |
|
2.5.3. Open questions |
253 |
|
-how transclusions are saved: is there somekind of urn/uri/hash in the block's header, which refers to another block ? |
254 |
|
-how part information (range, offset) of another block are defined and where this information is saved ? |
255 |
|
|
256 |
|
|
257 |
|
2.6. "Searching for all transclusions, which all refer into a specific point of specific document, from |
258 |
|
several blocks, where only *some* of the transclusions are relevant." |
259 |
|
|
260 |
|
2.6.1. Objectives |
261 |
|
|
262 |
|
2.6.2. Facts |
263 |
|
-transclusion is a part of a document (with block-id X) that says: "here, use 20 bytes of block Y offset 52" |
264 |
|
-simple pseudo thinking: "Find all blocks in the network and check if block refers to a specific part of specific |
265 |
|
document, and check that certain requirements are met. If ok, return it." |
266 |
|
|
267 |
|
|
268 |
|
2.6.3. Open questions |
269 |
|
-how transclusions are saved: is there somekind of urn/uri/hash in the block's header, which refers to another block ? |
270 |
|
-how part information (range, offset) of another block are defined and where this information is saved ? |
271 |
|
-how are the conditions given ? |
272 |
|
-in practice, what are the conditions, and how these conditions should be applied ? |
273 |
|
|
274 |
|
2.7. "Searching for all Xanadu links, which all refer into a specific point of specific document, from |
275 |
|
several blocks." |
276 |
|
|
277 |
|
|
278 |
|
2.7.1. Objectives |
279 |
|
- |
280 |
|
|
281 |
|
2.7.2. Facts |
282 |
|
-A Xanadu link is a document saying (with block-id X ?): "The 20 bytes of block Y offset 52 are connected to 40 bytes of block Z, offset 40, because |
283 |
|
they talk about the same thing" |
284 |
|
|
285 |
|
-how Xanadu links are saved: is there somekind of urn/uri/hash in the block's header, which refers to another block ? |
286 |
|
|
287 |
|
2.7.3. Open questions |
288 |
|
|
289 |
|
2.8. "Searching for all Xanadu links, which all refer into a specific point of speficic document, from |
290 |
|
several blocks, where only *some* of the Xanadu links are relevant." |
291 |
|
|
292 |
|
-A Xanadu link is a document saying (with block-id X ?): "The 20 bytes of block Y offset 52 are connected to 40 bytes of block Z, offset 40, because |
293 |
|
they talk about the same thing" |
294 |
|
|
295 |
|
2.8.3. Open questions |
296 |
|
-how Xanadu links are saved: is there somekind of urn/uri/hash in the block's header, which refers to another block ? |