diff options
| author | thibauth <thibauth@30fcff6e-8de6-41c7-acce-77ff6d1dd07b> | 2011-08-09 16:42:40 +0000 |
|---|---|---|
| committer | thibauth <thibauth@30fcff6e-8de6-41c7-acce-77ff6d1dd07b> | 2011-08-09 16:42:40 +0000 |
| commit | 7280c15ffbd67af31cd0045964c491862b5b5ad1 (patch) | |
| tree | 9c5bcf2e90579aacbf2123b8b223b0e504a80b69 | |
| parent | 92513ed6b32c9b8e519a5352c17fa0f51c573d75 (diff) | |
| download | pacemaker-7280c15ffbd67af31cd0045964c491862b5b5ad1.tar.gz | |
Rapport : protocole
git-svn-id: https://scm.gforge.inria.fr/svn/pacemaker@58 30fcff6e-8de6-41c7-acce-77ff6d1dd07b
| -rw-r--r-- | stage/article.tex | 40 |
1 files changed, 34 insertions, 6 deletions
diff --git a/stage/article.tex b/stage/article.tex index 3260bd9..da54353 100644 --- a/stage/article.tex +++ b/stage/article.tex @@ -31,12 +31,13 @@ C'est pourquoi de nombreux protocoles de réseaux pair-à-pair s'appuient sur la \item assurer une plus grande justice dans la répartition d'un service : faire en sorte que les gens qui ont la plus grande disponibilité aient plus d'avantages sur le réseau. \end{itemize} -Malheureusement, la plupart de ces stratégies supposent donné un oracle qui fournirait cette information de disponibilité. Plusieurs approches permettent d'obtenir cet orcale : +Malheureusement, la plupart de ces stratégies supposent donné un oracle qui fournirait cette information de disponibilité. Plusieurs approches permettent d'obtenir cet oracle : \begin{itemize} \item de façon individuelle : chaque nœud est en charge de surveiller et de stocker sa propre disponibilité \item l'évaluation par les pairs : à chaque nœud est associé un ensemble de pairs chargés de surveiller sa disponibilité \item de façon centralisée : un nœud s'occupant de surveiller le réseau et de stocker la disponibilité de l'ensemble des nœuds du réseau \end{itemize} + Chacune de ces approches présente une limite manifeste : \begin{itemize} \item l'approche individuelle autorise les nœuds à mentir sur leur propre disponibilité, pour obtenir par exemple plus d'avantages sur le réseau. Ceci met donc en défaut une des principales utilisation de l'information de disponibilité. @@ -55,6 +56,8 @@ Le but du présent rapport est donc de présenter et d'étudier le protocole \em \item \textbf{durabilité temporelle :} l'historique de disponibilité d'un nœud doit être préservé dans le temps \end{itemize} +Le protocole Pacemaker réalise un compromis entre l'approche individuelle et l'approche centralisée présentée ci-dessus : chaque pair présent dans le réseau reçoit à intervalle régulier une preuve de sa présence calculée par l'ensemble du réseau, celle-ci est stockée par le pair lui-même pour être présentée au besoin à la demande des autres pairs. Cette approche résout donc naturellement le problème de \textbf{durabilité temporelle} : l'information est disponible aussi longtemps qu'elle est utile, c'est à dire, aussi longtemps que le pair est présent sur le réseau. De plus, cette approche conserve la simplicité de l'approche individuelle en évitant la communication avec des tiers pour obtenir l'information de disponibilité. + La section 2. présente le modèle et les hypothèses sur lesquels repose Pacemaker, la section 3. contient la spéficiation complète du protocole, les sections suivantes s'attachent à l'analyse théorique et expérimentale du protocole, à travers une simulation et un déploiement sur PlanetLab\footnote{PlanetLab est un réseau constitués d'ordinateurs fournis par diverses entreprises et universités à travers le monde et mis à la disposition de l'ensemble des membres du réseau.}. \section{Modèle et notations} @@ -87,9 +90,18 @@ Enfin $\langle a|b|\ldots\rangle$ représente la sérialisation des données $a$ \section{Protocole} -The protcol works in three phases: +L'idée génerale du protocole est de générer un secret à un instant donné et de le diffuser sur le réseau. La possession de ce secret assure dans une certaine mesure la présence sur le réseau au moment où celui-ci a été diffusé. Dans cette version primitive, le protocole n'assure aucune protection contre la collusion ou la falsification : un pair pourrait révéler le secret à un autre pair qui n'était pas présent au moment de la diffusion. -\subsubsection*{Phase 1: Seeding} +La solution consiste à calculer à un instant donné une empreinte de la connaissance du secret par l'ensemble des pairs du réseau. Le protocole procède en trois phases : +\begin{itemize} +\item \textbf{Semaille :} Le serveur génére une graine aléatoire et la diffuse dans le réseau. +\item \textbf{Signature et hachage :} Chaque client signe la graine avec sa clé privée et calcule un hash de la signature. Il collecte ensuite les hashs de ses voisins auxquels il ajoute son propre hash. Le résultat est alors envoyé à ses parents. Le serveur calcule un hash racine de l'ensemble des hashs reçus de la part de ses fils. +\item \textbf{Pulsation :} Le serveur signe le hash calculé à la fin de la phase précédente avec sa clé privée et le diffuse dans le réseau avec la liste des hashs qui ont servi au calcul du hash racine. Au cours de la diffusion, les pairs ajoutent à la pulsation la liste des hashs qui ont servi au calcul du hash transmis à ses parents pendant la phase précédente. +\end{itemize} + +On obtient ainsi un arbe de hashage (cf. Merkel, De mare). + +\subsection{Semaille} The server generates a unique seed and initiates a seed pulse which is diffused through the network. Upon receiving the seed, @@ -106,7 +118,7 @@ pulse during this phase, where: \textsf{sign($\langle$$i$|seed$^i$|$T^i\rangle$, KS$_{priv}$)}. \end{itemize} -\subsubsection*{Phase 2: Hashing} +\subsection{Signature et hachage} Each peer starts collecting the tokens of his neighbors and adds his own token to the collected hashes, obtaining a @@ -118,7 +130,7 @@ server itself hashes the tokens of its children. where \textsf{H$_p$} is the token sent by peer $p$, that is, the hash of the collected map of the tokens received by peer $p$. -\subsubsection*{Phase 3: Pulse} +\subsubsection{Pulsation} The server initiates a new pulse with the map it has collected from its childrens. Upon receiving the pulse, each peer adds to the @@ -274,8 +286,9 @@ $q$}] end if \end{lstlisting} -\section{Analysis} +\section{Analyse} +\subsection{Non falsifiabilité} The first problem to be adressed is the guarantee given by a proof provided by a peer in Spec. \ref{lst-proof}. @@ -339,4 +352,19 @@ protocol at all. For example he could have just received see$^i$ from a colluding peer $q$, computed and sent back S$^i_{p}$ to $q$ who would have inserted S$^i_{p}$ in the branch himself. \end{rem} + +\subsection{Détection des pairs menteurs} + +\section{Simulation} + +\subsection{Modélisation de la disponibilité des pairs} + +\subsection{Construction du réseau} + +\subsection{Résultats} + +\section{Implémentation} + +\section{Conclusion, application à la signature de documents} + \end{document}
\ No newline at end of file |
