Update readme, start report
This commit is contained in:
parent
a31d9e29eb
commit
6d3774bc99
4 changed files with 147 additions and 5 deletions
|
@ -6,7 +6,7 @@ Projet de cours "réseau", M1 <https://tobast.fr/m1/nw-project.pdf>
|
|||
|
||||
* `g++` (version supportant c++14) ou tout autre compilateur c++ (éditer le
|
||||
Makefile pour changer `CXX`)
|
||||
* Bibliothèques standard POSIX
|
||||
* pthread
|
||||
|
||||
## Compiler
|
||||
|
||||
|
@ -23,13 +23,11 @@ arguments.
|
|||
* `bootstrap [ID du nœud] [adresse IPv6 du nœud] [port]` : déclare le nœud
|
||||
comme nœud de bootstrap. L'adresse peut être IPv4-mapped, eg.
|
||||
`::FFFF:42.42.42.42`.
|
||||
* `data [id de donnée] [donnée]` : déclare une donnée à propager. Si l'id est
|
||||
0, il sera tiré au hasard puis enregistré. La donnée peut contenir des
|
||||
* `data [donnée]` : déclare une donnée à propager. La donnée peut contenir des
|
||||
espaces, et s'étend jusqu'à la fin de la ligne.
|
||||
|
||||
Le programme, à l'initialisation, lit le fichier puis le réécrit avec
|
||||
éventuellement des données tirées au hasard si nécessaire (eg. ID du nœud, des
|
||||
données).
|
||||
éventuellement des données tirées au hasard si nécessaire (eg. ID du nœud).
|
||||
|
||||
Le programme produit des logs verbeux mais humainement lisibles sur sa sortie
|
||||
d'erreur (stderr).
|
||||
|
|
3
report/.gitignore
vendored
Normal file
3
report/.gitignore
vendored
Normal file
|
@ -0,0 +1,3 @@
|
|||
*.aux
|
||||
*.log
|
||||
*.pdf
|
6
report/Makefile
Normal file
6
report/Makefile
Normal file
|
@ -0,0 +1,6 @@
|
|||
TEX=report.tex
|
||||
all: $(TEX)
|
||||
pdflatex $(TEX)
|
||||
pdflatex $(TEX)
|
||||
|
||||
|
135
report/report.tex
Normal file
135
report/report.tex
Normal file
|
@ -0,0 +1,135 @@
|
|||
% vim: spelllang=fr
|
||||
|
||||
\documentclass[11pt,a4paper]{article}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage[francais]{babel} %% FRENCH, FIXME if typing in english
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage{amsmath}
|
||||
\usepackage{amsfonts}
|
||||
\usepackage{amssymb}
|
||||
\usepackage{graphicx}
|
||||
\usepackage[left=2cm,right=2cm,top=2cm,bottom=2cm]{geometry}
|
||||
|
||||
% Custom packages
|
||||
\usepackage{my_listings}
|
||||
\usepackage{math}
|
||||
|
||||
\author{Théophile \textsc{Bastian}}
|
||||
\title{Rapport~: projet réseau}
|
||||
\date{\today}
|
||||
|
||||
\begin{document}
|
||||
\maketitle
|
||||
|
||||
\begin{abstract}
|
||||
|
||||
L'implémentation du protocole en C++ respecte la spécification sur tous les
|
||||
cas observés. De plus, les paquets sont agrégés tant que possible pour
|
||||
éviter une surcharge du réseau, l'inondation est un peu optimisée et
|
||||
n'interrompt pas le reste du protocole et le programme affiche ses
|
||||
informations dans la console sur demande. Toutefois, il n'est pas possible
|
||||
de modifier dynamiquement les données propagées.
|
||||
|
||||
Le support de l'IPv4 et de l'IPv6 à la fois devrait être possible, mais n'a
|
||||
pas pu être testé.
|
||||
\end{abstract}
|
||||
|
||||
\section{Utilisation}
|
||||
|
||||
\subsection{Dépendances}
|
||||
Seuls un compilateur C++ supportant C++14 et la bibliothèque pthread sont
|
||||
nécessaires au fonctionnement du programme sur un environnement POSIX standard.
|
||||
|
||||
\subsection{Compilation}
|
||||
|
||||
\lstbash{make} suffit à compiler. Il est éventuellement possible d'utiliser un
|
||||
autre compilateur C++ en éditant le \texttt{Makefile}.
|
||||
|
||||
\subsection{Utilisation}
|
||||
|
||||
Le programme fourni prend en argument le chemin vers un fichier de
|
||||
configuration, dont chaque ligne commence par un mot-clé suivi de ses
|
||||
arguments.
|
||||
|
||||
\begin{itemize}
|
||||
|
||||
\item \lstbash{id [ID du programme]}~: laisser vide par défaut, sera généré
|
||||
automatiquement.
|
||||
|
||||
\item \lstbash{bootstrap [ID du nœud] [adresse IPv6 du nœud] [port]}~:
|
||||
déclare le nœud comme nœud de bootstrap. L'adresse peut être
|
||||
IPv4-mapped, eg. `::FFFF:42.42.42.42`.
|
||||
|
||||
\item \lstbash{data [donnée]}~: déclare une donnée à propager. La donnée
|
||||
peut contenir des espaces, et s'étend jusqu'à la fin de la ligne.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
Le programme, à l'initialisation, lit le fichier puis le réécrit avec
|
||||
éventuellement des données tirées au hasard si nécessaire (eg. ID du nœud).
|
||||
|
||||
\subsection{Entrée/sortie}
|
||||
|
||||
Le programme produit des logs verbeux mais humainement lisibles sur sa sortie
|
||||
d'erreur (stderr).
|
||||
|
||||
Le programme affiche son état actuel (voisins + infos sur eux, données + infos
|
||||
sur elles) lors d'un appui sur \textsc{return}.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{Implémentation}
|
||||
|
||||
Tout d'abord, mon code est très --- trop --- long pour le programme demandé.
|
||||
J'ai manqué de temps pour ce projet (beaucoup de choses à faire en parallèle)
|
||||
et j'ai donc plus produit du code rapidement qu'intelligemment\ldots
|
||||
|
||||
\subsection{Threads}
|
||||
Le programme contient deux threads~:
|
||||
\begin{itemize}
|
||||
\item thread principal, gérant la plupart des choses~;
|
||||
\item thread de lecture des paquets, réceptionnant les paquets et les
|
||||
stockant dans une file pour que le thread principal puisse les
|
||||
analyser.
|
||||
\end{itemize}
|
||||
|
||||
Des mutexes sont utilisées quand nécessaire (accès à la file, en particulier).
|
||||
|
||||
\subsection{Lecture de l'entrée standard}
|
||||
|
||||
Pour éviter d'être bloquant sur la lecture de l'entrée standard, j'utilise dans
|
||||
\texttt{main.cpp} \lstc{select} pour mettre un timeout d'une seconde sur
|
||||
\lstc{getchar}. Ceci remplace \lstc{sleep} dans la boucle principale.
|
||||
|
||||
\subsection{Agrégation des paquets}
|
||||
|
||||
L'idée suggérée est implémentée~: la fonction \lstcpp{Protocol::sendBody}
|
||||
agrège les TLVs qu'on lui donne dans une map de paquets (sans headers, \ie{}
|
||||
une suite de TLVs), mappant les IDs de nœuds sur leur paquet en cours d'envoi.
|
||||
Lorsqu'elle souhaite agréger plus d'un MTU~$- 12$ dans un paquet (\ie{}
|
||||
MTU~$-$~taille des headers), le paquet dans la map est envoyé, vidé, puis on
|
||||
agrèg le TLV qu'on souhaitait insérer.
|
||||
|
||||
À la fin de chaque itération de la boucle principale, tous les paquets en cours
|
||||
sont envoyés, garantissant ainsi un délai inférieur à une seconde ---
|
||||
acceptable compte-tenu des délais prévus dans le protocole.
|
||||
|
||||
\subsection{Amélioration de l'inondation}
|
||||
|
||||
Lorsqu'un premier IHU est reçu d'un pair, on inonde immédiatement la
|
||||
donnée.
|
||||
|
||||
\subsection{Inondation non-bloquante}
|
||||
|
||||
L'objet \lstcpp{DataStore} décide périodiquement de republier ses données. Dans
|
||||
ce cas, il met à jour la donnée stockée, puis met à jour un champ demandant la
|
||||
propagation d'une certaine donnée. Ce champ est récupéré régulièrement par
|
||||
l'objet \lstcpp{Neighbours}, pouvant lui aussi décider d'inonder une donnée
|
||||
vers \emph{un} pair lorsque celui-ci envoie son premier IHU\@.
|
||||
|
||||
Lorsque \lstcpp{Neighbours} reçoit, d'une manière ou d'une autre, une requête
|
||||
d'inondation, il crée un objet \lstcpp{Flooder} pour l'ID de la donnée à
|
||||
inonder initialisé avec la liste des voisins vers qui on souhaite inonder.
|
||||
Régulièrement, \lstcpp{Flooder::update} est appelé, et se charge d'inonder
|
||||
plusieurs fois la donnée vers chaque pair de l'ayant pas encore acquittée.
|
||||
|
||||
\end{document}
|
Loading…
Reference in a new issue