[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Hermanni Hyytiälä <address@hidden>      03/02/20 06:32:58

Modified files:
        Documentation/misc/hemppah-progradu: masterthesis.tex 

Log message:
        Reorg

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.52&tr2=1.53&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.52 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.53
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.52       Thu Feb 
20 05:07:18 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Thu Feb 20 
06:32:58 2003
@@ -23,13 +23,13 @@
 
 \author{Hermanni Hyytiälä}
 
-\linja{Ohjelmistotekniikka}
+\linja{Software Engineering}
 
-\tyyppi{pro gradu-tutkielma}
+\tyyppi{Master's Thesis}
 
-\keywords{Peer-to-Peer, Peer-to-Peer, networking, distributen computing}
+\keywords{Peer-to-Peer, P2P, Hypermedia, Distributed systems}
 
-\avainsanat{Vertaisverkot, Peer-to-Peer, tietoverkot, hajautetut järjestelmät}
+\avainsanat{Vertaisverkot, Hypermedia, hajautetut järjestelmät}
 
 \contactinformation{\\
 Hermanni Hyytiälä\\
@@ -356,7 +356,7 @@
 
 \cite{rowston03controlloingreliability}
 
-\cite{Bhattacharjee03resultcache}
+
 
 \cite{byers03dhtbalancing}
 
@@ -704,10 +704,19 @@
 
 \section{Security problems in Peer-to-Peer}
 
-\subsection{Anonymity}
-\subsection{Attack models}
+\subsection{Attacks}
+
 \subsection{Data authenticity and integrity}
+
+\subsection{Anonymity}
+Anonymoys \cite{352607}
+Anonymoys \cite{293447}
+
 \subsection{Access Control}
+\subsection{Fault-tolerance}
+\subsection{Hostile entities}
+\subsection{Secure Query Routing}
+\subsection{Other Security threds}
 
 
 -Could we use SDSI/SPKI in our system (it's hierarchical), like in ConChord 
\cite{ajmani02conchord}
@@ -821,7 +830,7 @@
 -system is resilient to adversial and controlled attacks (partial support for 
dynamic deletions, see below)
 -however, still assume a constant number of participating peers
 -not effiecient methods for maintaining dynamic netoworks
-c) Butterflies and Peer-to-Peer Networks \cite{datar02butterflie}
+c) Butterflies and Peer-to-Peer Networks \cite{datar02butterflies}
 -system is resilient to adversial and controlled attacks
 -support for dynamic deletions and dynamic number of participants
 -not effiecient methods for maintaining dynamic netoworks
@@ -922,9 +931,6 @@
 
 \cite{juels99clientpuzzles}
 
-Anonymoys \cite{352607}
-
-Anonymoys \cite{293447}
 
 Censorship \cite{502002}
 
@@ -937,8 +943,6 @@
 
 \section{Performance and usability problems in Peer-to-Peer}
 
-
-
 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
  (number of neighbors)
 2) Are we able to achieve reasonably pathlenghts with less neigbors (Viceroy) ?
@@ -954,107 +958,75 @@
 3) each additional step during search should not significantly increase the 
number of nodes visited
 
 
-\cite{harren02complex}
-
+\subsection{Efficient data lookup}
 \cite{ratnasamy02routing}
-
 \cite{hildrum02distributedobject}
-
-\cite{sloppy:iptps03}
-
-\cite{yang02improvingsearch}
-
-\cite{lv02searchreplication}
-
-\cite{libennowell01observations}
-
-\cite{karger02findingnearest}
-
 \cite{adamic02localsearch}
-
 \cite{adamic01powerlawsearch}
-
 \cite{ripeanu02mappinggnutella}
-
+\cite{lv02searchreplication}
 \cite{brinkmann02compactplacement}
-
-\cite{joseph02p2players}
-
 \cite{lv02gnutellascalable}
-
-\cite{rao03loadbalancing}
-
-\cite{zhang03somo}
-
-\cite{bhagwan03availability}
-
-\cite{li03feasibility}
-
-\cite{zhao02brocade}
-
-\cite{crespo02semanticoverlay}
-
+\cite{osokine02distnetworks}
+\cite{harvey03skipnet1}
 \cite{rhea02probabilistic}
-
 \cite{ansaryefficientbroadcast03}
+\cite{castro02networkproximity}
+\cite{yang02efficientsearch}
+\cite{crespo02semanticoverlay}
+Locality \cite{keleher-02-p2p}
+\cite{ng02predicting}
 
+\subsection{Fast and usable search}
+\cite{yang02improvingsearch}
+\cite{kronfol02fasdsearch}
+\cite{harren02complex}
+\cite{joseph02p2players}
 Bloom filters \cite{362692}
-
+\cite{andrzejak02rangequeries}
+\cite{li03feasibility}
 \cite{CuencaAcuna2002DSIWorkshop}
+\cite{Bhattacharjee03resultcache}
+\cite{chord:om_p-meng}
 
-Locality \cite{keleher-02-p2p}
-
+\subsection{System management}
+\cite{sloppy:iptps03}
+\cite{libennowell01observations}
+\cite{karger02findingnearest}
+\cite{rao03loadbalancing}
+\cite{zhang03somo}
+\cite{bhagwan03availability}
+\cite{zhao02brocade}
 Practical Byzantine fault tolerance \cite{296824}
 Byzantine Generals \cite{357176}
 
-\cite{castro02networkproximity}
-
-\cite{yang02efficientsearch}
-
 %dup
 \cite{liben-nowell02observatorionsp2p}
 \cite{571863}
 
 \cite{ledlie02selfp2p}
 
-\cite{andrzejak02rangequeries}
-
-\cite{hearn02mojonation}
-
-\cite{osokine02distnetworks}
-
-\cite{harvey03skipnet1}
-
-\cite{ng02predicting}
-
-\cite{chord:om_p-meng}
-
-
 \section{Miscellaneous problems in Peer-to-Peer}
 
-Research on *usage patterns* haven't been done. However, there have been some 
research
-focusing on file popularity in in www and p2p networks: file popularity 
follows the zipf/harmonical distribution)
+\subsection{Frameworks}
 
-\cite{kronfol02fasdsearch}
+\cite{zhao03api}
+\cite{frise02p2pframework}
+\cite{babaoglu02anthill}
+\cite{rhea03benchmarks}
 
+\subsection{Social behaviour}
+\cite{cornelli02reputableservents}
 \cite{oram01harnessingpower}
-
-\cite{krishnamurthy01earlymeasurements}
-
 \cite{golle01incentivesp2p}
+\cite{hearn02mojonation}
 
-\cite{cornelli02reputableservents}
-
+\subsection{Usage patterns}
 \cite{saroiu02measurementstudyp2p}
+\cite{krishnamurthy01earlymeasurements}
 
-\cite{rhea03benchmarks}
-
-\cite{zhao03api}
-
-\cite{frise02p2pframework}
-
-\cite{babaoglu02anthill}
-
+Research on *usage patterns* haven't been done. However, there have been some 
research
+focusing on file popularity in in www and p2p networks: file popularity 
follows the zipf/harmonical distribution)
 
 
 \section{Summary}
@@ -1308,6 +1280,25 @@
 \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)}
 \\ \hline
 
+\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
+               
 
 \end{longtable}
 \normalsize
@@ -1338,26 +1329,6 @@
 \endfoot
 
 
-\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
-
-
 \parbox{90pt}{Mutual distrust} &
 \parbox{110pt}{Nobody trusts anybody} &
 \parbox{110pt}{Reputation methods, key infrastructures} &
@@ -1465,7 +1436,7 @@
 
 \cite{lukka02freenetguids}
 
-\subsection{Block storage}
+\subsection{Storm block storage}
 
 \cite{benja02urn5}
 \cite{balakrishnan03semanticfree}
@@ -1487,7 +1458,7 @@
 -uses SHA-1 for checking data integrity (suits for us very well!)
 -we don't have to create 'mini-blocks' for Gzz p2p, since bitTorrent itself 
partitions data into several blocks for us
 
-\section{Motivation}
+\section{Overview}
 
 -need to make Gzz distributed system
 
@@ -1536,27 +1507,6 @@
 return the most recent block, if the signing key and block's timestamp are 
"valid"."
 
 
-\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
-
 \section{Special needs}
 
 Gzz's requirements
@@ -1580,6 +1530,28 @@
 
 \cite{bittorrenturl}
 \cite{maymounkov03ratelesscodes}
+
+\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
+
 
 \section{Possible problems}