49 lines
3.5 KiB
Markdown
49 lines
3.5 KiB
Markdown
# BE RESEAU
|
||
## TPs BE Reseau - 3 MIC Aittaleb Mohamed Barnavon Jules-iana
|
||
|
||
|
||
## Contenu du dépôqui vous interesse
|
||
Ce dépôt inclunotre code source final pour mictcp
|
||
- README.md (ce fichier)
|
||
- tsock_texte et tsock_video : lanceurs pour les applications de test fournies.
|
||
- src/mictcp.c : code source que l'on a d<>veloppé
|
||
- configurer.sh : script shell qui vous demandera la version que vous voudrez utiliser et la tol<6F>rance aux pertes que vous souhaitez pour la v3 et au-delas
|
||
|
||
## Choir la version
|
||
La méthode pour choisir la version que nous recommandons est d'utiliser le script `configurer.sh`, assurez vous de le rendre ex<65>cutable par la commande :
|
||
`chmod +x configurer.sh`. Il ne fait que modifier une variable `version` qui controle la version dans `src/mictcp.c`.
|
||
|
||
Si non vous pouvez toujours remonter aux commits tagg<67>s avec le nom de la version que vous voulez.
|
||
|
||
## Compiler:
|
||
Si vous avez utiliséle script pour choisir la version, il n'est pas n<>cessaire de recompiler, si non veuillez ex<65>cuter `make`
|
||
|
||
## Notre avancement
|
||
Nous arrivéà d<>veloppéune version qui marche de la v4, (i.e fiabilit<69> partielle et <20>tablissement de la connexion.
|
||
|
||
## Bug observé
|
||
Avant d'ex<65>cuter tsock_text, assurez vous de ne pas avoir ex<65>cutétsock_video sur votre machine auparavant, nous avons observéque ceci faisait planter
|
||
notre application. La seule solution que l on a trouvéest de simplement reboot la machine.
|
||
|
||
## Choix remarquables
|
||
### Parametres de la fiabilite partielle
|
||
Pour implanter la fiabilite partielle, nous repris notre solution pour la fiabilite totale, et nous avons ajoute les elements suivants
|
||
Lorsque le client re<72>oit un acquitement, il ajoute un 1 au buffer circulaire de son socket et incr<63>ment le num<75>ro de s<>quence, si non, il calcule la proportion de 1 dans
|
||
ce buffer, et si elle est sup<75>rieure <20>au pourcentage de pertes tol<6F>r<EFBFBD>es, il ajoute un 0 au buffer, et retourne au client la taille envoy<6F>e
|
||
mais n incremente pas le numero d acquitement, si non, il renvoie le packet et attend toujours l'acquittement.
|
||
|
||
Afin de permettre l'implantation de cette fiabilite partielle, nous avons juggéque seul celui qui envoie les packets (ici le client) est en
|
||
position de controler cette fonctionalit<69>. De ce fait, il n'y pas de n<>gociation, simplement c est la source envoie, et qui controle le pourcentage de
|
||
pertes dans ce qu elle a envoy<6F>.
|
||
|
||
### La r<>alisation des IP_recv
|
||
Si vous vous penchez sur notre code source, vous verrez que l'on a fait usage de thread supl<70>mentaire alors que nous ne sommes pas all<6C>s jusqu'à la v4.2.
|
||
La raison de ceci est que nous avons rencontrédes bugs assez troublant concernant les IP_recv, ces derniers adoptent un comportement diff<66>rent d une execution a l'autre.
|
||
Nous avons alors d<>cidéde les traiter comme une source de perte en tant que tel, et nous les ex<65>cutons toujours dans un thread c<>tépuit. C<>tésource, vu que le
|
||
process_received_pdu est lancé dans un thread a part, cela n'a pas <20>tén<C3A9>cese.
|
||
|
||
### Etablissement de la connexion
|
||
Pour l'etablissement de la connexion, notre protocole effectue les op<6F>rations suivantes :
|
||
|
||
Lorsque le client c<>tésource<63> fat un mic_tcp_connect, l'applicatio fixe le numero de sequence associe a son socket a 0, puis envoie un pdu syn a ce meme numero de sequence 0.
|
||
A sa reception cote puit, la fonction process_receive_pdu l'applicatio fixe aussi son numero de sequence associe a son socket a 0, envoie un pdu syn ack ce numero de sequence ,
|