136 lines
4.9 KiB
TeX
136 lines
4.9 KiB
TeX
|
% 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}
|