Update
This commit is contained in:
parent
4173686895
commit
e02957996c
49
RAPPORT.md
49
RAPPORT.md
@ -10,15 +10,54 @@ By 人民画报 - 《人民畫報》1967年, Public Domain, <a href="https://com
|
||||
|
||||
## Abstract
|
||||
|
||||
Qu'es ce que notre programme fait ?
|
||||
Dazi bao est l'implémentation d'un protocol de commérage, qui permet de publier un message, ce dernier est envoyé de proche en proche à chaque pair du réseau.
|
||||
|
||||
## Structure du programme
|
||||
L'utilisation se fait depuis un terminal, en ligne de commande.
|
||||
|
||||
## Structure et déroulement
|
||||
|
||||
Le programme est structuré autour du fichier `node.c`, dans lequel se trouve la fonction main. Cette fonction va se charger d'appeler les fonctions d'initialisation, et de lancer le protocol. La construction des TLV, la production d'un hash et les fonctions de gestion et d'affichage d'erreurs sont dans leurs propre fichier, car ce sont des points qui peuvent être amené à changé lors de l'implémentation d'extensions.
|
||||
|
||||
Le noeud n'a pas de mémoire, et va donc être intialisé à partir de 0 à chaque lancement. Entre le lancement, et le moment où l'on connaît l'ensemble des messages publiés ( avec le site web comme référence, bien que ça ne soit pas forcément valide), le temps de convergance est en dessous d'une seconde.
|
||||
|
||||
### Structure
|
||||
|
||||
Le programme se découpe en 2 parties ; l'initialisation, puis la récupération et publication des messages.
|
||||
|
||||
### Initialisation
|
||||
|
||||
Lorsque l'on éxécute le programme, on donne une URL ainsi qu'un numéro de port. Cette URL va être décodée par `getaddrinfo`, qui va nous donner >1 adresses IP, qui peuvent être en format IPv4 ou IPv6. Pour chaque adresse IP, nous crééons un pair, que l'on va marqué comme permanent. On y associe le numéro de port donné lors du lancement. Nous crééons aussi le socket que l'on utilisera ensuite. Nous le fixons sur le port 1212.
|
||||
|
||||
Par soucis de simplicité, et dans l'espoir que IPv4 disparaisse rapidement des internet, nous traitons tout les pairs comme étant en IPv6. Les adresses IPv4 sont _IPv6 mapped_. Une fois le programme lancé, on ne peux plus ajouter de pair permanent, ni les supprimer. On pourrait étendre le programme en permettant d'ajouter les pairs de façon dynamique, en les ajoutant ou supprimant. On pourrait aussi choisir de "bloquer" un pair, mais cela reste impossible en l'étant, voir la note 1.
|
||||
|
||||
Nous initialisations aussi la liste des messages, en créeant un permier message, vide. Il est vide, pour plusieurs raisons : d'une part, lorsque l'on lance le programme, on peux ne pas avoir envie de publier quoique ce soit, et de juste recevoir les messages. On peux aussi avoir envie d'effacer les messages publiés précédement. Lors de la publication de notre message, il remplacera les messages précédents connu des pairs par une phrase vide, ce qui effacera le message. À noter que, vu qu'il n'existe pas, dans le protocol de base, d'authentification, ça peux aussi être un moyen d'effacer tout les messages du réseau.¹
|
||||
|
||||
La liste de pair et la liste de messages sont des listes chainés simple. Elles sont suffisante, car permettent l'ajout et la suppression. Lors de l'envoie de messages, nous devons parcourir toute la liste des pairs, et lors de la réception ou l'inondation de message, nous devons aussi passer en revue tout les messages.
|
||||
|
||||
Une extension possible serait de stocker le hash de chaque message, afin d'avoir une hash map. On pourrait donc vérifier uniquement le hash, sans avoir besoin de le recalculer. Cela réduirait aussi fortement le temps de mise à jour et d'accès aux messages.
|
||||
|
||||
### Déroulement
|
||||
|
||||
Le noeud va ensuite initiliser une structure `pollfd`, un variable de délais, ainsi que deux tableau de char. Ces derniers font 1024 bytes, ce qui est recommandé dans le projet. C'est suffisant, car un paquet ne peux pas faire plus de 1024 bytes, et nous traitons les paquets les uns à la suite des autres. La structure `pollfd` va servir lors de l'appel à la fonction `poll`, qui se charge de surveiller deux descripteurs de fichiers : `stdin`, et le socket définit lors de l'initialisation. Quand des données sont écrites dans ces fichiers, nous effectuons une lecture.
|
||||
|
||||
La lecture de stdin premet de récupérer à la fois des commandes pour la gestion du noeud, ainsi que le message à publier. La lecture du socket nous permet de récupérer les paquets entrant.
|
||||
|
||||
La variable de délais est utilisé pour mettre à jour la liste de pair, demander plus de pair le cas échéant, et demander l'état du réseau aux autres pairs. Nous l'initialisation à une valeur inférieure à 20 secondes, car lors du lancement, nous ne connaissons rien du réseau. Pas la peine d'attendre. Une fois la première éxécution passée, nous mettons un délais de vingt à trentes secondes. C'est suffisant, car la publication de nouveaux messages sur le réseau est assez lente. Nous pourrions faire évoluer ce délais en fonction du rythme de publication de nouveaux messages.
|
||||
|
||||
#### Ajouts de nouveaux messages
|
||||
|
||||
L'ajout de nouveaux messages est fait uniquement si on écrit un message non-vide. Dans le cas contraire, on affiche les messages connus.
|
||||
|
||||
|
||||
#### Réception des paquets et traitement
|
||||
|
||||
Comment est organiser le code ? Diagram UML ? Dépendances ?
|
||||
|
||||
## Choix d'implémentation
|
||||
|
||||
Comment on implémente les TLV ? Utilisation de poll() ? Envoie des paquets UDP avec sendmsg ?
|
||||
Comment on implémente les TLV ? Utilisation de poll() ? Envoie des paquets UDP avec sendmsg ? Gestion des erreur.
|
||||
|
||||
Temps de convergance : < 1s
|
||||
|
||||
## Spécificités
|
||||
|
||||
@ -35,3 +74,7 @@ Ce que l'on as pensé du projet, les éventuelles difficultés ?
|
||||
## Conclusion
|
||||
|
||||
?
|
||||
|
||||
---
|
||||
|
||||
[1] Pour cela, il suffit de publier un message vide, tout en se donnant comme numéro d'identification ceux que l'on connait, venant d'autres pairs.
|
||||
|
Loading…
Reference in New Issue
Block a user