/[gzz]/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
ViewVC logotype

Diff of /gzz/Documentation/misc/hemppah-progradu/masterthesis.tex

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

revision 1.55 by hemppah, Thu Feb 20 11:57:32 2003 UTC revision 1.56 by hemppah, Thu Feb 20 12:58:06 2003 UTC
# Line 159  server to find other nodes and/or files Line 159  server to find other nodes and/or files
159  \section{Loosely structured}  \section{Loosely structured}
160    
161    
162    power-law disribution
163    
164  +own resources are not mapped into the network  +own resources are not mapped into the network
165  +keyword/fuzzy search possible  +keyword/fuzzy search possible
166  -based on FBNt technique,  -based on FBNt technique,
# Line 1570  From Benja's (plus antont and me) articl Line 1572  From Benja's (plus antont and me) articl
1572  -current p2p systems don't support all of these properties together  -current p2p systems don't support all of these properties together
1573    
1574    
1575  \section{Possible problems}  \section{Evaluation}
1576    
1577    2.1.5. Answers to research problem
1578    -the most efficient algorithm: O(log n)
1579            -DHTs requires O(log n) hops, log n neighbors, except Viceroy (however, robustness suffers)
1580            %-SWNs requires O(log^2 n) hops, much less neighbors (constant, is not depedent of n)
1581    -in DHTs and SWNs, it is possible to locate data in constant time, BUT it requires knowing all n neighbors!!!
1582    -in basic scenario, DHTs and SWTs assume that we have to know value's key beforehand
1583    -in this case, DHTs and SWNs require little bandwidth, because "network knows where the block resides"
1584    -in this case, FBNs, Hybrids, Social Discovery require much bandwidth, since there is no benefit from the block's ID at all (they have to ask constantly)
1585    -SWNs and FBSs require less memory than DHTs, since in these approaches, there are less connections to other nodes
1586    -SWNs relies less to neighbor nodes than DHTs
1587    -there are different kinds of uses of DHTs, e.g. DHT actually stores the data, or DHT only stores
1588    the values, which are used for locating the data
1589    -existing systems mainly uses the latter method
1590    -both have pros and cons:
1591            -in the value use, several hostile nodes might say that they hosts the value, but refuse to serve any host
1592            -in the storage use, hostile node might say that someone must save data block size of 1TB for her computer
1593            -however, there are methods for preventing these kinds of actions (look below)
1594    -DHTs and SWNs are very robust to failures: e.g. 20% of the nodes simultaneously fail, less than 0.1% of the data retrievals are failed
1595    (each node has "enough neighbors for alternative routing path)
1596    -however, in other approaches, the network infracstructure is very vulnerable: usually FBNs/hybrid networks follows the power-law distribution,
1597    in which, there are many nodes connected to one node. So, when this "super node" is under DoS attach, the performance of the network suffers a lot -->
1598    most of data retrievals could fail
1599    -when locating data blocks, the basic difference between DHTs/SWNs is that in DHT/SWN approach, systems "knows", where the desired data block resides
1600            -based on data block ID's, nodes gives "hints" (routes more close to ID in the key space) constantly to a query lookup until
1601            the specific node is found which hosts the block
1602            -no extra network traffic
1603    -so in a way, DHT/SWNs are structured entities
1604    -instead, in other approaches, system doesn't "know" where the data block resides
1605            -we have to ask from any participating node, if they have the data block
1606            -very much extra network traffic
1607    -proposol: most efficient approaches for this research problem are DHTs and SWNs, since they are based on key-value pairs (Storm has a key as block ID)
1608    -research challenges for DHTs/SWNs:
1609    
1610    
1611    2.2.3. Existing approaches and this specific research problem
1612    
1613    -First, *all* blocks (with the specific urn-5 name) have to checked and analysed
1614    -In this case (urn-5), there is no benefit from the block's ID at all (DHT, SWN)
1615    
1616    2.2.4. Open questions:
1617    -in this case, is it sensible to maintain two different key-value mappings key-value based systems (DHT, SWN) ?l
1618            -one fore block IDs
1619            -one for urn-5 names, which are associated with block IDs
1620            -is this approach too difficult to maintain ?
1621    
1622    -is there possibility, in the specific urn-5 name, to maintain information about most recent block's ID for better search performance (or moreover,
1623    tree/list based structure for all blocks for specific urn-5 name) ?
1624    -How CAs' data should be saved ?
1625    
1626    2.2.5. Answers to research problem
1627    -compared to previous research problem, the "obvious" benefits of DHTs and SWNs in this research problem are smaller
1628    -we don't beforehand know which block is the most recent associated with a specfic urn-5 name
1629    -in theory, though, the most efficient algorithm is O(log n), *assuming* that we already know the most recent block's ID (see previous research problem)
1630    -the most important question is, how we can efficiently associate urn-5 names with the most recent block / to all blocks which are associated with it
1631    -for DHTs and SWNs:
1632    
1633    Please notice: In this approach, DHT doesn't store the actual block, only the values for locating the data from the system
1634    
1635            Req. 1:
1636            -each node maintains a local hash-table based data structure (urn-5 name -> most recent local block ID) for every urn-5 names
1637            which node hosts. The most recent block is topmost --> we don't have to check all blocks and their urn-5 associations to get the most recent
1638            Req. 2:
1639            -all urn-5 name mappings are stored as <key, value[ ]>, where the key is urn-5 name's hash and value is a record containing
1640            block ID and timestamp of that block. So, when we store a block in our system first time, we have to create a new key-value:
1641            %<hash_of_urn_5_name, [block id, block timestamp]> and route this mapping to node which is "closest" to a hash value. Now when we want to find the most
1642            recent block associated with a specific urn-5 name, we do:
1643            
1644                    1. locally compute a hash for given urn-5 string
1645                    2. route the query to a node which hosts the given hash of urn-5 ("closest" node)
1646                    3. get most recent block's ID using the idea from previuos idea
1647                    4. use ID to get the specific block using normal DHT/SWN operation
1648                    
1649            In this approach, we don't have to perform additional searching and sorting of mappings. And of course, we know that for given urn-5, only one node
1650            hosts *all* the block information ("block history") for the urn-5, since mappings are mapped to a single node, closest to urn-5 hash value.
1651            Again, this should work fine under existing DHTs (and SWTs ?).
1652            
1653            Some simple analysis:
1654            -there are more key-value pairs in the system for additional urn-5 --> block associations
1655            -however, I don't think this is an issue, since data's size is small
1656            -efficiency: find node which hosts urn-5 names + find node which hosts blocks associated with urn-5 name: logn + logn = 2logn (logarithmical)
1657            
1658    -for FBS and others:
1659            -there is no very efficient (simple) methods for finding urn-5 name associated with the most recent block
1660            -one simple proposal is that when we visit to each node (first idea above), get only the most recent one and compare them (or greedy approach: dismiss currently
1661            most recent block as we visit to nodes, if newer block have been found)
1662    
1663            
1664            2.3.3. Existing approaches and this specific research problem
1665    
1666    -First, *all* blocks (with the specific urn-5 name) have to checked and analysed
1667    -In this case (urn-5), there is no benefit from the block's ID at all (DHT, SWN)
1668    
1669    2.3.4 Open questions:
1670    -in this case, is it sensible to maintain two different key-value mappings key-value based systems ?
1671            -one mapping fore block IDs
1672            -one mapping for urn-5 names, which are associated with block IDs
1673            -is this approach too difficult to maintain ?
1674            
1675    -is there possibility, in the specific urn-5 name, to maintain information about most recent block's ID for better search performance (or moreover,
1676    tree based structure for all blocks for specific urn-5 name) ?
1677    -How CAs' data should be saved ?
1678    
1679    2.3.5. Answers to research problem
1680    This is quite similar to previous research problem's answer. There are slight differences, though.
1681    
1682    -for DHTs and SWNs:
1683    
1684    Please notice: In this approach, DHT doesn't store the actual block, only the values for locating the data from the system
1685    
1686            Req. 1:
1687            -each node maintains a local hash-table based data structure (urn-5 name -> most recent local block ID) for every urn-5 names
1688            which node hosts. The most recent block is topmost --> we don't have to check all blocks and their urn-5 associations to get the most recent
1689            Req. 2:
1690            -all urn-5 name mappings are stored as <key, value[ ]>, where the key is urn-5 name's hash and value is a record containing
1691            block ID and timestamp of that block. So, when we store a block in our system first time, we have to create a new key-value:
1692            %<hash_of_urn_5_name, [block id, block timestamp]> and route this mapping to node which is "closest" to a hash value. Now when we want to find the most
1693            recent block associated with a specific urn-5 name, we do:      
1694            
1695                    1. locally compute a hash for given urn-5 string
1696                    2. route the query to a node which hosts the given hash of urn-5 ("closest" node)
1697                    %3. get the specific block(s) data (block ID) from the stack which matches to given date&time properties (we compare to block header data)
1698                    4. use IDs to get the specific blocks using normal DHT/SWN operation            
1699            
1700            Some simple analysis:
1701            -there are more key-value pairs in the system for additional urn-5 --> block associations
1702            -however, I don't think this is an issue, since data's size is small
1703            -efficiency: find node which hosts urn-5 names + find node which hosts blocks associated with urn-5 name: logn + logn = 2logn (logarithmical)
1704            
1705    -for FBS and others:
1706            -there is no very efficient (simple) methods for finding urn-5 name associated with the most recent block
1707            -one simple proposal is that when we be that we visit to each node (first idea above), get all blocks which matches to given properties
1708          
1709    
1710    \section{Open issues and future work}
1711    
1712  \cite{gribble01p2pdatabase}  \cite{gribble01p2pdatabase}
1713    

Legend:
Removed from v.1.55  
changed lines
  Added in v.1.56

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