Updated Rapport & README
This commit is contained in:
parent
7f6f1938a6
commit
de00cca6c7
37
RAPPORT.md
37
RAPPORT.md
@ -1,12 +1,10 @@
|
||||
# 大字报
|
||||
|
||||
> Le Maoïsme du XXIème siècle
|
||||
> Un grand bon en avant pour le pair à pair du XXIème siècle
|
||||
|
||||
![Étudiants préparant le projet de réseau, 2020](header.jpg)
|
||||
|
||||
**_Étudiants préparant le projet de réseau, 2020_**
|
||||
|
||||
By 人民画报 - 《人民畫報》1967年, Public Domain, <a href="https://commons.wikimedia.org/w/index.php?curid=66356803">Link</a>
|
||||
**_Étudiants préparant le projet de réseau, 2020_** _By 人民画报 - 《人民畫報》1967年, Public Domain, <a href="https://commons.wikimedia.org/w/index.php?curid=66356803">Link</a>_
|
||||
|
||||
## Abstract
|
||||
|
||||
@ -18,7 +16,7 @@ L'utilisation se fait depuis un terminal, en ligne de commande.
|
||||
|
||||
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 protocole. La construction des TLV, la production d'un hash et les fonctions de gestion et d'affichage d'erreurs sont dans leurs propres fichiers, car ce sont des points qui peuvent être amenés à changer 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.
|
||||
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 de l'ordre de quelques secondes.
|
||||
|
||||
### Structure
|
||||
|
||||
@ -26,7 +24,7 @@ Le programme se découpe en 2 parties ; l'initialisation, puis la récupération
|
||||
|
||||
### 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 marquer 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.
|
||||
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. Pour chaque adresse IP, nous crééons un pair, que l'on va marquer comme permanent. Si plusieurs adresses IP sont données, mais qu'elles correspondent à un seul pair, nous n'en utilisons qu'une seule, pour évider les congestions et autres erreurs. 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.
|
||||
|
||||
@ -64,7 +62,7 @@ Après avoir traité tous les TLVs reçus, nous enverrons le paquet courrant, qu
|
||||
|
||||
#### Gestion et génération des hashes.
|
||||
|
||||
On utilise la librairie OpenSSL pour générer notre hash SHA256. Dans le cas de hash d'un seul noeud, on concatenne les données id, seqno et data (en faisant attention à convertir id et seqno en big endian) dans un même buffer et on le passe à la fonction de hashage.
|
||||
Nous utilisons la librairie OpenSSL pour générer notre hash SHA256. Dans le cas où nous ne générons que le hash d'un seul noeud, on concatenne les données id, seqno et data (en faisant attention à convertir id et seqno en big endian) dans un même buffer et on le passe à la fonction de hashage.
|
||||
|
||||
Dans le cas d'un network hash, on concatenera dans un grand buffer tous les hashes de chaque donnée connue (qui sont ajoutées peu à peu dans une liste chainée de façon à ce qu'elle soit en ordre croissant par rapport à l'id) puis nous passerons ce buffer à la fonction de hashage.
|
||||
|
||||
@ -74,11 +72,11 @@ On n'utilisera que les 16 premiers bytes de ces hashes.
|
||||
|
||||
### TLV
|
||||
|
||||
Les TLVs sont représentés par un type `union TLV`, qui contient des pointeurs vers le `struct` TLV en lui-même, différent pour chaque type de TLV.
|
||||
Les TLVs sont représentés par un type `union TLV`, qui contient des pointeurs vers le `struct` TLV en lui-même, différent pour chaque type de TLV. Afin de garder une facilité d'accès aux TLVs, ils sont tous définit avec comme premier champs, sont type, qui est de même taille pour tout TLV.
|
||||
|
||||
### poll()
|
||||
|
||||
L'utilisation de `poll()` nous permet de réagir à des évènements, et donc de ne pas avoir à attendre inutilement quand rien ne se passe. `poll()` va attendre 10ms sur chaque descripteur de fichier, en bloquant le reste du programme. Si nous recevons un message alors que nous n'observons pas le socket, rien de grave ne se passe ; on attendra un autre message.
|
||||
L'utilisation de `poll()` nous permet de réagir à des évènements, et donc de ne pas avoir à attendre inutilement quand rien ne se passe. `poll()` va attendre 10ms sur chaque descripteur de fichier, en bloquant le reste du programme. Si nous recevons un message alors que nous n'observons pas le socket, rien de grave ne se passe ; on attendra un autre message. De plus, il y a déjà un buffer interne au système.
|
||||
|
||||
### Envoie des paquets avec sendmsg
|
||||
|
||||
@ -92,10 +90,6 @@ Puis, entre 1 et 9, des message de débug avec plus ou moins de détails sont af
|
||||
|
||||
Une attention particulière est porté sur la gestion des erreurs. En effet, notre pair va essayer au maximum de continuer à vivre malgré les bugs possible. Vu qu'il est possible de recevoir tout type de message, nous préférons afficher un message d'erreur ou de débug plutôt que d'arrêter l'éxécution. À noter que le fait de ne pas avoir de pair au début n'est pas une erreure fatale, car il se peut qu'un autre pair communique avec nous, sans que nous ne le connaissions au préalable.
|
||||
|
||||
## Spécificités
|
||||
|
||||
?
|
||||
|
||||
## Extensions
|
||||
|
||||
Nous avons implémenter l'aggrégation de TLV dans un paquet.
|
||||
@ -104,23 +98,16 @@ Nous vérifions la cohérence des _Node State_ ; si on reçoit un node state, on
|
||||
|
||||
Si notre pair as plusieurs adresses, nous communiquons sur toutes les adresses qu'il possède.
|
||||
|
||||
## Tests
|
||||
|
||||
Nous avons réalisé de nombreux test, y compris avec d'autres pairs, écrit par des camarades. Cela nous as permis de renforcer la robustesse de notre programme.
|
||||
|
||||
## Commentaire
|
||||
Nous nous ajoutions mutuellement comme pair par défault, ou alor nous formions une "chaîne", où l'on ajoute son voisin, et il ajoute un autre voisin.
|
||||
|
||||
Ce que l'on as pensé du projet, les éventuelles difficultés ?
|
||||
Nous avons aussi essayé de faire du renvoi de paquet depuis WireShark, afin de tester la réaction de notre pair à la réception de plusieurs paquets identiques, ou de messages tronqués, corrompu, ou malveillant...
|
||||
|
||||
## Conclusion
|
||||
|
||||
?
|
||||
Toutefois, la licence AGPL s'applique toujours ; aucune garantie n'est possible...
|
||||
|
||||
---
|
||||
|
||||
[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.
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
Comment est organisé le code ? Diagram UML ? Dépendances ?
|
||||
|
@ -25,6 +25,14 @@ _Ce logiciel est développé pour GNU/Linux, et n'a pas de support à l'heure ac
|
||||
|
||||
Si vous connaissez l'adresse d'un pair, vous pouvez éxecuter le programme avec la commande `./dazibao <root peer> <port>`, en remplacement `<root peer>` par l'URL où votre pair est disponible, et `<port>` par le port où le pair écoute.
|
||||
|
||||
Si vous voulez changer le niveau d'affichage, vous pouvez changer la valeur de la variable `DEBUG_LEVEL`, puis refaire la commande `make`.
|
||||
|
||||
Lorsque le niveau est >1, vous êtes en mode débug, et en appuyant sur **P** puis **Entrée**, vous pouvez afficher la liste des pairs connus.
|
||||
|
||||
En appuyant juste sur **Entrée** sans rien d'autre, vous pouvez afficher la liste des messages connus, classé par ID du pair.
|
||||
|
||||
Vous pouvez aussi lancer votre pair avec la commande `./dazibao <root peer> <port> >> dazibao.log`. Ainsi, vous aurez l'affichage de Dazibao dans le fichier susnommé, que vous pouvez lire avec `tail -f`, dans une autre fenêtre de terminal. De fait, cela rend l'écriture de nouveaux messages beaucoup plus simple.
|
||||
|
||||
## Contribution
|
||||
|
||||
Sentez vous libre de copier le code, le modifier et de nous renvoyer vos modifications tout en les décrivant avec le plus de détail possible. Vous pouvez ouvrir un _merge request_ depuis la page web du projet.
|
||||
|
Loading…
Reference in New Issue
Block a user