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

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

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

revision 1.52 by hemppah, Thu Feb 20 10:07:18 2003 UTC revision 1.53 by hemppah, Thu Feb 20 11:32:58 2003 UTC
# Line 23  Line 23 
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ä\\
# Line 356  load balance Line 356  load balance
356    
357  \cite{rowston03controlloingreliability}  \cite{rowston03controlloingreliability}
358    
359  \cite{Bhattacharjee03resultcache}  
360    
361  \cite{byers03dhtbalancing}  \cite{byers03dhtbalancing}
362    
# Line 704  Number of messages when an object lookup Line 704  Number of messages when an object lookup
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}
# Line 821  b) Dynamically Fault-Tolerant Content Ad Line 830  b) Dynamically Fault-Tolerant Content Ad
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
# Line 922  d) Access Control (Gzz: priority 2) Line 931  d) Access Control (Gzz: priority 2)
931    
932  \cite{juels99clientpuzzles}  \cite{juels99clientpuzzles}
933    
 Anonymoys \cite{352607}  
   
 Anonymoys \cite{293447}  
934    
935  Censorship \cite{502002}  Censorship \cite{502002}
936    
# Line 937  Censorship \cite{502002} Line 943  Censorship \cite{502002}
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) ?
# Line 954  Principles on scalable search in decentr Line 958  Principles on scalable search in decentr
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}
# Line 1308  is not scalable, since searching creates Line 1280  is not scalable, since searching creates
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
# Line 1338  is not scalable, since searching creates Line 1329  is not scalable, since searching creates
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} &
# Line 1465  that share text with the current documen Line 1436  that share text with the current documen
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}
# Line 1487  that share text with the current documen Line 1458  that share text with the current documen
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    
# Line 1536  return the most recent block, if the sig Line 1507  return the most recent block, if the sig
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
# Line 1581  P2P network requirements Line 1531  P2P network 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}

Legend:
Removed from v.1.52  
changed lines
  Added in v.1.53

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