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