Configuration du point d'accès

vue que hostapd pose des problèmes avec la carte wifi intel, nous avons eu recours à l'utilisation du
routeur wifi livré par notre fournisseur d'accès à internet. De plus nous avons utilisé la
configuration par défaut de ce dernier qui est en mode WPA2 personnel qui se repose sur des
protocoles d'authentification et un algorithme de cryptage robuste : AES.
A noter que:
@ ip du point d'accès=192.168.2.1
@ip du serveur=192.168.2.100
@ip du client=192.168.2.101

Diffusion des vidéos

Il existe principalement trois moyens fiables pour streamer une ressource sur le réseau : http, udp et
rtp.

Diffusion par http

Diffusion à travers le serveur apache:

diffusion de la vidéo coté serveur

afin de réaliser cette étape la vidéo qu'on désire diffuser doit être placée dans le répertoire var/www
A noter que
nom de la vidéo = documentaire.mpg

réception du flux coté client

pour pouvoir visualiser la vidéo en streaming, le client concerné doit préalablement installer le
logiciel VLC. Ainsi il lance la commande suivante:

vlc http://192.168.2.100/documentaire.avi
cette commande permet de recevoir le flux vidéo à travers le serveur en indiquant le nom de
la vidéo à transmettre.

Et pour tracer la courbe de débit en fonction du temps, un fichier de données(.dat) doit être mit en
place. Ce fichier doit être présenter sous la forme d'un tableau à 2 colonnes, dont la premier contient
le temps et la deuxième contient le débit. Et pour y créer on utilise la commande suivante:

tcpstat -i wlan0 -o "%S\t%b\n" 0.7>capture.dat

0.7 représente la largeur de l'intervalle à considérer pour calculer le débit à un instant t.

Capture avec wireshark

 On constate de cette capture qu'il y a alternance entre des paquets tcp et http(transmettant le
flux ) et que les paquets http sont toujours émis par le serveur apache. De plus on remarque des
transferts des paquets tcp particulières qui portent comme information « TCP window update ». ces
paquets indiquent combien d'octets de données que l'hôte(vlc) peut recevoir avant qu'il ne soit
complète. Ainsi L'expéditeur(serveur apache) n'est pas censé envoyer plus que cette quantité de
données.

Courbe du débit en fonction du temps

pour dessiner la courbe on lance la sous commande de gnuplot suivante:
plot 'capture.dat' using 1:2 title "capture apache" with lines
 Sur ce graphe on remarque que la pente de débit au démarrage de streaming est très
accentuée. Alors qu'après un certain temps on remarque chute brutale du débit. ce phénomène est
explique par le surcharge des paquet au niveau du point d'accès et la fiabilité (pas de pertes,
corruption ou duplication d'information) et livraison ordonnée du protocole tcp.
Appréciations:
avec cette méthode, le client a la possibilité de parcourir les différentes portion de la vidéo à sa
guise .

Diffusion à travers vlc :

diffusion de la vidéo coté serveur :

On diffuse la vidéo à travers vlc en mode http via la commande:

vlc /var/www/documentaire.mpg –sout '#standard{access=http,mux=ogg,dst=192.168.2.100:1234}'

•/var/www/documentaire.mpg : c'est le fichier que l’on souhaite diffuser

•--sout permet d’activer la diffusion
•standard permet d’envoyer un flux via un module de sortie (par exemple UDP, http, etc.)
•access permet de définir le module de sortie (ici HTTP)
•mux nous permet de définir la méthode d'encapsulation du flux:
ogg : C'est un muxer qui peut être utilisé avec les méthodes de sortie(access) file et http. Les
codecs supportés par ce muxer sont MEPG 1/2/4, MJPEG, WMV 1/2 ...
•dst:@ip du serveur + numéro de port

réception du flux coté client :

Le client execute la commande suivante:
vlc http://192.168.2.100:1234

De même que la méthode précédente pour la création du fichier de données par

l'intermédiaire de la commande tcpstat

Capture avec wireshark :

 Comme l'exemple précédent on remarque le transfert des paquets tcp particulières(« TCP
window update »).mais dans cette exemple on remarque que tous les paquets transférés sont des
paquets tcp. ainsi on constate que les données échangées sont en-capsulées dans des paquets tcp.

Courbe du débit en fonction du temps

Conclusion :
Les flux vidéo requièrent une transmission pas forcément fiable (robustesse aux erreurs,
avec ou sans mécanismes dédiés, FEC...), pas forcément ordonnée (les paquets constituant une
image peuvent arriver dans n'importe quel ordre), et à délai réduit. Le mécanisme de retransmission
intégré à TCP provoque un accroissement des délais de transmission souvent jugé incompatible
avec ce dernier besoin. De cette comparaison découle le conclusion que TCP est inadapté au
transport de flux multimédia.

Diffusion par udp :

Coté serveur:
Pour transmettre en udp,on utilise l'une des commandes suivantes:

vlc /var/www/documentaire.mpg --sout '#standard{access=udp,mux=st,dst=192.168.2.101:1234}'

cette commande permet la diffusion unicast du flux
vlc /var/www/documentaire.mpg --sout '#standard{access=udp,mux=st,dst=192.168.2.1:1234}'
cette commande permet la diffusion broadcast du flux

Coté client :
On exécute
vlc udp://@:1234
Capture avec wireshark
 Contrairement à tcp, udp véhicule les paquets dans un seul sens (du serveur au client),il ne
requiert pas la confirmation de réception. L'information est envoyée en un seul data gramme et n'est
pas forcément ordonnée. Udp n'est donc pas un protocole stable. mais il est le plus adapté pour le
transfert de flux multimédia vu que la transmission est à durée réduit.

Courbe du débit en fonction du temps :

Puisque le transfert se fait dans un seul sens donc il n'y aura pas de collision entre les
paquets d'où le débit de téléchargement de la vidéo coté client restera le même.

Réalisation d'une expérience

Nous avons fait un test qui nous semblait intéressant : c'est le fait de diffuser deux vidéos.
Le client les reçoit une par une. On note certaines variations sur le niveau du récepteur.
Comme l'indique le graphe on a 3 parties :

•une réception normale de la première vidéo. Stabilisation de la réception après le premier

accroissement.
•Le début de la réception de la deuxième vidéo et une chute du débit de réception de la première
vidéo.
•La stabilisation de la réception des deux vidéos mais avec un débit inférieur que celui du début.