diff options
| -rw-r--r-- | .gitignore | 2 | ||||
| -rw-r--r-- | a faire | 23 | ||||
| -rw-r--r-- | planetlab/Makefile | 6 | ||||
| -rw-r--r-- | stage/article.tex | 21 |
4 files changed, 52 insertions, 0 deletions
@@ -5,3 +5,5 @@ .depend build/ \#*\# +*.pyc +planetlab/data @@ -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} |