% 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}