234 |
peers can form the overlay network based on \emph{local} knowledge. Figure \ref{fig:gnutella_overlay} |
peers can form the overlay network based on \emph{local} knowledge. Figure \ref{fig:gnutella_overlay} |
235 |
illustrates how peers form an overlay network. Initially, peer 1 creates the overlay, since |
illustrates how peers form an overlay network. Initially, peer 1 creates the overlay, since |
236 |
it's the first participating peer. Then, repeatedly new peers join the network and connect to |
it's the first participating peer. Then, repeatedly new peers join the network and connect to |
237 |
other nodes in a random manner. Thus, Gnutella can be considered as a variation of \emph{scale-free |
other peers in a random manner. Thus, Gnutella can be considered as a variation of \emph{scale-free |
238 |
graph}\footnote{In scale-free graphs (also known as power-law graphs) only a few peers have high number of neighbor |
graph}\footnote{In scale-free graphs (also known as power-law graphs) only a few peers have high number of neighbor |
239 |
links and major of peers have low number of neighbor links.}. |
links and major of peers have low number of neighbor links.}. |
240 |
|
|
302 |
\begin{figure} |
\begin{figure} |
303 |
\centering |
\centering |
304 |
\includegraphics[width=10cm, height=6cm]{gnutella_overlay_clusters.eps} |
\includegraphics[width=10cm, height=6cm]{gnutella_overlay_clusters.eps} |
305 |
\caption{Power-law network overlay with 2-redundant super node clusters.} |
\caption{Power-law network overlay with 2-redundant super peer clusters.} |
306 |
\label{fig:gnutella_overlay_cluster} |
\label{fig:gnutella_overlay_cluster} |
307 |
\end{figure} |
\end{figure} |
308 |
|
|
334 |
This list includes CAN \cite{ratnasamy01can}, Chord \cite{stoica01chord}, |
This list includes CAN \cite{ratnasamy01can}, Chord \cite{stoica01chord}, |
335 |
Kademlia \cite{maymounkov02kademlia}, Kelips \cite{gupta03kelips}, |
Kademlia \cite{maymounkov02kademlia}, Kelips \cite{gupta03kelips}, |
336 |
Koorde \cite{kaashoek03koorde}, ODHDHT \cite{naor03simpledht}, |
Koorde \cite{kaashoek03koorde}, ODHDHT \cite{naor03simpledht}, |
337 |
Pastry \cite{rowston01pastry}, Peernet \cite{eriksson03peernet}, |
Pastry \cite{rowston01pastry}, PeerNet \cite{eriksson03peernet}, |
338 |
Skip Graphs \cite{AspnesS2003}, SkipNet \cite{harvey03skipnet2}, |
Skip Graphs \cite{AspnesS2003}, SkipNet \cite{harvey03skipnet2}, |
339 |
Symphony \cite{gurmeet03symphony}, SWAN \cite{bonsma02swan}, Tapestry |
Symphony \cite{gurmeet03symphony}, SWAN \cite{bonsma02swan}, Tapestry |
340 |
\cite{zhao01tapestry}, Viceroy \cite{malkhi02viceroy} and others \cite{freedman02trie}. |
\cite{zhao01tapestry}, Viceroy \cite{malkhi02viceroy} and others \cite{freedman02trie}. |
397 |
assigned keys.} keys is removed at the cost of each peer maintaining one |
assigned keys.} keys is removed at the cost of each peer maintaining one |
398 |
''resource peer'' in the overlay network for each resource item pair it publishes. |
''resource peer'' in the overlay network for each resource item pair it publishes. |
399 |
|
|
400 |
PeerNet differs from other tightly structured overlays in that it operates |
PeerNet \cite{eriksson03peernet} differs from other tightly structured overlays in that it operates |
401 |
at the \emph{network} layer. PeerNet makes an explicit distinction |
at the \emph{network} layer. PeerNet makes an explicit distinction |
402 |
between peer identity and address, which is not supported by standard |
between peer identity and address, which is not supported by standard |
403 |
TCP/IP-protocols. Otherwise, PeerNet has the same performance properties |
TCP/IP-protocols. Otherwise, PeerNet has the same performance properties |
417 |
Currently, all proposed tightly structured overlays provide at least |
Currently, all proposed tightly structured overlays provide at least |
418 |
poly--logarithmical data lookup operations. However, there are some key |
poly--logarithmical data lookup operations. However, there are some key |
419 |
differences in the data structure that they use as a routing table. For example, Chord |
differences in the data structure that they use as a routing table. For example, Chord |
420 |
\cite{stoica01chord}, Skip graphs \cite{AspnesS2003} and Skipnet \cite{harvey03skipnet2} maintain a local |
\cite{stoica01chord}, Skip graphs \cite{AspnesS2003} and SkipNet \cite{harvey03skipnet2} maintain a local |
421 |
data structure which resembles Skip lists \cite{78977}. |
data structure which resembles Skip lists \cite{78977}. |
422 |
In figure \ref{fig:structured_query}, we present an overview of Chord's lookup process. |
In figure \ref{fig:structured_query}, we present an overview of Chord's lookup process. |
423 |
On the right side of Chord's lookup process, the same data lookup process |
On the right side of Chord's lookup process, the same data lookup process |
603 |
\parbox{100pt}{Controlled and structured} |
\parbox{100pt}{Controlled and structured} |
604 |
\\ \hline |
\\ \hline |
605 |
|
|
606 |
\parbox{90pt}{Max. number of nodes} & |
\parbox{90pt}{Max. number of peers} & |
607 |
\parbox{100pt}{Millions} & |
\parbox{100pt}{Millions} & |
608 |
\parbox{100pt}{Billions} |
\parbox{100pt}{Billions} |
609 |
\\ \hline |
\\ \hline |
706 |
\parbox{37pt}{$O$($d$)} & |
\parbox{37pt}{$O$($d$)} & |
707 |
\parbox{37pt}{$O(dn^{\frac{1}{d}})$} & |
\parbox{37pt}{$O(dn^{\frac{1}{d}})$} & |
708 |
\parbox{85pt}{2$d$} & |
\parbox{85pt}{2$d$} & |
709 |
\parbox{85pt}{The performance of system may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, where $d$ is the dimension of virtual key space} |
\parbox{85pt}{The performance of system may decrease if peers are not homogeneous and peers join and leave the system in a dynamic manner, where $d$ is the dimension of virtual key space} |
710 |
\\ \hline |
\\ \hline |
711 |
|
|
712 |
\parbox{37pt}{Chord \cite{stoica01chord}} & |
\parbox{37pt}{Chord \cite{stoica01chord}} & |
714 |
\parbox{37pt}{$O(\log{n}$} & |
\parbox{37pt}{$O(\log{n}$} & |
715 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
716 |
\parbox{85pt}{2$(\log{n})$} & |
\parbox{85pt}{2$(\log{n})$} & |
717 |
\parbox{85pt}{The performance of system may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner} |
\parbox{85pt}{The performance of system may decrease if peers are not homogeneous and peers join and leave the system in a dynamic manner} |
718 |
\\ \hline |
\\ \hline |
719 |
|
|
720 |
|
|
749 |
\parbox{37pt}{$O(2(\sqrt{n}*(log^2{n})) + (\sqrt{n} + (log^3{n})))$} & |
\parbox{37pt}{$O(2(\sqrt{n}*(log^2{n})) + (\sqrt{n} + (log^3{n})))$} & |
750 |
\parbox{37pt}{$O$($\sqrt{n}$)} & |
\parbox{37pt}{$O$($\sqrt{n}$)} & |
751 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
752 |
\parbox{85pt}{$\frac{n}{\sqrt{n}} + c*(\sqrt{n}-1) + \frac{Totalnumber of files}{\sqrt{n}}$, where n is the number of nodes and c the number of contacts/foreign affinity group} & |
\parbox{85pt}{$\frac{n}{\sqrt{n}} + c*(\sqrt{n}-1) + \frac{Totalnumber of files}{\sqrt{n}}$, where n is the number of peers and c the number of contacts/foreign affinity group} & |
753 |
\parbox{85pt}{Insert/delete overhead is constant and performed in the background, the performance of system may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner} |
\parbox{85pt}{Insert/delete overhead is constant and performed in the background, the performance of system may decrease if peers are not homogeneous and peers join and leave the system in a dynamic manner} |
754 |
\\ \hline |
\\ \hline |
755 |
|
|
756 |
\parbox{37pt}{Koorde \cite{kaashoek03koorde}} & |
\parbox{37pt}{Koorde \cite{kaashoek03koorde}} & |
775 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
776 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
777 |
\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable parameter for tuning digit-fixing properties (routing table)} & |
\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable parameter for tuning digit-fixing properties (routing table)} & |
778 |
\parbox{85pt}{The performance of system performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, based on Plaxton's algorithm} |
\parbox{85pt}{The performance of system performance may decrease if peers are not homogeneous and peers join and leave the system in a dynamic manner, based on Plaxton's algorithm} |
779 |
\\ \hline |
\\ \hline |
780 |
|
|
781 |
|
|
800 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
801 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
802 |
\parbox{85pt}{$4r(\log{n}) + (\log{n})$, where r=number of resources provided)} & |
\parbox{85pt}{$4r(\log{n}) + (\log{n})$, where r=number of resources provided)} & |
803 |
\parbox{85pt}{In this approach, node is treated as ''named resource''} |
\parbox{85pt}{In this approach peer is treated as ''named resource''} |
804 |
\\ \hline |
\\ \hline |
805 |
|
|
806 |
\parbox{37pt}{SkipNet \cite{harvey03skipnet2}} & |
\parbox{37pt}{SkipNet \cite{harvey03skipnet2}} & |
816 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
817 |
\parbox{37pt}{$O(n)$} & |
\parbox{37pt}{$O(n)$} & |
818 |
\parbox{85pt}{Can be 1-10000 connections (aka social connections, connections are permanent)} & |
\parbox{85pt}{Can be 1-10000 connections (aka social connections, connections are permanent)} & |
819 |
\parbox{85pt}{Number of connections number depends on node's memory/network capabilities} |
\parbox{85pt}{Number of connections number depends on peer's memory/network capabilities} |
820 |
\\ \hline |
\\ \hline |
821 |
|
|
822 |
\parbox{37pt}{Symphony \cite{gurmeet03symphony}} & |
\parbox{37pt}{Symphony \cite{gurmeet03symphony}} & |
823 |
\parbox{37pt}{$O(\log^2{n})$} & |
\parbox{37pt}{$O(\log^2{n})$} & |
824 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
825 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
826 |
\parbox{85pt}{$2k+2+f$, where k = long range connections, 2 = node's neighbors, f = fault-tolerance connections)} & |
\parbox{85pt}{$2k+2+f$, where k = long range connections, 2 = peer's neighbors, f = fault-tolerance connections)} & |
827 |
\parbox{85pt}{Space can be also $O(1)$. Additional space of can be used as a lookahead list for better performance, not necessarily fault-tolerant because of constant degree of neighbors} |
\parbox{85pt}{Space can be also $O(1)$. Additional space of can be used as a lookahead list for better performance, not necessarily fault-tolerant because of constant degree of neighbors} |
828 |
\\ \hline |
\\ \hline |
829 |
|
|
832 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
833 |
\parbox{37pt}{$O(\log^2{n})$} & |
\parbox{37pt}{$O(\log^2{n})$} & |
834 |
\parbox{85pt}{$r(2b+2s+2l)$ (where r=number of resources provided, b=boot connections, s=short range connections, l=long range connections), typical connection configuration: 2*(6+7+8)=36} & |
\parbox{85pt}{$r(2b+2s+2l)$ (where r=number of resources provided, b=boot connections, s=short range connections, l=long range connections), typical connection configuration: 2*(6+7+8)=36} & |
835 |
\parbox{85pt}{In this approach, node is treated as ''named resource''} |
\parbox{85pt}{In this approach, peer is treated as ''named resource''} |
836 |
\\ \hline |
\\ \hline |
837 |
|
|
838 |
|
|
841 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
842 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
843 |
\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable parameter for tuning digit-fixing properties (routing table)} & |
\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable parameter for tuning digit-fixing properties (routing table)} & |
844 |
\parbox{85pt}{The system performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, based on Plaxton's algorithm} |
\parbox{85pt}{The system performance may decrease if peers are not homogeneous and peers join and leave the system in a dynamic manner, based on Plaxton's algorithm} |
845 |
\\ \hline |
\\ \hline |
846 |
|
|
847 |
\parbox{37pt}{Viceroy \cite{malkhi02viceroy}} & |
\parbox{37pt}{Viceroy \cite{malkhi02viceroy}} & |
849 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
850 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
851 |
\parbox{85pt}{11} & |
\parbox{85pt}{11} & |
852 |
\parbox{85pt}{The system performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, not necessarily fault-tolerant because of constant degree of neighbors} |
\parbox{85pt}{The system performance may decrease if peers are not homogeneous and peers join and leave the system in a dynamic manner, not necessarily fault-tolerant because of constant degree of neighbors} |
853 |
\\ \hline |
\\ \hline |
854 |
|
|
855 |
|
|
1077 |
Fiat et al. in \cite{fiat02censorship}, \cite{saia02dynamicfaultcontentnetwork} and Datar in \cite{datar02butterflies} |
Fiat et al. in \cite{fiat02censorship}, \cite{saia02dynamicfaultcontentnetwork} and Datar in \cite{datar02butterflies} |
1078 |
describe tightly structured overlay with analytical results in the presence of hostile entities. However, |
describe tightly structured overlay with analytical results in the presence of hostile entities. However, |
1079 |
none of these proposals address an efficient, dynamic tightly structured overlay and multiple rounds |
none of these proposals address an efficient, dynamic tightly structured overlay and multiple rounds |
1080 |
of hostile attack. Also, above mentioned proposals are not very efficient. In \cite{fiat02censorship}, each node |
of hostile attack. Also, above mentioned proposals are not very efficient. In \cite{fiat02censorship}, each peer |
1081 |
must maintain information of $O(\log^3{n})$ other peers, and in \cite{datar02butterflies}, $O(\log^2{n})$ is required. |
must maintain information of $O(\log^3{n})$ other peers, and in \cite{datar02butterflies}, $O(\log^2{n})$ is required. |
1082 |
|
|
1083 |
Finally, Ratnasamy and Gavoille \cite{ratnasamy02routing}, \cite{gavoille01routing} list several open problems |
Finally, Ratnasamy and Gavoille \cite{ratnasamy02routing}, \cite{gavoille01routing} list several open problems |
1125 |
are Peer-to-Peer systems which use somewhat similar method when performing data lookups. |
are Peer-to-Peer systems which use somewhat similar method when performing data lookups. |
1126 |
|
|
1127 |
Local indices \cite{yang02improvingsearch} is one variation of active caching. |
Local indices \cite{yang02improvingsearch} is one variation of active caching. |
1128 |
In this scheme, each peer maintains an index over the data of all nodes within |
In this scheme, each peer maintains an index over the data of all peers within |
1129 |
$h$ hops of itself, where $h$ is a system-wide variable, called radius of the |
$h$ hops of itself, where $h$ is a system-wide variable, called radius of the |
1130 |
index\footnote{In normal BFS case, the value of $h$ is 0, as peer only has index |
index\footnote{In normal BFS case, the value of $h$ is 0, as peer only has index |
1131 |
over its local content.}. Mutual index caching architecture, as proposed in |
over its local content.}. Mutual index caching architecture, as proposed in |
1152 |
lookup \emph{latency}. CAN \cite{ratnasamy01can}, Kademlia \cite{maymounkov02kademlia}, |
lookup \emph{latency}. CAN \cite{ratnasamy01can}, Kademlia \cite{maymounkov02kademlia}, |
1153 |
Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry} have advanced heuristics for |
Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry} have advanced heuristics for |
1154 |
proximity based routing. Additionally, most recent version of Chord uses proximity based |
proximity based routing. Additionally, most recent version of Chord uses proximity based |
1155 |
routing inspired by Karger and Ruhl \cite{karger02findingnearest}. Skipnet \cite{harvey03skipnet1} |
routing inspired by Karger and Ruhl \cite{karger02findingnearest}. SkipNet \cite{harvey03skipnet1} |
1156 |
uses combination of proximity and application level overlay routing when performing data |
uses combination of proximity and application level overlay routing when performing data |
1157 |
lookups. Authors call this feature \emph{constrained load balancing}. |
lookups. Authors call this feature \emph{constrained load balancing}. |
1158 |
|
|
1219 |
joins and leaves in the system. Some research has been done already in this area. |
joins and leaves in the system. Some research has been done already in this area. |
1220 |
|
|
1221 |
A concept of ''half-life'' was introduced by Liben-Nowell \cite{libennowell01observations}. Half-life is defined |
A concept of ''half-life'' was introduced by Liben-Nowell \cite{libennowell01observations}. Half-life is defined |
1222 |
as follows: let there be $N$ live nodes at time $t$. The doubling from time $t$ is the time that pass before |
as follows: let there be $N$ live peers at time $t$. The doubling from time $t$ is the time that pass before |
1223 |
$N$ new additional nodes arrive into the system. The halving time from time $t$ is the time |
$N$ new additional peers arrive into the system. The halving time from time $t$ is the time |
1224 |
required for half of the living nodes at time $t$ to leave the system. The half-life from |
required for half of the living peers at time $t$ to leave the system. The half-life from |
1225 |
time $t$ is smaller of the properties stated above. The half-life of the entire system is the |
time $t$ is smaller of the properties stated above. The half-life of the entire system is the |
1226 |
minimum half-life over all times $t$. Concept of half-time can be used as a basis for developing |
minimum half-life over all times $t$. Concept of half-time can be used as a basis for developing |
1227 |
more efficient analytical tools for modeling complex Peer-to-Peer systems. |
more efficient analytical tools for modeling complex Peer-to-Peer systems. |
1364 |
|
|
1365 |
\parbox{90pt}{Sybil attack \cite{douceur02sybil}, \cite{castro02securerouting}} & |
\parbox{90pt}{Sybil attack \cite{douceur02sybil}, \cite{castro02securerouting}} & |
1366 |
\parbox{110pt}{Single hostile entity presents multiple entities} & |
\parbox{110pt}{Single hostile entity presents multiple entities} & |
1367 |
\parbox{110pt}{Identify all nodes simultaneously across the system, collect pool of nodes which are validated, distributed node ID creation} & |
\parbox{110pt}{Identify all peers simultaneously across the system, collect pool of peers which are validated, distributed peer ID creation} & |
1368 |
\parbox{110pt}{Not practically realizable, research focused on persistence, not on identity distinction} |
\parbox{110pt}{Not practically realizable, research focused on persistence, not on identity distinction} |
1369 |
\\ \hline |
\\ \hline |
1370 |
|
|
1404 |
\\ \hline |
\\ \hline |
1405 |
|
|
1406 |
|
|
1407 |
\parbox{90pt}{Malicious nodes \cite{sit02securitycons}, \cite{castro02securerouting}} & |
\parbox{90pt}{Malicious peers \cite{sit02securitycons}, \cite{castro02securerouting}} & |
1408 |
\parbox{110pt}{How to identify malicious nodes in the system} & |
\parbox{110pt}{How to identify malicious peers in the system} & |
1409 |
\parbox{110pt}{Create invariants for node behavior, verify invariants, self-certifying data} & |
\parbox{110pt}{Create invariants for peer behavior, verify invariants, self-certifying data} & |
1410 |
\parbox{110pt}{Partial solutions, self-certifying data most reliable} |
\parbox{110pt}{Partial solutions, self-certifying data most reliable} |
1411 |
\\ \hline |
\\ \hline |
1412 |
|
|
1419 |
|
|
1420 |
|
|
1421 |
\parbox{90pt}{Inconsistent behavior \cite{sit02securitycons}} & |
\parbox{90pt}{Inconsistent behavior \cite{sit02securitycons}} & |
1422 |
\parbox{110pt}{Hostile node could act correctly with its neighbors, but incorrectly with others} & |
\parbox{110pt}{Hostile peer could act correctly with its neighbors, but incorrectly with others} & |
1423 |
\parbox{110pt}{Public keys, digital signatures} & |
\parbox{110pt}{Public keys, digital signatures} & |
1424 |
\parbox{110pt}{Not practical approach/working proposal created yet} |
\parbox{110pt}{Not practical approach/working proposal created yet} |
1425 |
\\ \hline |
\\ \hline |
1426 |
|
|
1427 |
|
|
1428 |
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} & |
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} & |
1429 |
\parbox{110pt}{Joining node may join parallel network, formed a group of hostile nodes, hostile node(s) controls the construction of the network} & |
\parbox{110pt}{Joining peer may join parallel network, formed a group of hostile peers, hostile peer(s) controls the construction of the network} & |
1430 |
\parbox{110pt}{Use trusted nodes, based on history information, cryptography, key infrastructure} & |
\parbox{110pt}{Use trusted peers, based on history information, cryptography, key infrastructure} & |
1431 |
\parbox{110pt}{Not 100\% sure if Central Authority (CA) is missing, not practical approach/working proposal created yet} |
\parbox{110pt}{Not 100\% sure if Central Authority (CA) is missing, not practical approach/working proposal created yet} |
1432 |
\\ \hline |
\\ \hline |
1433 |
|
|
1478 |
|
|
1479 |
\parbox{90pt}{Efficient and scalable data discovery \cite{lv02searchreplication}, \cite{osokine02distnetworks}, \cite{yang02improvingsearch}, \cite{lv02gnutellascalable}, \cite{ganesan02yappers}, \cite{adamic02localsearch}, \cite{adamic01powerlawsearch}, \cite{ripeanu02mappinggnutella}, \cite{milgram67smallworld}, \cite{adamic99small}, \cite{ramanathan02goodpeers}, \cite{kleinberg99small}, \cite{nips02-Kleinberg}, \cite{zhang02using}, \cite{watts00dynamics}} & |
\parbox{90pt}{Efficient and scalable data discovery \cite{lv02searchreplication}, \cite{osokine02distnetworks}, \cite{yang02improvingsearch}, \cite{lv02gnutellascalable}, \cite{ganesan02yappers}, \cite{adamic02localsearch}, \cite{adamic01powerlawsearch}, \cite{ripeanu02mappinggnutella}, \cite{milgram67smallworld}, \cite{adamic99small}, \cite{ramanathan02goodpeers}, \cite{kleinberg99small}, \cite{nips02-Kleinberg}, \cite{zhang02using}, \cite{watts00dynamics}} & |
1480 |
\parbox{110pt}{Find resources efficiently, if resource exists (loosely structured)} & |
\parbox{110pt}{Find resources efficiently, if resource exists (loosely structured)} & |
1481 |
\parbox{110pt}{Super nodes, node clusters, caching techniques} & |
\parbox{110pt}{Super peers, peer clusters, caching techniques} & |
1482 |
\parbox{110pt}{More efficient, less network traffic, not comparable to DHT's efficiency} |
\parbox{110pt}{More efficient, less network traffic, not comparable to the efficiency of tightly structured systems} |
1483 |
\\ \hline |
\\ \hline |
1484 |
|
|
1485 |
|
|
1507 |
\parbox{90pt}{Data availability/persistence \cite{bhagwan03availability}} & |
\parbox{90pt}{Data availability/persistence \cite{bhagwan03availability}} & |
1508 |
\parbox{110pt}{Data might be temporarily unavailable, or lost permanently} & |
\parbox{110pt}{Data might be temporarily unavailable, or lost permanently} & |
1509 |
\parbox{110pt}{Data caching, data replication} & |
\parbox{110pt}{Data caching, data replication} & |
1510 |
\parbox{110pt}{Working solutions, but creates more traffic and overhead per node} |
\parbox{110pt}{Working solutions, but creates more traffic and overhead per peer} |
1511 |
\\ \hline |
\\ \hline |
1512 |
|
|
1513 |
|
|
1519 |
|
|
1520 |
|
|
1521 |
\parbox{90pt}{Locality \cite{keleher-02-p2p}, \cite{hildrum02distributedobject}, \cite{freedman02trie}, \cite{sloppy:iptps03}, \cite{plaxton97accessingnearby}, \cite{karger02findingnearest}} & |
\parbox{90pt}{Locality \cite{keleher-02-p2p}, \cite{hildrum02distributedobject}, \cite{freedman02trie}, \cite{sloppy:iptps03}, \cite{plaxton97accessingnearby}, \cite{karger02findingnearest}} & |
1522 |
\parbox{110pt}{Could DHTs exploit locality properties better ?} & |
\parbox{110pt}{Could tightly structured systems exploit locality properties better ?} & |
1523 |
\parbox{110pt}{Constrained Load Balancing, using network properties for nearest neighbor selection, self-organizing clusters} & |
\parbox{110pt}{Constrained Load Balancing, using network properties for nearest neighbor selection, self-organizing clusters} & |
1524 |
\parbox{110pt}{Working solutions} |
\parbox{110pt}{Working solutions} |
1525 |
\\ \hline |
\\ \hline |
1526 |
|
|
1527 |
|
|
1528 |
\parbox{90pt}{Hot spots \cite{258660}, \cite{sloppy:iptps03}, \cite{maymounkov03ratelesscodes}} & |
\parbox{90pt}{Hot spots \cite{258660}, \cite{sloppy:iptps03}, \cite{maymounkov03ratelesscodes}} & |
1529 |
\parbox{110pt}{What will happen if some resource is extremely popular and only one node is hosting it ?} & |
\parbox{110pt}{What will happen if some resource is extremely popular and only one peer is hosting it ?} & |
1530 |
\parbox{110pt}{Caching, multi source downloads, replication, load balancing, sloppy hashing} & |
\parbox{110pt}{Caching, multi source downloads, replication, load balancing, sloppy hashing} & |
1531 |
\parbox{110pt}{For query hot spots, caching and multi source downloads efficiently reduce hot spots, for routing hot spots, benefits are smaller} |
\parbox{110pt}{For query hot spots, caching and multi source downloads efficiently reduce hot spots, for routing hot spots, benefits are smaller} |
1532 |
\\ \hline |
\\ \hline |
1539 |
\\ \hline |
\\ \hline |
1540 |
|
|
1541 |
\parbox{90pt}{System in flux \cite{libennowell01observations}, \cite{571863}, \cite{ledlie02selfp2p}, \cite{albert-02-statistical}} & |
\parbox{90pt}{System in flux \cite{libennowell01observations}, \cite{571863}, \cite{ledlie02selfp2p}, \cite{albert-02-statistical}} & |
1542 |
\parbox{110pt}{Nodes join and leave system constantly. What about load balancing and performance ?} & |
\parbox{110pt}{Peers join and leave system constantly. What about load balancing and performance ?} & |
1543 |
\parbox{110pt}{Half-life phenomenon (for analysis), simple overlay maintenance and construction algorithm} & |
\parbox{110pt}{Half-life phenomenon (for analysis), simple overlay maintenance and construction algorithm} & |
1544 |
\parbox{110pt}{Initial theoretical analysis have been created, but not comprehensive model for analyzing different system states and its variations (e.g. complex usage patterns)} |
\parbox{110pt}{Initial theoretical analysis have been created, but not comprehensive model for analyzing different system states and its variations (e.g. complex usage patterns)} |
1545 |
\\ \hline |
\\ \hline |
1547 |
\parbox{90pt}{Sudden network partition \cite{harvey03skipnet1}, \cite{harvey03skipnet2}, \cite{rowston03controlloingreliability}} & |
\parbox{90pt}{Sudden network partition \cite{harvey03skipnet1}, \cite{harvey03skipnet2}, \cite{rowston03controlloingreliability}} & |
1548 |
\parbox{110pt}{Sub network is isolated from other network because of network disconnection} & |
\parbox{110pt}{Sub network is isolated from other network because of network disconnection} & |
1549 |
\parbox{110pt}{Self-tuning, environment observation, localized network connection for minimum latency (backup connections)} & |
\parbox{110pt}{Self-tuning, environment observation, localized network connection for minimum latency (backup connections)} & |
1550 |
\parbox{110pt}{Creates more overhead/space requirements per node} |
\parbox{110pt}{Creates more overhead/space requirements per peer} |
1551 |
\\ \hline |
\\ \hline |
1552 |
|
|
1553 |
\parbox{90pt}{Fail Stop} & |
\parbox{90pt}{Fail Stop} & |
1554 |
\parbox{110pt}{A faulty node stops working} & |
\parbox{110pt}{A faulty peer stops working} & |
1555 |
\parbox{110pt}{Failure detectors, informing algorithms} & |
\parbox{110pt}{Failure detectors, informing algorithms} & |
1556 |
\parbox{110pt}{Creates more network traffic, peer's information can be outdated, failure detectors not reliable} |
\parbox{110pt}{Creates more network traffic, peer's information can be outdated, failure detectors not reliable} |
1557 |
\\ \hline |
\\ \hline |
1558 |
|
|
1559 |
|
|
1560 |
\parbox{90pt}{Byzantine faults \cite{296824}} & |
\parbox{90pt}{Byzantine faults \cite{296824}} & |
1561 |
\parbox{110pt}{Faulty nodes may behave arbitrarily} & |
\parbox{110pt}{Faulty peers may behave arbitrarily} & |
1562 |
\parbox{110pt}{Byzantine replication algorithms, get information from multiple entities, trust majority's opinion} & |
\parbox{110pt}{Byzantine replication algorithms, get information from multiple entities, trust majority's opinion} & |
1563 |
\parbox{110pt}{Much research has been done on this field, practical solutions, decreases system performance slightly} |
\parbox{110pt}{Much research has been done on this field, practical solutions, decreases system performance slightly} |
1564 |
\\ \hline |
\\ \hline |
1610 |
|
|
1611 |
|
|
1612 |
\parbox{90pt}{Heterogeneity \cite{saroiu02measurementstudyp2p}, \cite{brinkmann02compactplacement}, \cite{zhao02brocade},\cite{gurmeet03symphony}} & |
\parbox{90pt}{Heterogeneity \cite{saroiu02measurementstudyp2p}, \cite{brinkmann02compactplacement}, \cite{zhao02brocade},\cite{gurmeet03symphony}} & |
1613 |
\parbox{110pt}{There are different kind of nodes in the system, in light of bandwidth and computing power} & |
\parbox{110pt}{There are different kind of peers in the system, in light of bandwidth and computing power} & |
1614 |
\parbox{110pt}{Super peers (broadcasting), cluster (broadcasting) additional layer upon DHTs, structural simplicity (DHTs)} & |
\parbox{110pt}{Super peers (loosely structured), clusters (loosely structured) additional layer upon tighty structured systems, structure itself is simple (tighty structured)} & |
1615 |
\parbox{110pt}{Working solutions, increases system complexity (additional layer)} |
\parbox{110pt}{Working solutions, increases system complexity (additional layer)} |
1616 |
\\ \hline |
\\ \hline |
1617 |
|
|
1619 |
\parbox{90pt}{Programming guidelines \cite{zhao03api}, \cite{frise02p2pframework}, \cite{babaoglu02anthill}, \cite{rhea03benchmarks}, \cite{garciamolina03sil}, \cite{balakrishnan03semanticfree}} & |
\parbox{90pt}{Programming guidelines \cite{zhao03api}, \cite{frise02p2pframework}, \cite{babaoglu02anthill}, \cite{rhea03benchmarks}, \cite{garciamolina03sil}, \cite{balakrishnan03semanticfree}} & |
1620 |
\parbox{110pt}{Set of programming guidelines/frameworks is needed for better interoperability between different systems} & |
\parbox{110pt}{Set of programming guidelines/frameworks is needed for better interoperability between different systems} & |
1621 |
\parbox{110pt}{Common frameworks and APIs} & |
\parbox{110pt}{Common frameworks and APIs} & |
1622 |
\parbox{110pt}{Common framework/API is still missing, a few proposals have been made (DHTs)} |
\parbox{110pt}{Common framework/API is still missing, a few proposals have been made (tightly structured)} |
1623 |
\\ \hline |
\\ \hline |
1624 |
|
|
1625 |
|
|
1632 |
|
|
1633 |
\parbox{90pt}{Overlay management and health monitoring \cite{zhang03somo}} & |
\parbox{90pt}{Overlay management and health monitoring \cite{zhang03somo}} & |
1634 |
\parbox{110pt}{System is self-capable to monitor it's status and health for better performance} & |
\parbox{110pt}{System is self-capable to monitor it's status and health for better performance} & |
1635 |
\parbox{110pt}{Build a meta data overlay atop of structured overlay (such as SOMO for structured overlays), make local decisions about overlay (unstructured)} & |
\parbox{110pt}{Build a meta data overlay atop of structured overlay (such as SOMO for structured overlays), make local decisions about overlay (loosely structured)} & |
1636 |
\parbox{110pt}{For tightly structured overlays, efficient and simple to implement, fault tolerance unknown, for loosely structured not necessarily efficient because decisions are based on local knowledge} |
\parbox{110pt}{For tightly structured overlays, efficient and simple to implement, fault tolerance unknown, for loosely structured not necessarily efficient because decisions are based on local knowledge} |
1637 |
\\ \hline |
\\ \hline |
1638 |
|
|
1901 |
On top of Kademlia, we propose the usage of Sloppy hashing \cite{sloppy:iptps03} which |
On top of Kademlia, we propose the usage of Sloppy hashing \cite{sloppy:iptps03} which |
1902 |
is optimized for DOLR abstraction of tightly structured overlays. With Sloppy hashing, |
is optimized for DOLR abstraction of tightly structured overlays. With Sloppy hashing, |
1903 |
we are able to reduce the generation of query hot spots. Sloppy hashing enables to |
we are able to reduce the generation of query hot spots. Sloppy hashing enables to |
1904 |
locate nearby data without looking up data from distant nodes. Moreover, authors' |
locate nearby data without looking up data from distant peers. Moreover, authors' |
1905 |
proposal for self-organizing clusters using network diameters may be useful, |
proposal for self-organizing clusters using network diameters may be useful, |
1906 |
especially within small groups of working people. Thus, with Sloppy hashing |
especially within small groups of working people. Thus, with Sloppy hashing |
1907 |
we can provide locality properties for Fenfire. |
we can provide locality properties for Fenfire. |
1948 |
\begin{enumerate} |
\begin{enumerate} |
1949 |
\item Submit data lookup using scroll block's identifier. |
\item Submit data lookup using scroll block's identifier. |
1950 |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given scroll block identifier. |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given scroll block identifier. |
1951 |
\item Pointer peer returns most recent pointer block's value (e.g., hosting peer's IP-address) to query originator. |
\item Pointer peer returns most recent pointer block's value (e.g., hosting peer's IP address) to query originator. |
1952 |
\item Query originator requests hosting peer to return the scroll block. |
\item Query originator requests hosting peer to return the scroll block. |
1953 |
\end{enumerate} |
\end{enumerate} |
1954 |
\end{itemize} |
\end{itemize} |
1963 |
\begin{enumerate} |
\begin{enumerate} |
1964 |
\item Query originator locally computes a hash for given pointer random string. |
\item Query originator locally computes a hash for given pointer random string. |
1965 |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given hash of pointer random string. |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given hash of pointer random string. |
1966 |
\item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP-address) to query originator, using pointer block's own indexing schemes. |
\item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP address) to query originator, using pointer block's own indexing schemes. |
1967 |
\item Query originator requests hosting peer to return the scroll block. |
\item Query originator requests hosting peer to return the scroll block. |
1968 |
\end{enumerate} |
\end{enumerate} |
1969 |
\end{itemize} |
\end{itemize} |
1974 |
|
|
1975 |
\item Query originator locally computes a hash for given pointer random string. |
\item Query originator locally computes a hash for given pointer random string. |
1976 |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given hash of pointer random string. |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given hash of pointer random string. |
1977 |
\item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP-addresses) to query originator, using pointer block's own indexing schemes. |
\item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP addresses) to query originator, using pointer block's own indexing schemes. |
1978 |
\item Query originator requests hosting peer to return the scroll block. |
\item Query originator requests hosting peer to return the scroll block. |
1979 |
\end{enumerate} |
\end{enumerate} |
1980 |
\end{itemize} |
\end{itemize} |