/[gzz]/gzz/Documentation/misc/hemppah-progradu/research_problems
ViewVC logotype

Diff of /gzz/Documentation/misc/hemppah-progradu/research_problems

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.1 by hemppah, Thu Dec 12 14:32:30 2002 UTC revision 1.2 by hemppah, Mon Dec 16 13:53:19 2002 UTC
# Line 1  Line 1 
 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    
# Line 67  Tapestry:      O(log^2 n)      O(nlog n)       O(log n) Line 69  Tapestry:      O(log^2 n)      O(nlog n)       O(log n)
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    
# Line 77  Insert/Delete: Line 79  Insert/Delete:
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
# Line 141  e) SDS Line 143  e) SDS
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    
# Line 164  return the most recent block, if the sig Line 168  return the most recent block, if the sig
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
# Line 173  tree based structure for all blocks for Line 179  tree based structure for all blocks for
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"."
# Line 194  return the most recent block, if the sig Line 200  return the most recent block, if the sig
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 ?

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.2

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