BE_reseau/README.md

# 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 ,