Repository cleaning, makefile for planetlab, some changes to the article

git-svn-id: https://scm.gforge.inria.fr/svn/pacemaker@55 30fcff6e-8de6-41c7-acce-77ff6d1dd07b

4 files changed, 52 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index 4cbbde0..5768261 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,5 @@
 .depend
 build/
 \#*\#
+*.pyc
+planetlab/data
diff --git a/a faire b/a faire
new file mode 100644
index 0000000..60ba1d7
--- /dev/null
+++ b/a faire
@@ -0,0 +1,23 @@
+* article AVMON : regarder les references (en particulier:
+  *	8 : Gossip-based overlay topology management 
+  * 6 : Peer to peer membership management
+  * 9 : exploiting availability prediction
+  * 14 : Availability in global peer to peer storage systems
+  * 15
+
+* simulateur : vérifier les points sur le brouillon (en particulier les bugs
+corrigés dans l'implémentation réelle.
+
+* sur planetlab : trouver une façon rapide de rappatrier les logs
+
+* self-init dans le client (ou s'assurer que les identifiants sont uniques)
+
+* à vérifier pour la biblio :
+  * tamper-evident history/log
+  * distributed merkle tree
+  * broadcast timestamp
+  * broadcast protocol
+  * gossip-based protocol
+  * distributed decentralized authentification
+  * content authentification
+
diff --git a/planetlab/Makefile b/planetlab/Makefile
new file mode 100644
index 0000000..648868c
--- /dev/null
+++ b/planetlab/Makefile
@@ -0,0 +1,6 @@
+status:
+	pssh/bin/pssh -h ple.txt -O StrictHostKeyChecking=no -P -l irisaple_pacemaker2 "arch" | grep  SUCCESS | awk '{print $$4}' | sort > alive.txt
+	pssh/bin/pssh -h ple.txt -O StrictHostKeyChecking=no -P -l irisaple_pacemaker2 "pgrep client" | grep -v -E "(FAILURE|SUCCESS)" | awk '{print $$1}' | sort > running.txt
+
+import:
+	pssh/bin/pslurp -h ple.txt -O StrictHostKeyChecking=no -l irisaple_pacemaker2 -r -L data /home/irisaple_pacemaker2/client/log ./
\ No newline at end of file
diff --git a/stage/article.tex b/stage/article.tex
index c6cc713..cb6fb18 100644
--- a/stage/article.tex
+++ b/stage/article.tex
@@ -1,6 +1,7 @@
 \documentclass[a4paper,10pt]{article}
 \usepackage[T1]{fontenc}
 \usepackage[utf8]{inputenc}
+\usepackage[french]{babel}
 
 \usepackage{listings}
 \lstdefinelanguage{pseudo}
@@ -21,6 +22,26 @@ basicstyle=\small, keywordstyle=\bfseries, captionpos=b}
 
 \maketitle
 
+\section{Introduction}
+Tous les réseaux pair-à-pair ont en commun d'avoir un dynamique complexe : naissances, morts, arrivées, départs, indisponibilité temporaires peuvent survenir à tout instant. Ainsi, la \emph{disponibilité} d'un noeud est une caractérisitique importante pour déterminer l'impact d'un nœud sur le réseau. La \emph{disponibilité} d'un nœud est définie comme étant la fraction du temps passée par le nœud sur le réseau.
+
+C'est pourquoi de nombreux protocoles de réseaux pair-à-pair s'appuient sur la disponibilité des nœuds. Deux utilisations différentes de cette information sont à distinguer:
+\begin{itemize}
+\item la structuration du réseau, ou bien par l'élection de super-peer (cf. ...) ou dans la sélection des voisins (cf. backup)
+\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 s'appuyant sur la disponibilité s'appuient sur un oracle qui leur fournirait cette information. Il existe deux approches fondamentalement opposées pour construire un tel oracle
+\begin{itemize}
+\item de façon centralisée
+\item peer-review
+\end{itemize}
+Chacune de ces deux approches présente un défaut, 
+
+
+
+\section{Model}
+
 \section{Protocol}
 
 \subsection{Assumptions and notations}