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 represente 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èrenttes portion de la vidéo à sa guise .

Diffusion à travers vlc :

diffusion de la vidéo coté serveur

On diffuse la video à 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 da des ns paquets tcp.

Courbe du débit en fonction du temps

conclusion

Les flux video 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 duflux

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

cette commande permet la diffusion broadcast duflux

Coté client :

On execute

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.