296 |
approach the overlay is constructed deterministically, which all participating peers have to follow; the topology of the |
approach the overlay is constructed deterministically, which all participating peers have to follow; the topology of the |
297 |
overlay and the placement of services is controlled tightly. |
overlay and the placement of services is controlled tightly. |
298 |
|
|
299 |
\subsection{Definition} |
\subsection{Sketch of definition} |
300 |
|
|
301 |
In this subsection, we try to introduce a \emph{sketch} of formal definition of the tightly structured overlay, such as |
In this subsection, we try to introduce a \emph{sketch} of formal definition of the tightly structured overlay, such as |
302 |
identifiers, identifier space and the mapping function. |
identifiers, identifier space and the mapping function. |
369 |
\ref{fig:kademlia_lookup} shows the process of Kademlia's |
\ref{fig:kademlia_lookup} shows the process of Kademlia's |
370 |
data lookup. Viceroy \cite{malkhi02viceroy} maintains a butterfly data structure (e.g., \cite{226658}), |
data lookup. Viceroy \cite{malkhi02viceroy} maintains a butterfly data structure (e.g., \cite{226658}), |
371 |
which requires only a constant number of neighbor peers while providing $O(\log{n})$ data lookup |
which requires only a constant number of neighbor peers while providing $O(\log{n})$ data lookup |
372 |
efficiency. Koorde \cite{kaashoek03koorde}, a recent modification of Chord, uses de Bruijn graphs |
efficiency, where $n$ is the number of peers in the system. Koorde \cite{kaashoek03koorde}, a recent modification of Chord, uses de Bruijn graphs |
373 |
\cite{debruijn46graph} to maintain local routing tables. It requires |
\cite{debruijn46graph} to maintain local routing tables. It requires |
374 |
each peer to have only about two links to other peers to provide $O(\log{n})$ performance. |
each peer to have only about two links to other peers to provide $O(\log{n})$ performance. |
375 |
|
|
471 |
which has initially published services into the overlay. |
which has initially published services into the overlay. |
472 |
|
|
473 |
PeerNet \cite{eriksson03peernet} differs from other tightly structured overlays in that it operates |
PeerNet \cite{eriksson03peernet} differs from other tightly structured overlays in that it operates |
474 |
at the \emph{network} layer instead of application layer. This property would provide a common interface |
at the \emph{network} layer instead of application layer (see the ISO-OSI reference model, e.g., \cite{800902}). |
475 |
|
This property would provide a common interface |
476 |
to all Peer-to-Peer systems using PeerNet. PeerNet makes an explicit distinction |
to all Peer-to-Peer systems using PeerNet. PeerNet makes an explicit distinction |
477 |
between peer identity and address, which is not supported by standard |
between peer identity and address, which is not supported by standard |
478 |
TCP/IP-protocols. PeerNet has the same performance properties as other tightly structured |
TCP/IP-protocols. PeerNet has the same performance properties as other tightly structured |
543 |
\endfirsthead |
\endfirsthead |
544 |
|
|
545 |
\multicolumn{3}{c}% |
\multicolumn{3}{c}% |
546 |
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
{{\tablename\ \thetable{} -- continued from the previous page}} \\ |
547 |
\hline |
\hline |
548 |
\multicolumn{1}{|c|}{\textbf{Property}} & |
\multicolumn{1}{|c|}{\textbf{Property}} & |
549 |
\multicolumn{1}{c|}{\textbf{Loosely structured}} & |
\multicolumn{1}{c|}{\textbf{Loosely structured}} & |
610 |
Table \ref{table_Peer-to-Peer_algorithms} lists proposed Peer-to-Peer algorithms |
Table \ref{table_Peer-to-Peer_algorithms} lists proposed Peer-to-Peer algorithms |
611 |
and their key properties with regard to performance and scalability. The list |
and their key properties with regard to performance and scalability. The list |
612 |
includes algorithms from both loosely and tightly structured approaches. The list doesn't |
includes algorithms from both loosely and tightly structured approaches. The list doesn't |
613 |
include \emph{all} proposed Peer-to-Peer algorithms. Only the ones which already have |
include \emph{all} proposed Peer-to-Peer algorithms; only the ones which already have |
614 |
been widely deployed, or the ones which may be promising in the future |
been widely deployed, or the ones which may be promising in the future |
615 |
Peer-to-Peer systems are included in this thesis. |
Peer-to-Peer systems are included. |
616 |
|
|
617 |
We decided to follow the guidelines from \cite{kaashoek03koorde} in measuring |
We decided to follow the guidelines from \cite{kaashoek03koorde} in measuring |
618 |
the properties of different Peer-to-Peer systems. However, we dropped |
the properties of different Peer-to-Peer systems. However, we dropped |
642 |
\endfirsthead |
\endfirsthead |
643 |
|
|
644 |
\multicolumn{6}{c}% |
\multicolumn{6}{c}% |
645 |
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
{{\tablename\ \thetable{} -- continued from the previous page}} \\ |
646 |
\hline |
\hline |
647 |
\multicolumn{1}{|c|}{\textbf{Algorithm}} & |
\multicolumn{1}{|c|}{\textbf{Algorithm}} & |
648 |
\multicolumn{1}{c|}{\textbf{Insert/Delete}} & |
\multicolumn{1}{c|}{\textbf{Insert/Delete}} & |
660 |
\parbox{37pt}{$O$($d$)} & |
\parbox{37pt}{$O$($d$)} & |
661 |
\parbox{37pt}{$O(dn^{\frac{1}{d}})$} & |
\parbox{37pt}{$O(dn^{\frac{1}{d}})$} & |
662 |
\parbox{85pt}{2$d$} & |
\parbox{85pt}{2$d$} & |
663 |
\parbox{85pt}{System performance may decrease if peers are not homogeneous and peers join and leave the system constantly. $d$ is the dimension of virtual key space} |
\parbox{85pt}{System performance may decrease if peers are not homogeneous and peers join and leave the system constantly. $d$ is the dimension of virtual key space.} |
664 |
\\ \hline |
\\ \hline |
665 |
|
|
666 |
\parbox{37pt}{Chord \cite{stoica01chord}} & |
\parbox{37pt}{Chord \cite{stoica01chord}} & |
667 |
\parbox{37pt}{$O(\log^2{n})$} & |
\parbox{37pt}{$O(\log^2{n})$} & |
668 |
\parbox{37pt}{$O(\log{n}$} & |
\parbox{37pt}{$O(\log{n})$} & |
669 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
670 |
\parbox{85pt}{2$(\log{n})$} & |
\parbox{85pt}{2$(\log{n})$} & |
671 |
\parbox{85pt}{System performance may decrease if peers are not homogeneous and peers join and leave the system constantly} |
\parbox{85pt}{System performance may decrease if peers are not homogeneous and peers join and leave the system constantly.} |
672 |
\\ \hline |
\\ \hline |
673 |
|
|
674 |
|
|
676 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
677 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
678 |
\parbox{37pt}{$O(n)$} & |
\parbox{37pt}{$O(n)$} & |
679 |
\parbox{85pt}{Typical configuration e.g., {4--150}} & |
\parbox{85pt}{Typical configuration e.g., {4--150}.} & |
680 |
\parbox{85pt}{Average lookup performance is $O(\log{n})$ with tens of thousands concurrent users, beyond that, the performance is $O(n)$} |
\parbox{85pt}{Average lookup performance is $O(\log{n})$ with tens of thousands concurrent users; beyond that, the performance is $O(n)$.} |
681 |
\\ \hline |
\\ \hline |
682 |
|
|
683 |
|
|
685 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
686 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
687 |
\parbox{37pt}{$O(n)$} & |
\parbox{37pt}{$O(n)$} & |
688 |
\parbox{85pt}{Typical configuration is 5 connections (2*5=10 total), however, this depends on implementation} & |
\parbox{85pt}{Typical configuration is 5 connections (2*5=10 total), however, this depends on implementation.} & |
689 |
\parbox{85pt}{Number of messages can grow as fast as $O(n^{2})$} |
\parbox{85pt}{Number of messages can grow as fast as $O(n^{2})$.} |
690 |
\\ \hline |
\\ \hline |
691 |
|
|
692 |
|
|
695 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
696 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
697 |
\parbox{85pt}{$2(\log{n})$} & |
\parbox{85pt}{$2(\log{n})$} & |
698 |
\parbox{85pt}{There is no action required when peers leave the system} |
\parbox{85pt}{There is no action required when peers leave the system.} |
699 |
\\ \hline |
\\ \hline |
700 |
|
|
701 |
|
|
703 |
\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})))$} & |
704 |
\parbox{37pt}{$O$($\sqrt{n}$)} & |
\parbox{37pt}{$O$($\sqrt{n}$)} & |
705 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
706 |
\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} & |
\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.} & |
707 |
\parbox{85pt}{Insert/delete overhead is constant and performed in the background, system performance may decrease if peers are not homogeneous and peers join and leave the system constantly} |
\parbox{85pt}{Insert/delete overhead is constant and performed in the background. System performance may decrease if peers are not homogeneous and peers join and leave the system constantly.} |
708 |
\\ \hline |
\\ \hline |
709 |
|
|
710 |
\parbox{37pt}{Koorde \cite{kaashoek03koorde}} & |
\parbox{37pt}{Koorde \cite{kaashoek03koorde}} & |
712 |
\parbox{37pt}{$O(1)$ or $O(\log{n})$} & |
\parbox{37pt}{$O(1)$ or $O(\log{n})$} & |
713 |
\parbox{37pt}{$O(\log{n})$ or $O(\frac{\log{n}}{\log{}\log{n}})$} & |
\parbox{37pt}{$O(\log{n})$ or $O(\frac{\log{n}}{\log{}\log{n}})$} & |
714 |
\parbox{85pt}{$2(\log{n})$} & |
\parbox{85pt}{$2(\log{n})$} & |
715 |
\parbox{85pt}{Based on Chord algorithm, uses de Bruijn graphs for better efficiency and fault tolerance} |
\parbox{85pt}{Based on Chord algorithm, uses de Bruijn graphs for better efficiency and fault tolerance.} |
716 |
\\ \hline |
\\ \hline |
717 |
|
|
718 |
\parbox{37pt}{ODHDHT \cite{naor03simpledht}} & |
\parbox{37pt}{ODHDHT \cite{naor03simpledht}} & |
728 |
\parbox{37pt}{$O(\log^2{n})$} & |
\parbox{37pt}{$O(\log^2{n})$} & |
729 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
730 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
731 |
\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).} & |
732 |
\parbox{85pt}{System performance may decrease if peers are not homogeneous and peers join and leave the system constantly, based on Plaxton's algorithm} |
\parbox{85pt}{System performance may decrease if peers are not homogeneous and peers join and leave the system constantly; based on Plaxton's algorithm.} |
733 |
\\ \hline |
\\ \hline |
734 |
|
|
735 |
|
|
738 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
739 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
740 |
\parbox{85pt}{$O(\log{n})$} & |
\parbox{85pt}{$O(\log{n})$} & |
741 |
\parbox{85pt}{Operates at network layer} |
\parbox{85pt}{Operates at network level layer.} |
742 |
\\ \hline |
\\ \hline |
743 |
|
|
744 |
\parbox{37pt}{Plaxton \cite{plaxton97accessingnearby}} & |
\parbox{37pt}{Plaxton \cite{plaxton97accessingnearby}} & |
746 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
747 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
748 |
\parbox{85pt}{$O(\log{n})$} & |
\parbox{85pt}{$O(\log{n})$} & |
749 |
\parbox{85pt}{Plaxton's algorithm is designed to operate in static environment (e.g., web cache)} |
\parbox{85pt}{Plaxton's algorithm is designed to operate in static environment (e.g., web cache).} |
750 |
\\ \hline |
\\ \hline |
751 |
|
|
752 |
\parbox{37pt}{Skip Graphs \cite{AspnesS2003}} & |
\parbox{37pt}{Skip Graphs \cite{AspnesS2003}} & |
753 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
754 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
755 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
756 |
\parbox{85pt}{$4r(\log{n}) + (\log{n})$, where r=number of resources provided)} & |
\parbox{85pt}{$4r(\log{n}) + O(\log{n})$, where r=number of resources provided.} & |
757 |
\parbox{85pt}{In this approach peer is treated as ''named resource''} |
\parbox{85pt}{In this approach peer is treated as ''named resource''.} |
758 |
\\ \hline |
\\ \hline |
759 |
|
|
760 |
\parbox{37pt}{SkipNet \cite{harvey03skipnet2}} & |
\parbox{37pt}{SkipNet \cite{harvey03skipnet2}} & |
762 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
763 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
764 |
\parbox{85pt}{$2(\log{n})$} & |
\parbox{85pt}{$2(\log{n})$} & |
765 |
\parbox{85pt}{Partially supports underlying network's locality properties} |
\parbox{85pt}{Partially supports underlying network's locality properties.} |
766 |
\\ \hline |
\\ \hline |
767 |
|
|
768 |
\parbox{37pt}{Social \cite{alpineurl}} & |
\parbox{37pt}{Social \cite{alpineurl}} & |
769 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
770 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
771 |
\parbox{37pt}{$O(n)$} & |
\parbox{37pt}{$O(n)$} & |
772 |
\parbox{85pt}{Can be 1-10000 connections (as known as ''social'' connections, connections are permanent)} & |
\parbox{85pt}{Can be 1-10000 connections (as known as ''social'' connections, connections are permanent).} & |
773 |
\parbox{85pt}{Number of connections number depends on peer's memory/network capabilities} |
\parbox{85pt}{Number of connections depends on peer's memory/network capabilities.} |
774 |
\\ \hline |
\\ \hline |
775 |
|
|
776 |
\parbox{37pt}{Symphony \cite{gurmeet03symphony}} & |
\parbox{37pt}{Symphony \cite{gurmeet03symphony}} & |
777 |
\parbox{37pt}{$O(\log^2{n})$} & |
\parbox{37pt}{$O(\log^2{n})$} & |
778 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
779 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
780 |
\parbox{85pt}{$2k+2+f$, where k = long range connections, 2 = peer's neighbors, f = fault tolerance connections)} & |
\parbox{85pt}{$2k+2+f$, where k = long range connections, 2 = peer's neighbors, f = fault tolerance connections).} & |
781 |
\parbox{85pt}{Space can also be $O(1)$. Additional space of can be used as a lookahead list for better performance} |
\parbox{85pt}{Space can also be $O(1)$. Additional space of can be used as a lookahead list for better performance.} |
782 |
\\ \hline |
\\ \hline |
783 |
|
|
784 |
\parbox{37pt}{SWAN \cite{bonsma02swan}} & |
\parbox{37pt}{SWAN \cite{bonsma02swan}} & |
785 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
786 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
787 |
\parbox{37pt}{$O(\log^2{n})$} & |
\parbox{37pt}{$O(\log^2{n})$} & |
788 |
\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.} & |
789 |
\parbox{85pt}{In this approach, peer is treated as ''named resource''} |
\parbox{85pt}{In this approach, peer is treated as ''named resource''.} |
790 |
\\ \hline |
\\ \hline |
791 |
|
|
792 |
|
|
794 |
\parbox{37pt}{$O(\log^2{n})$} & |
\parbox{37pt}{$O(\log^2{n})$} & |
795 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
796 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
797 |
\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).} & |
798 |
\parbox{85pt}{System performance may decrease if peers are not homogeneous and peers join and leave the system constantly, based on Plaxton's algorithm} |
\parbox{85pt}{System performance may decrease if peers are not homogeneous and peers join and leave the system constantly, based on Plaxton's algorithm.} |
799 |
\\ \hline |
\\ \hline |
800 |
|
|
801 |
\parbox{37pt}{Viceroy \cite{malkhi02viceroy}} & |
\parbox{37pt}{Viceroy \cite{malkhi02viceroy}} & |
803 |
\parbox{37pt}{$O(1)$} & |
\parbox{37pt}{$O(1)$} & |
804 |
\parbox{37pt}{$O(\log{n})$} & |
\parbox{37pt}{$O(\log{n})$} & |
805 |
\parbox{85pt}{11} & |
\parbox{85pt}{11} & |
806 |
\parbox{85pt}{System performance may decrease if peers are not homogeneous and peers join and leave the system constantly, not necessarily fault-tolerant because of constant degree of neighbors} |
\parbox{85pt}{System performance may decrease if peers are not homogeneous and peers join and leave the system constantly, not necessarily fault-tolerant because of constant degree of neighbors.} |
807 |
\\ \hline |
\\ \hline |
808 |
|
|
809 |
|
|
830 |
open problems to be solved. Also, many techniques developed for traditional distributed |
open problems to be solved. Also, many techniques developed for traditional distributed |
831 |
systems may no longer apply with Peer-to-Peer systems, e.g., load balancing techiques \cite{byers03dhtbalancing}. |
systems may no longer apply with Peer-to-Peer systems, e.g., load balancing techiques \cite{byers03dhtbalancing}. |
832 |
|
|
833 |
Different problems apply to both the loosely structured and the tightly structured approach have their own specific problems. |
Different problems apply to both the loosely structured and the tightly structured approach. |
834 |
Since the introduction of Gnutella \cite{gnutellaurl}, the main concern has been the scalability problem of loosely structured |
For instance, since the introduction of Gnutella \cite{gnutellaurl}, the main concern has been the scalability problem of loosely structured |
835 |
systems. However, the scalability problem of the loosely structured is often misunderstood; |
systems. However, the scalability problem of the loosely structured is often misunderstood; |
836 |
\emph{the network overlay} of loosely structured systems is scalable, but the \emph{data lookup model} is not as |
\emph{the network overlay} of loosely structured systems is scalable, but the \emph{data lookup model} is not as |
837 |
the data lookup process creates lot of extra network traffic (e.g., \cite{yang02improvingsearch}). |
the data lookup process creates lot of extra network traffic (e.g., \cite{yang02improvingsearch}). |
882 |
Naor et al. \cite{naor03simpledht} have proposed a partial solution against Spam attack in a \emph{faulty} peer environment (not hostile). |
Naor et al. \cite{naor03simpledht} have proposed a partial solution against Spam attack in a \emph{faulty} peer environment (not hostile). |
883 |
|
|
884 |
Overloading of targeted peers is a form of Distributed Denial of Service attack (DDoS) (see, e.g., \cite{372148}). For instance, |
Overloading of targeted peers is a form of Distributed Denial of Service attack (DDoS) (see, e.g., \cite{372148}). For instance, |
885 |
a hostile entity can attempt to burden targeted peers with garbage network packets. As a consequence, peers may act incorrectly or |
a hostile entity can attempt to burden specific peers with garbage network packets. As a consequence, peers may act incorrectly or |
886 |
stop working. Daswani et al. \cite{daswani02queryflooddos} suggest efficient load balancing |
stop working. Daswani et al. \cite{daswani02queryflooddos} suggest efficient load balancing |
887 |
policies for Peer-to-Peer system in order to prevent massive system failures. They suggest a traffic model |
policies for Peer-to-Peer system in order to prevent massive system failures. They suggest a traffic model |
888 |
that can be used to understand the effects of DDoS attacks. Sit et al. \cite{sit02securitycons} |
that can be used to understand the effects of DDoS attacks. Sit et al. \cite{sit02securitycons} |
889 |
suggest that identifier assignment algorithm for peers would assign identifier with respect to network topology |
suggest that identifier assignment algorithm for peers would assign identifier with respect to network topology |
890 |
and that replicas should be located physically to different locations. |
and that replicas of data should be located physically to different locations. |
891 |
|
|
892 |
|
|
893 |
\subsection{Trust management, data authenticity and integrity} |
\subsection{Trust management, data authenticity and integrity} |
894 |
|
|
895 |
According to \cite{aberer01trust}, mutual trust ''...allows agents to cooperate in a game-theoretic situation that corresponds |
According to \cite{aberer01trust}, mutual trust ''...allows agents to cooperate in a game-theoretic situation that corresponds |
896 |
to the repeated prisoners dilemma and leads in the long term to an increased aggregated utility for the participating agents''. |
to the repeated prisoners dilemma and leads in the long term to an increased aggregated utility for the participating agents''. |
897 |
The authors of \cite{aberer01trust} define \emph{trust management} as a mechanism that allows to establish mutual trust. Furthermore, \emph{reputation} is a measure |
The authors of \cite{aberer01trust} define \emph{trust management} as a mechanism that allows one to establish mutual trust. Furthermore, \emph{reputation} is a measure |
898 |
that is derived from knowledge on interactions in the past \cite{aberer01trust}. In this subsection, we discuss mechanisms to maintain |
that is derived from knowledge on interactions in the past \cite{aberer01trust}. In this subsection, we discuss mechanisms to maintain |
899 |
trust in Peer-to-Peer systems. |
trust in Peer-to-Peer systems. |
900 |
|
|
901 |
Trust in Peer-to-Peer systems is based on \emph{reputation}. Little research has been done on reputation models in Peer-to-Peer |
Trust in Peer-to-Peer systems is based on \emph{reputation}. Little research has been done on the reputation models in Peer-to-Peer |
902 |
systems, such as \cite{aberer01trust}, \cite{cornelli02reputableservents}. In \cite{aberer01trust}, authors present a scalable |
systems, such as \cite{aberer01trust}, \cite{cornelli02reputableservents}. In \cite{aberer01trust}, authors present a scalable |
903 |
trust management model, which can be used in Peer-to-Peer enviroment. Authors in \cite{cornelli02reputableservents} |
trust management model, which can be used in Peer-to-Peer enviroment. Authors in \cite{cornelli02reputableservents} |
904 |
suggest techniques to keep track and share information about the reputation of a peer with others peers. |
suggest techniques to keep track and share information about the reputation of a peer with others peers. |
906 |
Quite recently, widely used Public Key Infrastructure (PKI) has been deployed in distributed |
Quite recently, widely used Public Key Infrastructure (PKI) has been deployed in distributed |
907 |
systems \cite{rivest96sdsi}, \cite{spkiworkinggroup}. PKI is a reliable technology for securing |
systems \cite{rivest96sdsi}, \cite{spkiworkinggroup}. PKI is a reliable technology for securing |
908 |
data in computing systems, such as the Internet. However, in Peer-to-Peer |
data in computing systems, such as the Internet. However, in Peer-to-Peer |
909 |
networks, the problem of key-based security mechanism may be the maintenance of keys as participating |
networks, the problem of key-based security mechanism may be the revocation of keys and the |
|
peers constantly join and leave the system, i.e., the revocation of keys and the |
|
910 |
distribution of new keys in a hostile environment \cite{KohMau99}. |
distribution of new keys in a hostile environment \cite{KohMau99}. |
911 |
|
|
912 |
ConChord \cite{ajmani02conchord} is the first Peer-to-Peer system which has a support for PKI based |
ConChord \cite{ajmani02conchord} is the first Peer-to-Peer system which has a support for PKI based |
948 |
|
|
949 |
Even if many existing Peer-to-Peer systems are able to provide some of the types of anonymity, there is no |
Even if many existing Peer-to-Peer systems are able to provide some of the types of anonymity, there is no |
950 |
such system which is able to provide complete anonymity in all levels (see above). Specifically, the conflicts |
such system which is able to provide complete anonymity in all levels (see above). Specifically, the conflicts |
951 |
between anonymity and other properties of Peer-to-Peer system require more research work. |
between anonymity and other properties of Peer-to-Peer systems require more research work. |
952 |
|
|
953 |
|
|
954 |
\subsection{Access control} |
\subsection{Access control} |
1006 |
$h$ is the number of hops in the overlay. Sit and Morris \cite{sit02securitycons} discuss the possibility of |
$h$ is the number of hops in the overlay. Sit and Morris \cite{sit02securitycons} discuss the possibility of |
1007 |
allowing the query originator to observe lookup progress and cross-check routing tables using random queries to achieve |
allowing the query originator to observe lookup progress and cross-check routing tables using random queries to achieve |
1008 |
secure routing in tightly structured overlay. However, their |
secure routing in tightly structured overlay. However, their |
1009 |
approach is not very efficient, since this method creates lot of additional network traffic when |
approach is not very efficient, since this method creates a lot of additional network traffic when |
1010 |
in function i.e., it is unknown if this technique is realizable in an efficient way. |
in function i.e., it is unknown if this technique is realizable in an efficient way. |
1011 |
Lynch et al. \cite{lynch02atomicdataaccess} propose a solution for secure routing table |
Lynch et al. \cite{lynch02atomicdataaccess} propose a solution for secure routing table |
1012 |
maintenance, but their solution seems to have two major problems according to \cite{castro02securitystructured}. |
maintenance, but their solution seems to have two major problems according to \cite{castro02securitystructured}. |
1047 |
\endfirsthead |
\endfirsthead |
1048 |
|
|
1049 |
\multicolumn{4}{c}% |
\multicolumn{4}{c}% |
1050 |
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
{{\tablename\ \thetable{} -- continued from the previous page}} \\ |
1051 |
\hline \multicolumn{1}{|c|}{\textbf{Problem}} & |
\hline \multicolumn{1}{|c|}{\textbf{Problem}} & |
1052 |
\multicolumn{1}{c|}{\textbf{Problem description}} & |
\multicolumn{1}{c|}{\textbf{Problem description}} & |
1053 |
\multicolumn{1}{c|}{\textbf{Solutions}} & |
\multicolumn{1}{c|}{\textbf{Solutions}} & |
1061 |
|
|
1062 |
\parbox{90pt}{Query routing \cite{sit02securitycons, aspnes02faultrouting, castro02securerouting, ratnasamy02routing, gavoille01routing, |
\parbox{90pt}{Query routing \cite{sit02securitycons, aspnes02faultrouting, castro02securerouting, ratnasamy02routing, gavoille01routing, |
1063 |
lynch02atomicdataaccess, fiat02censorship, saia02dynamicfaultcontentnetwork, datar02butterflies}} & |
lynch02atomicdataaccess, fiat02censorship, saia02dynamicfaultcontentnetwork, datar02butterflies}} & |
1064 |
\parbox{110pt}{Incorrect forwarding (hostile), incorrect routing (hostile)} & |
\parbox{110pt}{Incorrect forwarding (hostile), incorrect routing (hostile).} & |
1065 |
\parbox{110pt}{Query monitoring, cross check routing tables, verify routing tables, create routing table invariants} & |
\parbox{110pt}{Query monitoring, cross check routing tables, verify routing tables, create routing table invariants.} & |
1066 |
\parbox{110pt}{Increases system complexity} |
\parbox{110pt}{Increases system complexity.} |
1067 |
\\ \hline |
\\ \hline |
1068 |
|
|
1069 |
|
|
1070 |
\parbox{90pt}{DoS attack \cite{sit02securitycons, saia02dynamicfaultcontentnetwork, datar02butterflies, daswani02queryflooddos, juels99clientpuzzles}} & |
\parbox{90pt}{DoS attack \cite{sit02securitycons, saia02dynamicfaultcontentnetwork, datar02butterflies, daswani02queryflooddos, juels99clientpuzzles}} & |
1071 |
\parbox{110pt}{Distributed, controlled burden against specific computer(s)} & |
\parbox{110pt}{Distributed, controlled burden against specific computer(s).} & |
1072 |
\parbox{110pt}{Client puzzles, load balancing, traffic measurements, traffic models, replication} & |
\parbox{110pt}{Client puzzles, load balancing, traffic measurements, traffic models, replication.} & |
1073 |
\parbox{110pt}{Only partial solutions, traffic models most effective} |
\parbox{110pt}{Only partial solutions, traffic models most effective.} |
1074 |
\\ \hline |
\\ \hline |
1075 |
|
|
1076 |
|
|
1077 |
\parbox{90pt}{Sybil attack \cite{douceur02sybil, castro02securerouting}} & |
\parbox{90pt}{Sybil attack \cite{douceur02sybil, castro02securerouting}} & |
1078 |
\parbox{110pt}{Single hostile entity presents multiple entities} & |
\parbox{110pt}{Single hostile entity presents multiple entities.} & |
1079 |
\parbox{110pt}{Identify all peers simultaneously across the system, collect pool of peers which are validated, distributed peer ID creation} & |
\parbox{110pt}{Identify all peers simultaneously across the system, collect pool of peers which are validated, distributed peer ID creation.} & |
1080 |
\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.} |
1081 |
\\ \hline |
\\ \hline |
1082 |
|
|
1083 |
|
|
1084 |
\parbox{90pt}{Spam attack \cite{naor03simpledht}} & |
\parbox{90pt}{Spam attack \cite{naor03simpledht}} & |
1085 |
\parbox{110pt}{Hostile entity creates false versions of data, or gives wrong information about the data which entity is responsible for/knows about} & |
\parbox{110pt}{Hostile entity creates false versions of data, or gives wrong information about the data which entity is responsible for/knows about.} & |
1086 |
\parbox{110pt}{Do not trust to single entity, get information from multiple entities, trust on majority's opinion} & |
\parbox{110pt}{Do not trust to single entity, get information from multiple entities, trust on majority's opinion.} & |
1087 |
\parbox{110pt}{Easy to implement, creates more network traffic} |
\parbox{110pt}{Easy to implement, creates more network traffic.} |
1088 |
\\ \hline |
\\ \hline |
1089 |
|
|
1090 |
|
|
1091 |
\parbox{90pt}{Entity identification \cite{ajmani02conchord}, \cite{douceur02sybil}} & |
\parbox{90pt}{Entity identification \cite{ajmani02conchord}, \cite{douceur02sybil}} & |
1092 |
\parbox{110pt}{Identify participating entities reliably and efficiently } & |
\parbox{110pt}{Identify participating entities reliably and efficiently.} & |
1093 |
\parbox{110pt}{Digital signatures, key infrastructure} & |
\parbox{110pt}{Digital signatures, key infrastructure.} & |
1094 |
\parbox{110pt}{Not practically realizable} |
\parbox{110pt}{Not practically realizable.} |
1095 |
\\ \hline |
\\ \hline |
1096 |
|
|
1097 |
|
|
1098 |
\parbox{90pt}{Data integrity/authenticity \cite{fips-sha-1}, \cite{rivest96sdsi}, \cite{spkiworkinggroup}} & |
\parbox{90pt}{Data integrity/authenticity \cite{fips-sha-1}, \cite{rivest96sdsi}, \cite{spkiworkinggroup}} & |
1099 |
\parbox{110pt}{Integrity/originality of data is unknown} & |
\parbox{110pt}{Integrity/originality of data is unknown.} & |
1100 |
\parbox{110pt}{Cryptographic content hashes, key architectures} & |
\parbox{110pt}{Cryptographic content hashes, key architectures.} & |
1101 |
\parbox{110pt}{For data integrity, there are working solutions, but for data authenticity, some of the solutions are partial, which may be practically realizable} |
\parbox{110pt}{For data integrity, there are working solutions, but for data authenticity, some of the solutions are partial, which may be practically realizable.} |
1102 |
\\ \hline |
\\ \hline |
1103 |
|
|
1104 |
|
|
1105 |
\parbox{90pt}{Anonymity \cite{dingledine00free, tarzan:ccs9, pub00, clarke00freenet, reiter98crowds, 352607, 502002}} & |
\parbox{90pt}{Anonymity \cite{dingledine00free, tarzan:ccs9, pub00, clarke00freenet, reiter98crowds, 352607, 502002}} & |
1106 |
\parbox{110pt}{Anonymity cannot be provided in all cases} & |
\parbox{110pt}{Anonymity cannot be provided in all cases.} & |
1107 |
\parbox{110pt}{Remailers, pre-routing} & |
\parbox{110pt}{Remailers, pre-routing.} & |
1108 |
\parbox{110pt}{Total anonymity cannot be provided yet} |
\parbox{110pt}{Total anonymity cannot be provided yet.} |
1109 |
\\ \hline |
\\ \hline |
1110 |
|
|
1111 |
|
|
1112 |
\parbox{90pt}{Malicious peers \cite{sit02securitycons, castro02securerouting}} & |
\parbox{90pt}{Malicious peers \cite{sit02securitycons, castro02securerouting}} & |
1113 |
\parbox{110pt}{How to identify malicious peers in the system ?} & |
\parbox{110pt}{How to identify malicious peers in the system ?} & |
1114 |
\parbox{110pt}{Create invariants for peer behavior, verify invariants, self-certifying data} & |
\parbox{110pt}{Create invariants for peer behavior, verify invariants, self-certifying data.} & |
1115 |
\parbox{110pt}{Partial solutions, self-certifying data most reliable} |
\parbox{110pt}{Partial solutions, self-certifying data most reliable.} |
1116 |
\\ \hline |
\\ \hline |
1117 |
|
|
1118 |
|
|
1119 |
\parbox{90pt}{Access Control \cite{nejdl03accesscontrol, daswani03openproblems}} & |
\parbox{90pt}{Access Control \cite{nejdl03accesscontrol, daswani03openproblems}} & |
1120 |
\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} & |
\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} & |
1121 |
\parbox{110pt}{Schema-based rules} & |
\parbox{110pt}{Schema-based rules.} & |
1122 |
\parbox{110pt}{Some initial experiences, needs more research} |
\parbox{110pt}{Some initial experiences, needs more research.} |
1123 |
\\ \hline |
\\ \hline |
1124 |
|
|
1125 |
|
|
1126 |
\parbox{90pt}{Inconsistent behavior \cite{sit02securitycons}} & |
\parbox{90pt}{Inconsistent behavior \cite{sit02securitycons}} & |
1127 |
\parbox{110pt}{Hostile peer could act correctly with its neighbors, but incorrectly with others} & |
\parbox{110pt}{Hostile peer could act correctly with its neighbors, but incorrectly with others.} & |
1128 |
\parbox{110pt}{Public keys, digital signatures} & |
\parbox{110pt}{Public keys, digital signatures.} & |
1129 |
\parbox{110pt}{Not practical approach/working proposal created yet} |
\parbox{110pt}{Not practical approach/working proposal created yet.} |
1130 |
\\ \hline |
\\ \hline |
1131 |
|
|
1132 |
|
|
1133 |
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} & |
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} & |
1134 |
\parbox{110pt}{Joining peer may join parallel network, formed a group of hostile peers, hostile peer(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.} & |
1135 |
\parbox{110pt}{Use trusted peers, based on history information, cryptography, key infrastructure} & |
\parbox{110pt}{Use trusted peers, based on history information, cryptography, key infrastructure.} & |
1136 |
\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.} |
1137 |
\\ \hline |
\\ \hline |
1138 |
|
|
1139 |
|
|
1140 |
\parbox{90pt}{External security threats \cite{grahamp2psecurity}} & |
\parbox{90pt}{External security threats \cite{grahamp2psecurity}} & |
1141 |
\parbox{110pt}{Viruses, trojans, sniffers} & |
\parbox{110pt}{Viruses, trojans, sniffers.} & |
1142 |
\parbox{110pt}{Data integrity/authenticity, distributed anti virus software} & |
\parbox{110pt}{Data integrity/authenticity, distributed anti virus software.} & |
1143 |
\parbox{110pt}{Not much research has been done on this area} |
\parbox{110pt}{Not much research has been done on this area.} |
1144 |
\\ \hline |
\\ \hline |
1145 |
|
|
1146 |
\caption{Security problems in Peer-to-Peer.} |
\caption{Security problems in Peer-to-Peer.} |
1237 |
is designed for the CAN system \cite{ratnasamy01can}. |
is designed for the CAN system \cite{ratnasamy01can}. |
1238 |
|
|
1239 |
Recent study has been focused on the feasibility of Peer-to-Peer Web-like indexing and searching |
Recent study has been focused on the feasibility of Peer-to-Peer Web-like indexing and searching |
1240 |
on top of tightly structured overlays \cite{li03feasibility}. Authors argue, that it is possible to implement |
on top of tightly structured overlays \cite{li03feasibility}. Authors argue that it is possible to implement |
1241 |
Peer-to-Peer Web-like search with certain compromises. First, Peer-to-Peer search engine may need to |
Peer-to-Peer Web-like search with certain compromises. First, Peer-to-Peer search engine may need to |
1242 |
decrease the result quality in order to make searching more efficient. Second, Peer-to-Peer systems must |
decrease the result quality in order to make searching more efficient. Second, Peer-to-Peer systems must |
1243 |
consult the properties of underlying network for better performance. |
consult the properties of underlying network for better performance. |
1336 |
\endfirsthead |
\endfirsthead |
1337 |
|
|
1338 |
\multicolumn{4}{c}% |
\multicolumn{4}{c}% |
1339 |
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
{{\tablename\ \thetable{} -- continued from the previous page}} \\ |
1340 |
\hline \multicolumn{1}{|c|}{\textbf{Problem}} & |
\hline \multicolumn{1}{|c|}{\textbf{Problem}} & |
1341 |
\multicolumn{1}{c|}{\textbf{Problem description}} & |
\multicolumn{1}{c|}{\textbf{Problem description}} & |
1342 |
\multicolumn{1}{c|}{\textbf{Solutions}} & |
\multicolumn{1}{c|}{\textbf{Solutions}} & |
1348 |
|
|
1349 |
\parbox{90pt}{Web indexing and searching \cite{li03feasibility, Bhattacharjee03resultcache, 362692, CuencaAcuna2002DSIWorkshop, |
\parbox{90pt}{Web indexing and searching \cite{li03feasibility, Bhattacharjee03resultcache, 362692, CuencaAcuna2002DSIWorkshop, |
1350 |
rhea02probabilistic, joseph02neurogrid, crespo02semanticoverlay, joseph02p2players, chord:om_p-meng, wittengigabytes, 338634}} & |
rhea02probabilistic, joseph02neurogrid, crespo02semanticoverlay, joseph02p2players, chord:om_p-meng, wittengigabytes, 338634}} & |
1351 |
\parbox{110pt}{Perform Web like searches in Peer-to-Peer network} & |
\parbox{110pt}{Perform Web like searches in Peer-to-Peer network.} & |
1352 |
\parbox{110pt}{Data compression, view trees, bloom filters and its variations, gap compression, index intersection optimizations, clustering} & |
\parbox{110pt}{Data compression, view trees, bloom filters and its variations, gap compression, index intersection optimizations, clustering.} & |
1353 |
\parbox{110pt}{Effective but complex solutions, some compromises have to be done (decrease result quality, modify overlay's structure), more research needed} |
\parbox{110pt}{Effective but complex solutions, some compromises have to be done (decrease result quality, modify overlay's structure), more research needed.} |
1354 |
\\ \hline |
\\ \hline |
1355 |
|
|
1356 |
|
|
1359 |
ramanathan02goodpeers, kleinberg99small, nips02-Kleinberg, zhang02using, watts00dynamics, karger02findingnearest, |
ramanathan02goodpeers, kleinberg99small, nips02-Kleinberg, zhang02using, watts00dynamics, karger02findingnearest, |
1360 |
brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, ng02predicting, pias03lighthouse, waterhouse02searchp2p, botros01jxtasearch, |
brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, ng02predicting, pias03lighthouse, waterhouse02searchp2p, botros01jxtasearch, |
1361 |
ganesan02yappers}} & |
ganesan02yappers}} & |
1362 |
\parbox{110pt}{Find resource efficiently, if resource exists (loosely structured)} & |
\parbox{110pt}{Find resource efficiently, if resource exists (loosely structured).} & |
1363 |
\parbox{110pt}{Super peers, peer clusters, caching techniques} & |
\parbox{110pt}{Super peers, peer clusters, caching techniques.} & |
1364 |
\parbox{110pt}{More efficient, less network traffic, not comparable to the efficiency of tightly structured systems} |
\parbox{110pt}{More efficient, less network traffic, not comparable to the efficiency of tightly structured systems.} |
1365 |
\\ \hline |
\\ \hline |
1366 |
|
|
1367 |
|
|
1368 |
\parbox{90pt}{Richness of queries \cite{harren02complex, ansaryefficientbroadcast03, andrzejak02rangequeries}} & |
\parbox{90pt}{Richness of queries \cite{harren02complex, ansaryefficientbroadcast03, andrzejak02rangequeries}} & |
1369 |
\parbox{110pt}{Query languages should be more powerful in tightly structured overlays} & |
\parbox{110pt}{Query languages should be more powerful in tightly structured overlays.} & |
1370 |
\parbox{110pt}{SQL-like queries} & |
\parbox{110pt}{SQL-like queries.} & |
1371 |
\parbox{110pt}{Hard to implement, increases system complexity, not much research has been done} |
\parbox{110pt}{Hard to implement, increases system complexity, not much research has been done.} |
1372 |
\\ \hline |
\\ \hline |
1373 |
|
|
1374 |
|
|
1375 |
\parbox{90pt}{Robustness \cite{datar02butterflies, saia02dynamicfaultcontentnetwork, fiat02censorship, aspnes02faultrouting, albert-00-tolerance, libennowell01observations}} & |
\parbox{90pt}{Robustness \cite{datar02butterflies, saia02dynamicfaultcontentnetwork, fiat02censorship, aspnes02faultrouting, albert-00-tolerance, libennowell01observations}} & |
1376 |
\parbox{110pt}{How well system performs under hostile attacks/in the case of severe failure ?} & |
\parbox{110pt}{How well system performs under hostile attacks/in the case of severe failure ?} & |
1377 |
\parbox{110pt}{Self-tuning, backup links, use diverse routing paths, power-law networks/properties} & |
\parbox{110pt}{Self-tuning, backup links, use diverse routing paths, power-law networks/properties.} & |
1378 |
\parbox{110pt}{Working solutions} |
\parbox{110pt}{Partially working solutions.} |
1379 |
\\ \hline |
\\ \hline |
1380 |
|
|
1381 |
|
|
1382 |
\parbox{90pt}{Quality of Service} & |
\parbox{90pt}{Quality of Service} & |
1383 |
\parbox{110pt}{The system can only provide (at most) best effort services} & |
\parbox{110pt}{The system can only provide (at most) best effort services.} & |
1384 |
\parbox{110pt}{Use network proximity for better network performance (bandwidth, latency, jitter, packet loss)} & |
\parbox{110pt}{Use network proximity for better network performance (bandwidth, latency, jitter, packet loss).} & |
1385 |
\parbox{110pt}{Increases system complexity, some initial experiences, need more research} |
\parbox{110pt}{Increases system complexity, some initial experiences, need more research.} |
1386 |
\\ \hline |
\\ \hline |
1387 |
|
|
1388 |
|
|
1389 |
\parbox{90pt}{Data availability/persistence \cite{bhagwan03availability}} & |
\parbox{90pt}{Data availability/persistence \cite{bhagwan03availability}} & |
1390 |
\parbox{110pt}{Data might be temporarily unavailable, or lost permanently} & |
\parbox{110pt}{Data might be temporarily unavailable, or lost permanently.} & |
1391 |
\parbox{110pt}{Data caching, data replication} & |
\parbox{110pt}{Data caching, data replication.} & |
1392 |
\parbox{110pt}{Working solutions, but creates more traffic and overhead per peer} |
\parbox{110pt}{Working solutions, but creates more traffic and overhead per peer.} |
1393 |
\\ \hline |
\\ \hline |
1394 |
|
|
1395 |
|
|
1396 |
\parbox{90pt}{Network proximity \cite{pias03lighthouse, ng02predicting, ratnasamy02ght, eriksson03peernet, castro02networkproximity}} & |
\parbox{90pt}{Network proximity \cite{pias03lighthouse, ng02predicting, ratnasamy02ght, eriksson03peernet, castro02networkproximity}} & |
1397 |
\parbox{110pt}{Can we take into account the underlying network's properties better when forming overlay network (network-awareness for performance) ?} & |
\parbox{110pt}{Can we take into account the underlying network's properties better when forming overlay network (network-awareness for performance) ?} & |
1398 |
\parbox{110pt}{Global network positioning, lighthouse technique, triangulated heuristics} & |
\parbox{110pt}{Global network positioning, lighthouse technique, triangulated heuristics.} & |
1399 |
\parbox{110pt}{Increases system complexity, no real world experience in a wide scale, proposed solutions are susceptible to single point of failure} |
\parbox{110pt}{Increases system complexity, no real world experience in a wide scale, proposed solutions are susceptible to single point of failure.} |
1400 |
\\ \hline |
\\ \hline |
1401 |
|
|
1402 |
|
|
1403 |
\parbox{90pt}{Locality \cite{keleher-02-p2p, hildrum02distributedobject, freedman02trie, sloppy:iptps03, plaxton97accessingnearby, karger02findingnearest}} & |
\parbox{90pt}{Locality \cite{keleher-02-p2p, hildrum02distributedobject, freedman02trie, sloppy:iptps03, plaxton97accessingnearby, karger02findingnearest}} & |
1404 |
\parbox{110pt}{Could tightly structured systems exploit locality properties better ?} & |
\parbox{110pt}{Could tightly structured systems exploit locality properties better ?} & |
1405 |
\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.} & |
1406 |
\parbox{110pt}{Working solutions} |
\parbox{110pt}{Partially working solutions.} |
1407 |
\\ \hline |
\\ \hline |
1408 |
|
|
1409 |
|
|
1410 |
\parbox{90pt}{Hot spots \cite{258660, sloppy:iptps03, maymounkov03ratelesscodes}} & |
\parbox{90pt}{Hot spots \cite{258660, sloppy:iptps03, maymounkov03ratelesscodes}} & |
1411 |
\parbox{110pt}{What will happen if some resource is extremely popular and only one peer is hosting it ?} & |
\parbox{110pt}{What will happen if some resource is extremely popular and only one peer is hosting it ?} & |
1412 |
\parbox{110pt}{Caching, multisource downloads, replication, load balancing, sloppy hashing} & |
\parbox{110pt}{Caching, multisource downloads, replication, load balancing, sloppy hashing.} & |
1413 |
\parbox{110pt}{For query hot spots, caching and multisource downloads efficiently reduce hot spots, for routing hot spots, benefits are smaller} |
\parbox{110pt}{For query hot spots, caching and multisource downloads efficiently reduce hot spots, for routing hot spots, benefits are smaller.} |
1414 |
\\ \hline |
\\ \hline |
1415 |
|
|
1416 |
|
|
1417 |
\parbox{90pt}{Load balancing \cite{rao03loadbalancing, ledlie02selfp2p, byers03dhtbalancing}} & |
\parbox{90pt}{Load balancing \cite{rao03loadbalancing, ledlie02selfp2p, byers03dhtbalancing}} & |
1418 |
\parbox{110pt}{Random (but uniformly distributed) identifier selection could cause system inbalance among participants with different capabilities} & |
\parbox{110pt}{Random (but uniformly distributed) identifier selection could cause system inbalance among participants with different capabilities.} & |
1419 |
\parbox{110pt}{Caching, virtual server transfers} & |
\parbox{110pt}{Caching, virtual server transfers.} & |
1420 |
\parbox{110pt}{Effective, more research required in fully dynamic environment} |
\parbox{110pt}{Effective, more research required in fully dynamic environment.} |
1421 |
\\ \hline |
\\ \hline |
1422 |
|
|
1423 |
\parbox{90pt}{System in flux \cite{libennowell01observations, 571863, ledlie02selfp2p, albert-02-statistical}} & |
\parbox{90pt}{System in flux \cite{libennowell01observations, 571863, ledlie02selfp2p, albert-02-statistical}} & |
1424 |
\parbox{110pt}{Peers 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 ?} & |
1425 |
\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.} & |
1426 |
\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).} |
1427 |
\\ \hline |
\\ \hline |
1428 |
|
|
1429 |
\parbox{90pt}{Sudden network partition \cite{harvey03skipnet1, harvey03skipnet2, rowston03controlloingreliability}} & |
\parbox{90pt}{Sudden network partition \cite{harvey03skipnet1, harvey03skipnet2, rowston03controlloingreliability}} & |
1430 |
\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.} & |
1431 |
\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).} & |
1432 |
\parbox{110pt}{Creates more overhead/space requirements per peer} |
\parbox{110pt}{Creates more overhead/space requirements per peer.} |
1433 |
\\ \hline |
\\ \hline |
1434 |
|
|
1435 |
\parbox{90pt}{Fail Stop \cite{rowston03controlloingreliability, zhang03somo}} & |
\parbox{90pt}{Fail Stop \cite{rowston03controlloingreliability, zhang03somo}} & |
1436 |
\parbox{110pt}{A faulty peer stops working} & |
\parbox{110pt}{A faulty peer stops working.} & |
1437 |
\parbox{110pt}{Failure detectors, informing algorithms} & |
\parbox{110pt}{Failure detectors, informing algorithms.} & |
1438 |
\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.} |
1439 |
\\ \hline |
\\ \hline |
1440 |
|
|
1441 |
|
|
1442 |
\parbox{90pt}{Byzantine faults \cite{296824}} & |
\parbox{90pt}{Byzantine faults \cite{296824}} & |
1443 |
\parbox{110pt}{Faulty peers may behave arbitrarily} & |
\parbox{110pt}{Faulty peers may behave arbitrarily.} & |
1444 |
\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.} & |
1445 |
\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.} |
1446 |
\\ \hline |
\\ \hline |
1447 |
|
|
1448 |
\caption{Performance and usability problems in Peer-to-Peer.} |
\caption{Performance and usability problems in Peer-to-Peer.} |
1525 |
\endfirsthead |
\endfirsthead |
1526 |
|
|
1527 |
\multicolumn{4}{c}% |
\multicolumn{4}{c}% |
1528 |
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
{{\tablename\ \thetable{} -- continued from the previous page}} \\ |
1529 |
\hline \multicolumn{1}{|c|}{\textbf{Problem}} & |
\hline \multicolumn{1}{|c|}{\textbf{Problem}} & |
1530 |
\multicolumn{1}{c|}{\textbf{Problem description}} & |
\multicolumn{1}{c|}{\textbf{Problem description}} & |
1531 |
\multicolumn{1}{c|}{\textbf{Solutions}} & |
\multicolumn{1}{c|}{\textbf{Solutions}} & |
1537 |
|
|
1538 |
|
|
1539 |
\parbox{90pt}{Mutual distrust \cite{cornelli02reputableservents, aberer01trust}} & |
\parbox{90pt}{Mutual distrust \cite{cornelli02reputableservents, aberer01trust}} & |
1540 |
\parbox{110pt}{Nobody trusts anybody} & |
\parbox{110pt}{Nobody trusts anybody.} & |
1541 |
\parbox{110pt}{Reputation methods, key infrastructures} & |
\parbox{110pt}{Reputation methods, key infrastructures.} & |
1542 |
\parbox{110pt}{Resource demanding, not practical to implement/not working solutions, no real world experience in a wide scale} |
\parbox{110pt}{Resource demanding, not practical to implement/not working solutions, no real world experience in a wide scale.} |
1543 |
\\ \hline |
\\ \hline |
1544 |
|
|
1545 |
|
|
1546 |
\parbox{90pt}{Lack of motivation to cooperate \cite{golle01incentivesp2p, ngan03enforcefile, shneidman03rationality}} & |
\parbox{90pt}{Lack of motivation to cooperate \cite{golle01incentivesp2p, ngan03enforcefile, shneidman03rationality}} & |
1547 |
\parbox{110pt}{All participants do not behave like they should be, instead they go for own profit} & |
\parbox{110pt}{All participants do not behave like they should be, instead they go for own profit.} & |
1548 |
\parbox{110pt}{Different reputation methods} & |
\parbox{110pt}{Different reputation methods.} & |
1549 |
\parbox{110pt}{No real world experience in a wide scale} |
\parbox{110pt}{No real world experience in a wide scale.} |
1550 |
\\ \hline |
\\ \hline |
1551 |
|
|
1552 |
|
|
1553 |
\parbox{90pt}{Heterogeneity \cite{saroiu02measurementstudyp2p, brinkmann02compactplacement, zhao02brocade, gurmeet03symphony, rowston03controlloingreliability}} & |
\parbox{90pt}{Heterogeneity \cite{saroiu02measurementstudyp2p, brinkmann02compactplacement, zhao02brocade, gurmeet03symphony, rowston03controlloingreliability}} & |
1554 |
\parbox{110pt}{There are different kind of peers 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.} & |
1555 |
\parbox{110pt}{Super peers (loosely structured), clusters (loosely structured) additional layer upon tighty structured systems, structure itself is simple (tightly structured)} & |
\parbox{110pt}{Super peers (loosely structured), clusters (loosely structured) additional layer upon tighty structured systems, structure itself is simple (tightly structured).} & |
1556 |
\parbox{110pt}{Working solutions, increases system complexity (additional layer)} |
\parbox{110pt}{Working solutions, increases system complexity (additional layer).} |
1557 |
\\ \hline |
\\ \hline |
1558 |
|
|
1559 |
|
|
1560 |
\parbox{90pt}{Programming guidelines \cite{zhao03api, frise02p2pframework, babaoglu02anthill, rhea03benchmarks, garciamolina03sil, balakrishnan03semanticfree}} & |
\parbox{90pt}{Programming guidelines \cite{zhao03api, frise02p2pframework, babaoglu02anthill, rhea03benchmarks, garciamolina03sil, balakrishnan03semanticfree}} & |
1561 |
\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.} & |
1562 |
\parbox{110pt}{Common frameworks and APIs} & |
\parbox{110pt}{Common frameworks and APIs.} & |
1563 |
\parbox{110pt}{Common framework/API is still missing, a few proposals have been made (tightly structured)} |
\parbox{110pt}{Common framework/API is still missing, a few proposals have been made (tightly structured).} |
1564 |
\\ \hline |
\\ \hline |
1565 |
|
|
1566 |
|
|
1567 |
\parbox{90pt}{Comprehensive simulations or analysis of Peer-to-Peer system} & |
\parbox{90pt}{Comprehensive simulations or analysis of Peer-to-Peer system} & |
1568 |
\parbox{110pt}{Ability to simulate whole Peer-to-Peer network's usage patterns, network traffics, flux state etc.} & |
\parbox{110pt}{Ability to simulate whole Peer-to-Peer network's usage patterns, network traffics, flux state etc.} & |
1569 |
\parbox{110pt}{Use same techniques as simulating/analyzing the Internet} & |
\parbox{110pt}{Use same techniques as simulating/analyzing the Internet.} & |
1570 |
\parbox{110pt}{Only small subsets of Peer-to-Peer networks has been analysed, because of ad hoc properties of network, more powerful solutions needed} |
\parbox{110pt}{Only small subsets of Peer-to-Peer networks has been analysed, because of ad hoc properties of network, more powerful solutions needed.} |
1571 |
\\ \hline |
\\ \hline |
1572 |
|
|
1573 |
|
|
1574 |
\parbox{90pt}{Overlay management and health monitoring \cite{zhang03somo}} & |
\parbox{90pt}{Overlay management and health monitoring \cite{zhang03somo}} & |
1575 |
\parbox{110pt}{System is self-capable to monitor it is status and health for better performance} & |
\parbox{110pt}{System is self-capable to monitor it is status and health for better performance.} & |
1576 |
\parbox{110pt}{Build a meta data overlay atop of structured overlay (such as SOMO for structured overlays), make local decisions about overlay (loosely structured)} & |
\parbox{110pt}{Build a meta data overlay atop of structured overlay (such as SOMO for structured overlays), make local decisions about overlay (loosely structured).} & |
1577 |
\parbox{110pt}{For tightly structured overlays, efficient and simple to implement, fault tolerance unknown, for the loosely structured approach 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 the loosely structured approach not necessarily efficient because decisions are based on local knowledge.} |
1578 |
\\ \hline |
\\ \hline |
1579 |
|
|
1580 |
\parbox{90pt}{Locating Peer-to-Peer network} & |
\parbox{90pt}{Locating Peer-to-Peer network} & |
1581 |
\parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer network, if it exists} & |
\parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer network, if it exists.} & |
1582 |
\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com), peer's history information} & |
\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com), peer's history information.} & |
1583 |
\parbox{110pt}{Depends on implementation and purpose of the system, for a desktop system there are working solutions} |
\parbox{110pt}{Depends on implementation and purpose of the system, for a desktop system there are working solutions.} |
1584 |
\\ \hline |
\\ \hline |
1585 |
|
|
1586 |
\caption{Miscellaneous problems in Peer-to-Peer.} |
\caption{Miscellaneous problems in Peer-to-Peer.} |
1600 |
|
|
1601 |
The Fenfire project \cite{fenfireurl} is an effort to build a location transparent, hyperstructured desktop |
The Fenfire project \cite{fenfireurl} is an effort to build a location transparent, hyperstructured desktop |
1602 |
environment. By location transparent, we mean hiding the heterogeneous and distributed nature of the system |
environment. By location transparent, we mean hiding the heterogeneous and distributed nature of the system |
1603 |
so that it appears to the end user like one system and by hyperstructured system |
so that it appears to the end user like one system, and by hyperstructured system |
1604 |
a system in which data can be associated with other data arbitrarily. Fenfire uses xanalogical storage model |
a system in which data can be associated with other data arbitrarily. Fenfire uses xanalogical storage model |
1605 |
\cite{ted-xu-model} as a basis for hyperstructured media. Each data item in the Fenfire system has a globally unique |
\cite{ted-xu-model} as a basis for hyperstructured media. Each data item in the Fenfire system has a globally unique |
1606 |
identifier. This property should allow making references between \emph{any} |
identifier. This property allows making references between \emph{any} |
1607 |
data easier and more seamlessly interoperating than in other systems. For location transparency in the Fenfire system, |
data easier and more seamlessly interoperating than in other systems. For location transparency in the Fenfire system, |
1608 |
we are currently analysing the applicability of Peer-to-Peer infrastructure. |
we are currently analysing the applicability of Peer-to-Peer infrastructure. |
1609 |
|
|
1629 |
\section{Xanalogical storage model} |
\section{Xanalogical storage model} |
1630 |
|
|
1631 |
Xanalogical storage model \cite{nelson99xanalogicalneeded} is a different kind of model for |
Xanalogical storage model \cite{nelson99xanalogicalneeded} is a different kind of model for |
1632 |
presenting data and relationships between data, e.g., while in the World Wide Web links are |
presenting data and relationships between data. For example, in the World Wide Web links are |
1633 |
between documents, in the xanalogical storage model links are between individual |
between documents, while in the xanalogical storage model links are between individual |
1634 |
characters\footnote{Xanalogical storage model |
characters\footnote{Xanalogical storage model |
1635 |
is not limited to text. It can support arbitrary data, e.g., pixels of picture or |
is not limited to text. It can support arbitrary data, e.g., pixels of picture or |
1636 |
frames of video.}. \emph{Enfilade} is a mutable ''virtual file'' (or part of one), which is a list |
frames of video.}. \emph{Enfilade} is a mutable ''virtual file'' (or part of one), which is a list |
1666 |
\section{Storm} |
\section{Storm} |
1667 |
|
|
1668 |
In this section, we will give a brief overview of Storm design. More information can be found |
In this section, we will give a brief overview of Storm design. More information can be found |
1669 |
from recent publications. For general discussion about Fenfire in Peer-to-Peer environment, |
from recent publications. For detailed Storm design, see \cite{fallenstein03storm}. |
|
see \cite{lukka02freenetguids}, and for detailed Storm design, see \cite{fallenstein03storm}. |
|
1670 |
|
|
1671 |
Storm (for \emph{STORage Module}) stores all data as \emph{blocks}, which |
Storm (for \emph{STORage Module}) stores all data as \emph{blocks}, which |
1672 |
are immutable byte sequences. Storm \emph{assigns} a globally unique identifier to each |
are immutable byte sequences. Storm \emph{assigns} a globally unique identifier to each |
1712 |
\centering |
\centering |
1713 |
\includegraphics[width=10cm, height=10cm]{storm_uml.eps} |
\includegraphics[width=10cm, height=10cm]{storm_uml.eps} |
1714 |
\caption{Implementation of the xanalogical storage model on Storm. Storm storage model is based on |
\caption{Implementation of the xanalogical storage model on Storm. Storm storage model is based on |
1715 |
fluid media units, i.e., fluid media units are smallest units of data. Currently, Storm provides a support |
fluid media units, which represent the smallest units of data. Currently, Storm provides a support |
1716 |
for textual fluid media units (characters) only, but a support for arbitrary data (e.g., video or music) is |
for textual fluid media units (characters) only, but a support for arbitrary data (e.g., video or music) is |
1717 |
planned in future versions of Storm.} |
planned in future versions of Storm.} |
1718 |
\label{fig:storm_model} |
\label{fig:storm_model} |
1833 |
within a small group of working people. |
within a small group of working people. |
1834 |
|
|
1835 |
For better fault tolerance and self-monitoring for Fenfire, we propose techniques |
For better fault tolerance and self-monitoring for Fenfire, we propose techniques |
1836 |
presented by Rowston et al. \cite{rowston03controlloingreliability}. With these |
presented by Rowston et al. \cite{rowston03controlloingreliability}. With their methods, |
1837 |
techniques, we can ensure the performance of the Fenfire system in a highly adverse conditions, such |
we can ensure the performance of the Fenfire system in a highly adverse conditions, such |
1838 |
as sudden network partition, or highly dynamic and heterogeneous environment. |
as sudden network partition, or highly dynamic and heterogeneous environment. |
1839 |
|
|
1840 |
Additionally, for more efficient data transfer, we can use variable techniques for this purpose. |
Additionally, for more efficient data transfer, we can use variable techniques for this purpose. |
1865 |
Also, we don't respond to the security issues related to Peer-to-Peer systems, since there is no working solution |
Also, we don't respond to the security issues related to Peer-to-Peer systems, since there is no working solution |
1866 |
available yet. We either assume that Fenfire has a reliable technique for identifying individual entities, or |
available yet. We either assume that Fenfire has a reliable technique for identifying individual entities, or |
1867 |
there are no hostile entities among participating peers, i.e., Storm blocks can be identified correctly (e.g., when |
there are no hostile entities among participating peers, i.e., Storm blocks can be identified correctly (e.g., when |
1868 |
performing searches). In the next subsection, we discuss security problems in more detail. |
performing searches). In the next subsection, we discuss security problems in more detail. |
1869 |
|
|
1870 |
|
Next, we present methods for locating Storm data blocks using the DOLR abstraction. |
1871 |
|
|
1872 |
|
|
1873 |
\begin{itemize} |
\begin{itemize} |