23 |
|
|
24 |
\author{Hermanni Hyytiälä} |
\author{Hermanni Hyytiälä} |
25 |
|
|
26 |
\linja{Ohjelmistotekniikka} |
\linja{Software Engineering} |
27 |
|
|
28 |
\tyyppi{pro gradu-tutkielma} |
\tyyppi{Master's Thesis} |
29 |
|
|
30 |
\keywords{Peer-to-Peer, Peer-to-Peer, networking, distributen computing} |
\keywords{Peer-to-Peer, P2P, Hypermedia, Distributed systems} |
31 |
|
|
32 |
\avainsanat{Vertaisverkot, Peer-to-Peer, tietoverkot, hajautetut järjestelmät} |
\avainsanat{Vertaisverkot, Hypermedia, hajautetut järjestelmät} |
33 |
|
|
34 |
\contactinformation{\\ |
\contactinformation{\\ |
35 |
Hermanni Hyytiälä\\ |
Hermanni Hyytiälä\\ |
356 |
|
|
357 |
\cite{rowston03controlloingreliability} |
\cite{rowston03controlloingreliability} |
358 |
|
|
359 |
\cite{Bhattacharjee03resultcache} |
|
360 |
|
|
361 |
\cite{byers03dhtbalancing} |
\cite{byers03dhtbalancing} |
362 |
|
|
704 |
|
|
705 |
\section{Security problems in Peer-to-Peer} |
\section{Security problems in Peer-to-Peer} |
706 |
|
|
707 |
\subsection{Anonymity} |
\subsection{Attacks} |
708 |
\subsection{Attack models} |
|
709 |
\subsection{Data authenticity and integrity} |
\subsection{Data authenticity and integrity} |
710 |
|
|
711 |
|
\subsection{Anonymity} |
712 |
|
Anonymoys \cite{352607} |
713 |
|
Anonymoys \cite{293447} |
714 |
|
|
715 |
\subsection{Access Control} |
\subsection{Access Control} |
716 |
|
\subsection{Fault-tolerance} |
717 |
|
\subsection{Hostile entities} |
718 |
|
\subsection{Secure Query Routing} |
719 |
|
\subsection{Other Security threds} |
720 |
|
|
721 |
|
|
722 |
-Could we use SDSI/SPKI in our system (it's hierarchical), like in ConChord \cite{ajmani02conchord} |
-Could we use SDSI/SPKI in our system (it's hierarchical), like in ConChord \cite{ajmani02conchord} |
830 |
-system is resilient to adversial and controlled attacks (partial support for dynamic deletions, see below) |
-system is resilient to adversial and controlled attacks (partial support for dynamic deletions, see below) |
831 |
-however, still assume a constant number of participating peers |
-however, still assume a constant number of participating peers |
832 |
-not effiecient methods for maintaining dynamic netoworks |
-not effiecient methods for maintaining dynamic netoworks |
833 |
c) Butterflies and Peer-to-Peer Networks \cite{datar02butterflie} |
c) Butterflies and Peer-to-Peer Networks \cite{datar02butterflies} |
834 |
-system is resilient to adversial and controlled attacks |
-system is resilient to adversial and controlled attacks |
835 |
-support for dynamic deletions and dynamic number of participants |
-support for dynamic deletions and dynamic number of participants |
836 |
-not effiecient methods for maintaining dynamic netoworks |
-not effiecient methods for maintaining dynamic netoworks |
931 |
|
|
932 |
\cite{juels99clientpuzzles} |
\cite{juels99clientpuzzles} |
933 |
|
|
|
Anonymoys \cite{352607} |
|
|
|
|
|
Anonymoys \cite{293447} |
|
934 |
|
|
935 |
Censorship \cite{502002} |
Censorship \cite{502002} |
936 |
|
|
943 |
|
|
944 |
\section{Performance and usability problems in Peer-to-Peer} |
\section{Performance and usability problems in Peer-to-Peer} |
945 |
|
|
|
|
|
|
|
|
946 |
1) Which one is more important: short path length or overhead associated with keeping routing tables updated, e.g. number of state updates whenever join/leave occurs |
1) Which one is more important: short path length or overhead associated with keeping routing tables updated, e.g. number of state updates whenever join/leave occurs |
947 |
(number of neighbors) |
(number of neighbors) |
948 |
2) Are we able to achieve reasonably pathlenghts with less neigbors (Viceroy) ? |
2) Are we able to achieve reasonably pathlenghts with less neigbors (Viceroy) ? |
958 |
3) each additional step during search should not significantly increase the number of nodes visited |
3) each additional step during search should not significantly increase the number of nodes visited |
959 |
|
|
960 |
|
|
961 |
\cite{harren02complex} |
\subsection{Efficient data lookup} |
|
|
|
962 |
\cite{ratnasamy02routing} |
\cite{ratnasamy02routing} |
|
|
|
963 |
\cite{hildrum02distributedobject} |
\cite{hildrum02distributedobject} |
|
|
|
|
\cite{sloppy:iptps03} |
|
|
|
|
|
\cite{yang02improvingsearch} |
|
|
|
|
|
\cite{lv02searchreplication} |
|
|
|
|
|
\cite{libennowell01observations} |
|
|
|
|
|
\cite{karger02findingnearest} |
|
|
|
|
964 |
\cite{adamic02localsearch} |
\cite{adamic02localsearch} |
|
|
|
965 |
\cite{adamic01powerlawsearch} |
\cite{adamic01powerlawsearch} |
|
|
|
966 |
\cite{ripeanu02mappinggnutella} |
\cite{ripeanu02mappinggnutella} |
967 |
|
\cite{lv02searchreplication} |
968 |
\cite{brinkmann02compactplacement} |
\cite{brinkmann02compactplacement} |
|
|
|
|
\cite{joseph02p2players} |
|
|
|
|
969 |
\cite{lv02gnutellascalable} |
\cite{lv02gnutellascalable} |
970 |
|
\cite{osokine02distnetworks} |
971 |
\cite{rao03loadbalancing} |
\cite{harvey03skipnet1} |
|
|
|
|
\cite{zhang03somo} |
|
|
|
|
|
\cite{bhagwan03availability} |
|
|
|
|
|
\cite{li03feasibility} |
|
|
|
|
|
\cite{zhao02brocade} |
|
|
|
|
|
\cite{crespo02semanticoverlay} |
|
|
|
|
972 |
\cite{rhea02probabilistic} |
\cite{rhea02probabilistic} |
|
|
|
973 |
\cite{ansaryefficientbroadcast03} |
\cite{ansaryefficientbroadcast03} |
974 |
|
\cite{castro02networkproximity} |
975 |
|
\cite{yang02efficientsearch} |
976 |
|
\cite{crespo02semanticoverlay} |
977 |
|
Locality \cite{keleher-02-p2p} |
978 |
|
\cite{ng02predicting} |
979 |
|
|
980 |
|
\subsection{Fast and usable search} |
981 |
|
\cite{yang02improvingsearch} |
982 |
|
\cite{kronfol02fasdsearch} |
983 |
|
\cite{harren02complex} |
984 |
|
\cite{joseph02p2players} |
985 |
Bloom filters \cite{362692} |
Bloom filters \cite{362692} |
986 |
|
\cite{andrzejak02rangequeries} |
987 |
|
\cite{li03feasibility} |
988 |
\cite{CuencaAcuna2002DSIWorkshop} |
\cite{CuencaAcuna2002DSIWorkshop} |
989 |
|
\cite{Bhattacharjee03resultcache} |
990 |
|
\cite{chord:om_p-meng} |
991 |
|
|
992 |
Locality \cite{keleher-02-p2p} |
\subsection{System management} |
993 |
|
\cite{sloppy:iptps03} |
994 |
|
\cite{libennowell01observations} |
995 |
|
\cite{karger02findingnearest} |
996 |
|
\cite{rao03loadbalancing} |
997 |
|
\cite{zhang03somo} |
998 |
|
\cite{bhagwan03availability} |
999 |
|
\cite{zhao02brocade} |
1000 |
Practical Byzantine fault tolerance \cite{296824} |
Practical Byzantine fault tolerance \cite{296824} |
1001 |
Byzantine Generals \cite{357176} |
Byzantine Generals \cite{357176} |
1002 |
|
|
|
\cite{castro02networkproximity} |
|
|
|
|
|
\cite{yang02efficientsearch} |
|
|
|
|
1003 |
%dup |
%dup |
1004 |
\cite{liben-nowell02observatorionsp2p} |
\cite{liben-nowell02observatorionsp2p} |
1005 |
\cite{571863} |
\cite{571863} |
1006 |
|
|
1007 |
\cite{ledlie02selfp2p} |
\cite{ledlie02selfp2p} |
1008 |
|
|
|
\cite{andrzejak02rangequeries} |
|
|
|
|
|
\cite{hearn02mojonation} |
|
|
|
|
|
\cite{osokine02distnetworks} |
|
|
|
|
|
\cite{harvey03skipnet1} |
|
|
|
|
|
\cite{ng02predicting} |
|
|
|
|
|
\cite{chord:om_p-meng} |
|
|
|
|
|
|
|
1009 |
\section{Miscellaneous problems in Peer-to-Peer} |
\section{Miscellaneous problems in Peer-to-Peer} |
1010 |
|
|
1011 |
Research on *usage patterns* haven't been done. However, there have been some research |
\subsection{Frameworks} |
|
focusing on file popularity in in www and p2p networks: file popularity follows the zipf/harmonical distribution) |
|
1012 |
|
|
1013 |
\cite{kronfol02fasdsearch} |
\cite{zhao03api} |
1014 |
|
\cite{frise02p2pframework} |
1015 |
|
\cite{babaoglu02anthill} |
1016 |
|
\cite{rhea03benchmarks} |
1017 |
|
|
1018 |
|
\subsection{Social behaviour} |
1019 |
|
\cite{cornelli02reputableservents} |
1020 |
\cite{oram01harnessingpower} |
\cite{oram01harnessingpower} |
|
|
|
|
\cite{krishnamurthy01earlymeasurements} |
|
|
|
|
1021 |
\cite{golle01incentivesp2p} |
\cite{golle01incentivesp2p} |
1022 |
|
\cite{hearn02mojonation} |
1023 |
|
|
1024 |
\cite{cornelli02reputableservents} |
\subsection{Usage patterns} |
|
|
|
1025 |
\cite{saroiu02measurementstudyp2p} |
\cite{saroiu02measurementstudyp2p} |
1026 |
|
\cite{krishnamurthy01earlymeasurements} |
1027 |
|
|
1028 |
\cite{rhea03benchmarks} |
Research on *usage patterns* haven't been done. However, there have been some research |
1029 |
|
focusing on file popularity in in www and p2p networks: file popularity follows the zipf/harmonical distribution) |
|
\cite{zhao03api} |
|
|
|
|
|
\cite{frise02p2pframework} |
|
|
|
|
|
\cite{babaoglu02anthill} |
|
|
|
|
1030 |
|
|
1031 |
|
|
1032 |
\section{Summary} |
\section{Summary} |
1280 |
\parbox{110pt}{Initial theoretical analysis have been created, but not comprehensive model for analysing different system states and its variations (e.g. complex usage patterns)} |
\parbox{110pt}{Initial theoretical analysis have been created, but not comprehensive model for analysing different system states and its variations (e.g. complex usage patterns)} |
1281 |
\\ \hline |
\\ \hline |
1282 |
|
|
1283 |
|
\parbox{90pt}{Sudden network partition} & |
1284 |
|
\parbox{110pt}{Sub network is isolated from other network because of network disconnection} & |
1285 |
|
\parbox{110pt}{Self-tuning, environment observatorion, localized network connection for minimun latency (backup connections)} & |
1286 |
|
\parbox{110pt}{Creates more overhead/space requirements per node} |
1287 |
|
\\ \hline |
1288 |
|
|
1289 |
|
\parbox{90pt}{Fail Stop} & |
1290 |
|
\parbox{110pt}{A faulty node stops working} & |
1291 |
|
\parbox{110pt}{Failure detectors, informing protocols} & |
1292 |
|
\parbox{110pt}{Creates more network traffics, node's information can be outdated, failure detectors not reliable} |
1293 |
|
\\ \hline |
1294 |
|
|
1295 |
|
|
1296 |
|
\parbox{90pt}{Byzantine faults} & |
1297 |
|
\parbox{110pt}{Faulty nodes may behave arbitrarily} & |
1298 |
|
\parbox{110pt}{Byzantine replication protocols -> get information from multiple entities, trust majority's opinion} & |
1299 |
|
\parbox{110pt}{Much research has been done on this field, practical solutions, decreases system's, performance slighly} |
1300 |
|
\\ \hline |
1301 |
|
|
1302 |
|
|
1303 |
\end{longtable} |
\end{longtable} |
1304 |
\normalsize |
\normalsize |
1329 |
\endfoot |
\endfoot |
1330 |
|
|
1331 |
|
|
|
\parbox{90pt}{Sudden network partition} & |
|
|
\parbox{110pt}{Sub network is isolated from other network because of network disconnection} & |
|
|
\parbox{110pt}{Self-tuning, environment observatorion, localized network connection for minimun latency (backup connections)} & |
|
|
\parbox{110pt}{Creates more overhead/space requirements per node} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Fail Stop} & |
|
|
\parbox{110pt}{A faulty node stops working} & |
|
|
\parbox{110pt}{Failure detectors, informing protocols} & |
|
|
\parbox{110pt}{Creates more network traffics, node's information can be outdated, failure detectors not reliable} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{90pt}{Byzantine faults} & |
|
|
\parbox{110pt}{Faulty nodes may behave arbitrarily} & |
|
|
\parbox{110pt}{Byzantine replication protocols -> get information from multiple entities, trust majority's opinion} & |
|
|
\parbox{110pt}{Much research has been done on this field, practical solutions, decreases system's, performance slighly} |
|
|
\\ \hline |
|
|
|
|
|
|
|
1332 |
\parbox{90pt}{Mutual distrust} & |
\parbox{90pt}{Mutual distrust} & |
1333 |
\parbox{110pt}{Nobody trusts anybody} & |
\parbox{110pt}{Nobody trusts anybody} & |
1334 |
\parbox{110pt}{Reputation methods, key infrastructures} & |
\parbox{110pt}{Reputation methods, key infrastructures} & |
1436 |
|
|
1437 |
\cite{lukka02freenetguids} |
\cite{lukka02freenetguids} |
1438 |
|
|
1439 |
\subsection{Block storage} |
\subsection{Storm block storage} |
1440 |
|
|
1441 |
\cite{benja02urn5} |
\cite{benja02urn5} |
1442 |
\cite{balakrishnan03semanticfree} |
\cite{balakrishnan03semanticfree} |
1458 |
-uses SHA-1 for checking data integrity (suits for us very well!) |
-uses SHA-1 for checking data integrity (suits for us very well!) |
1459 |
-we don't have to create 'mini-blocks' for Gzz p2p, since bitTorrent itself partitions data into several blocks for us |
-we don't have to create 'mini-blocks' for Gzz p2p, since bitTorrent itself partitions data into several blocks for us |
1460 |
|
|
1461 |
\section{Motivation} |
\section{Overview} |
1462 |
|
|
1463 |
-need to make Gzz distributed system |
-need to make Gzz distributed system |
1464 |
|
|
1507 |
return the most recent block, if the signing key and block's timestamp are "valid"." |
return the most recent block, if the signing key and block's timestamp are "valid"." |
1508 |
|
|
1509 |
|
|
|
\section{Benefits over existing Peer-to-Peer file sharing systems} |
|
|
|
|
|
- Easy syncing: |
|
|
- Just copy a bunch of blocks |
|
|
%- Documents can be synced & merged |
|
|
%- Inter-document structures can be synced & merged |
|
|
- Syncing can be done without merging immediately, |
|
|
leaving two alternative versions current |
|
|
(so e.g. an automated process is entirely possible, |
|
|
even when there are conflicts) |
|
|
- Versioning |
|
|
|
|
|
From Benja's (plus antont and me) article: |
|
|
- Reliability (old versions, links work always, accessibility, append-and-delete) |
|
|
- Usability in the face of intermittent connectivity |
|
|
(includes syncing, finding a document if available...) |
|
|
- Xanalogical structure |
|
|
(includes versioning, non-breaking links etc.) |
|
|
|
|
|
-current p2p systems don't support all of these properties together |
|
|
|
|
1510 |
\section{Special needs} |
\section{Special needs} |
1511 |
|
|
1512 |
Gzz's requirements |
Gzz's requirements |
1531 |
\cite{bittorrenturl} |
\cite{bittorrenturl} |
1532 |
\cite{maymounkov03ratelesscodes} |
\cite{maymounkov03ratelesscodes} |
1533 |
|
|
1534 |
|
\section{Benefits over existing Peer-to-Peer file sharing systems} |
1535 |
|
|
1536 |
|
- Easy syncing: |
1537 |
|
- Just copy a bunch of blocks |
1538 |
|
%- Documents can be synced & merged |
1539 |
|
%- Inter-document structures can be synced & merged |
1540 |
|
- Syncing can be done without merging immediately, |
1541 |
|
leaving two alternative versions current |
1542 |
|
(so e.g. an automated process is entirely possible, |
1543 |
|
even when there are conflicts) |
1544 |
|
- Versioning |
1545 |
|
|
1546 |
|
From Benja's (plus antont and me) article: |
1547 |
|
- Reliability (old versions, links work always, accessibility, append-and-delete) |
1548 |
|
- Usability in the face of intermittent connectivity |
1549 |
|
(includes syncing, finding a document if available...) |
1550 |
|
- Xanalogical structure |
1551 |
|
(includes versioning, non-breaking links etc.) |
1552 |
|
|
1553 |
|
-current p2p systems don't support all of these properties together |
1554 |
|
|
1555 |
|
|
1556 |
\section{Possible problems} |
\section{Possible problems} |
1557 |
|
|
1558 |
\cite{gribble01p2pdatabase} |
\cite{gribble01p2pdatabase} |