summaryrefslogtreecommitdiffstats
path: root/stage/article.tex
diff options
context:
space:
mode:
authorthibauth <thibauth@30fcff6e-8de6-41c7-acce-77ff6d1dd07b>2011-08-09 12:14:25 +0000
committerthibauth <thibauth@30fcff6e-8de6-41c7-acce-77ff6d1dd07b>2011-08-09 12:14:25 +0000
commit92513ed6b32c9b8e519a5352c17fa0f51c573d75 (patch)
tree3fd5d2f772987dcd3a90e288b67e7384285eb9c1 /stage/article.tex
parentb6626f14635fc5ad36df9d05b64e03f44bb14ff4 (diff)
downloadpacemaker-92513ed6b32c9b8e519a5352c17fa0f51c573d75.tar.gz
Rapport : modèle
git-svn-id: https://scm.gforge.inria.fr/svn/pacemaker@57 30fcff6e-8de6-41c7-acce-77ff6d1dd07b
Diffstat (limited to 'stage/article.tex')
-rw-r--r--stage/article.tex23
1 files changed, 13 insertions, 10 deletions
diff --git a/stage/article.tex b/stage/article.tex
index f11d190..3260bd9 100644
--- a/stage/article.tex
+++ b/stage/article.tex
@@ -17,7 +17,7 @@ basicstyle=\small, keywordstyle=\bfseries, captionpos=b}
\newtheorem*{rem}{Remark}
\title{Pacemaker : un protocole de mesure de disponibilité dans les réseaux pair-à-pair}
-\date{Sujet proposé et supervisé par Fabrice Le Fessant}
+\date{Sujet proposé et encadré par Fabrice Le Fessant}
\begin{document}
\maketitle
@@ -61,28 +61,31 @@ La section 2. présente le modèle et les hypothèses sur lesquels repose Pacema
\subsection{Réseau}
+On considère un réseau pair-à-pair constitué d'ordinateurs reliés entre eux par un réseau de communication (par exemple Internet). On suppose qu'au-dessus de ce réseau se situe un réseau logique dans lequel chaque pair ne connaît qu'une partie d'une réseau : ce sont ses voisins\footnote{C'est le cas dans la majeure partie des protocoles pair-à-pair usuels comme par exemple Gnutella ou BitTorrent.}.
+Pacemaker repose également sur la présence de pairs particuliers : certains pairs ont un rôle distingué dans le réseau, on les appelle \emph{serveurs}. Pour que le protocole fonctionne, il est nécessaire que chaque pair soit dans la composante connexe d'au moins un serveur. Le protocole reste toutefois décentralisé au sens où il ne suppose pas que les serveurs possèdent des ressources physiques supérieures à celles des autres pairs.
+
+Pacemaker peut donc fonctionner comme un service au-dessus d'un protocole pair-à-pair déjà existant, mais il peut également être vu comme un protocole indéoendant qui construit et maintient son propre réseau. La section ... présente une méthode ad hoc pour la construction du réseau.
\subsection{Cryptographie}
-On suppose que chaque pair $p$ possède une pair de clé publique/privée \textsf{(K$^p_{pub}$, K$^p_{priv}$)} donnant accés aux primitives cryptographiques suivantes :
+On suppose que chaque pair $p$ possède une paire de clé publique/privée \textsf{(K$^p_{pub}$, K$^p_{priv}$)} donnant accés aux primitives cryptographiques suivantes :
\begin{itemize}
\item{\sf sign(data, K$_{priv}$) :} renvoie une signature pour \textsf{data} en utilisant la clé privée \textsf{K$_{priv}$}.
\item{\sf verify(S, data, K$_{pub}$) :} vérifie que \textsf{S} est une signature pour \textsf{data} créée avec la clé privée \textsf{K$_{priv}$} associée à la clé publique \textsf{K$_{pub}$}.
\item{\sf hash(data) :} renvoie un hash de \textsf{data}.
\end{itemize}
-On considére donc que les pairs connaissent toujours l'expéditeur des messages qu'ils recoivent, ceux-ci étant identifiés de façon unique par leur clé publique. Les attaques cryptographiques usuelles ne sont pas étudiées ici, et les primitives ci-dessus sont considérés comme sûres. De même. la fonction de hachage ci-dessus est considérée comme résistante aux attaques par collision (au moins sur la durée caractéristique d'utilisation du protocole).
+On considére donc que les pairs connaissent toujours l'expéditeur des messages qu'ils recoivent, ceux-ci étant identifiés de façon unique par leur clé publique. Les attaques cryptographiques usuelles ne sont pas étudiées ici, et les primitives ci-dessus sont considérés comme sûres. En particulier, la fonction de hachage ci-dessus est considérée comme résistante aux attaques par collision.
+
+\subsection{Notations}
-The key pair of the server will be denoted by \textsf{(KS$_{pub}$,
-KS$_{priv}$)}. \textsf{KS$_{pub}$} is assumed to be known by every peer.
+On suppose pour simplifier qu'il n'y a qu'un seul serveur, et que l'on n'étudie que la composante connexe de ce serveur. Cette hypothèse n'est pas restrictive car les serveurs ne communiquent pas entre eux. La paire de clé du serveur est notée \textsf{(KS$_{pub}$, KS$_{priv}$)}. On suppose de plus que \textsf{KS$_{pub}$} est connue par l'ensemble des pairs.
-Each peer $p$ knows the list of peers to whom he is connected, this list is denoted by $NS_p$.
-If $q\in NS_p$ then $p$ can send the message $m$ to $q$ using the function \textsf{send($q$, $m$)}.
+Chaque pair $p$ connaît l'ensemble des paris auxquels il est connecté, cet ensemble est noté $NS_p$. Si $q\in NS_p$ alors $p$ peut envoyer le message $m$ à $q$ en utilisant la fonction \textsf{send($q$, $m$)}.
-$\langle a|b|\ldots\rangle$ will be used to denote the serialisation
-(depending on the implemetation) of two or more pieces of data.
+Enfin $\langle a|b|\ldots\rangle$ représente la sérialisation des données $a$, $b$ (et plus) pour utilisation dans les fonctions primitives, notamment $\textsf{sign}$ et $\textsf{send}$.
-\subsection{Principle}
+\section{Protocole}
The protcol works in three phases: