Réseau informatique et musique : Différence entre versions
(44 révisions intermédiaires par un autre utilisateur non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
+ | <include nopre noesc src="/home/pedago/pimasc/include/video-ReseauEtMusique-iframe.html" /> | ||
__TOC__ | __TOC__ | ||
<br style="clear: both;"/> | <br style="clear: both;"/> | ||
Ligne 4 : | Ligne 5 : | ||
===Présentation générale du projet=== | ===Présentation générale du projet=== | ||
====Contexte==== | ====Contexte==== | ||
+ | Dans un réseau informatique, il est important, pour un administrateur, de connaître l’état de son réseau à un moment donné. En revanche, ce travail est très prenant et pénible à faire car il devrait étudier les paquets un par un et filtrer que les informations utiles. C’est pour ça qu’il est intéressant de filtrer les paquets utiles et avertir l’administrateur (par l’intermédiaire du son) de l’arrivée de tels types de paquets dans le réseau. | ||
====Objectif du projet==== | ====Objectif du projet==== | ||
− | Le but de ce projet est de récupérer et analyser les paquets qui circulent dans le réseau et produire des mélopées qui leurs correspondent. Celle-ci simplifie le travail d’un administrateur en lui aidant à identifier les paquets sans les | + | Le but de ce projet est de récupérer et analyser les paquets qui circulent dans le réseau et produire des mélopées qui leurs correspondent. Celle-ci simplifie le travail d’un administrateur en lui aidant à identifier les paquets sans qu'il les étudie en détails. |
+ | |||
====Description du projet==== | ====Description du projet==== | ||
Ce projet se consiste à : | Ce projet se consiste à : | ||
− | + | *Récupérer les paquets avec <abbr title="Linux Socket Filter">LSF</abbr> | |
− | + | *Analyser des paquets sur différentes couches OSI (liaison de données, réseau, transport, application) | |
− | + | *Ecrire un programme (en utilisant la bibliothèque de son) pour pouvoir produire de son par rapport au type de paquets | |
− | |||
====Choix techniques : matériel et logiciel==== | ====Choix techniques : matériel et logiciel==== | ||
− | ===Etapes du projet=== | + | Dans le cadre de ce projet, le matériel qui sera utilisé est un PC sous Linux. Au niveau de logiciel, l’outil <code>LSF</code>, les <abbr title="Application Programming Interface">API</abbr>s de <code>libsndfile</code><sup><small><nowiki>[</nowiki>[[#Références|1]]]</small></sup> et <code>libasound</code><sup><small><nowiki>[</nowiki>[[#Références|2]]]</small></sup> (bibliothèque d’ALSA) seront utilisés pour faire la programmation en C. <code>LSF</code> est un outil/mécanisme de socket brut (<em>raw</em>) qui a l’accès direct de la carte réseau sachant qu'il est attaché au noyau du système d'exploitation. Un avantage de cet outil est que les paquets de données ne sont pas modifiés. <code>libsndfile</code> est une bibliothèque qui permet de lire/écrire des fichiers audio. <code>libasound</code> est, quant à elle, utilisée afin de produire du son sur la périphérique audio. |
+ | |||
+ | Les paquetages<sup><small><nowiki>[</nowiki>[[#Références|3]]]</small></sup><sup><small><nowiki>[</nowiki>[[#Références|4]]]</small></sup> qui sont nécessaires pour ce projet sont : <code>libsndfile1</code>, <code>libsndfile1-dev</code>, <code>libasound2</code>, et <code>libasound2-dev</code>. | ||
+ | |||
+ | ===Etapes globales du projet=== | ||
+ | # Etude de la bibliothèque API de <code>libsndfile</code> et <code>libasound</code> | ||
+ | # Prise en main de la bibliothèque <code>libsndfile</code> afin de lire des fichiers audio | ||
+ | # Prise en main de la bibliothèque <code>libasound</code> pour produire du son correspondant au fichier audio lu | ||
+ | # Appariement des son correspondants aux paquets étudiés en fusionnant <code>LSF</code> avec le programme créé précédemment | ||
+ | |||
==Avancement du Projet== | ==Avancement du Projet== | ||
===Semaine 1=== | ===Semaine 1=== | ||
− | ... | + | Durant cette première séance du projet, j’ai pris en main l’API de <code>libsndfile</code> en commençant par étudier les fonctions définies dans cette bibliothèque. Cette étude m’a permet de récupérer que les fonctions qui seront utilisées pour lire un fichier de type audio. Pour réduire la complexité du code, j’ai choisi de prendre en compte que les fichiers de type <abbr title="WAVEform audio format">WAV</abbr> (codé en <abbr title="Pulse-Code Modulation">PCM</abbr>). Les étapes réalisées lors de cette séance sont : |
+ | *Installer le paquetage <code>libsndfile1</code> et <code>libsndfile1-dev</code> | ||
+ | *Ouvrir un fichier audio de type <code>.wav</code> | ||
+ | *Récupérer ses caractéristiques (taux d’échantillonnage, codage utilisé, nombre de canaux, durée) | ||
+ | *Lire des données depuis ce fichier audio | ||
+ | |||
+ | ===Semaine 2=== | ||
+ | Lors de la deuxième séance, j’ai commencé à étudier la bibliothèque libasound (<code>ALSA</code>) afin de pouvoir produire du son en directement configurant la carte son (étant donné que c’est une bibliothèque du bas niveau). Il y existe deux types de configuration : matériel (hardware) et logiciel (software). Mais, il existe une configuration simple qui permet de les paramétrer avec une seule fonction de la bibliothèque. Les étapes réalisées lors de la deuxième semaine sont : | ||
+ | *Créer une poignée (handle) vers le periphérique du son | ||
+ | *Parametrer la configuration matériel et logiciel de libasound | ||
+ | *Passer les données (de fichier audio) lues précedemment à la fonction de <code>libasound</code> afin de produire du son à la sortie | ||
+ | ===Semaine 3=== | ||
+ | Jusqu’à maintenant, le programme prend en compte qu’un fichier audio. Pour pouvoir récupérer plusieurs fichiers audio et ses caractéristiques, il a fallu créer une structure de type : | ||
+ | {| width=10% align=center | ||
+ | |<pre> | ||
+ | struct snd_data { | ||
+ | int *data; | ||
+ | int frames; | ||
+ | SF_INFO sfinfo; | ||
+ | }; | ||
+ | </pre> | ||
+ | |} | ||
+ | Dans cette structure, il y a : | ||
+ | *Pointeur sur un entier qui sera initialisé avec les données audio | ||
+ | *Un entier (frames) qui contient le nombre de données lu depuis un fichier audio | ||
+ | *Une structure <code>SF_INFO</code> qui contient les caractéristique du fichier son | ||
+ | Afin de produire un son (sans perte d’information ou altération), il faut changer la configuration software et/ou hardware à chaque changement de fichier audio tels que la période les canaux, etc.. | ||
+ | |||
+ | <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap;white-space: -o-pre-wrap;word-wrap: break-word;">Remarque : | ||
+ | Normalement, on aurait dû utiliser une fonction asynchrone pour produire du son à moment donné (avec signaux ou autre types de communication). En revanche, cette fonction est dépréciée dans certains systèmes à cause de l’incompatibilité avec le logiciel de son tels que PulseAudio. | ||
+ | </pre> | ||
+ | ===Semaine 4=== | ||
+ | Lors de cette semaine, j’ai commencé à programmer la communication interprocessus (par l’intermédiaire de mémoire partagée). Cette communication (IPC) sera utilisé plus tard pour communiquer l’information venant du programme coté réseau (LSF) vers coté audio (libasound). L’information qui sera communiquée entre 2 processus est un entier qui va déterminer quel type de son à appliquer sur la sortie (périphérique). Par exemple, le programme coté LSF va modifier cet entier par rapport au paquet étudié et le programme coté audio verra cette modification (et il va changer le type de son à produire). | ||
+ | |||
+ | <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap;white-space: -o-pre-wrap;word-wrap: break-word;">Remarque : | ||
+ | Pour ce moment, la communication interprocessus se passe entre un fichier test (en C) et le programme audio (déjà écrit aux séances précédentes). Il sera implémenté plus tard dans LSF. | ||
+ | </pre> | ||
+ | |||
+ | ===Semaine 5=== | ||
+ | *Prise en main de <code>LSF</code> | ||
+ | *Etude de différent paquets analysable avec <code>LSF</code> | ||
+ | |||
+ | ===Semaine 6=== | ||
+ | Cette semaine, j’ai commencé à regarder les différents paquets à analyser et produire du son correspondant. Le tableau ci-dessous résume cette analyse : | ||
+ | |||
+ | {| border="1" class="wikitable" style="margin: 1em auto 1em auto;" | ||
+ | ! Couche | ||
+ | ! Type/caractéristique du trame | ||
+ | |- | ||
+ | ! Liaison de données | ||
+ | | broadcast - <abbr title="Address Resolution Protocol">ARP</abbr> | ||
+ | |- | ||
+ | ! rowspan="3" | Réseau | ||
+ | | IP - flux local | ||
+ | |- | ||
+ | | IP - flux distant | ||
+ | |- | ||
+ | | ICMP - requête ping | ||
+ | |- | ||
+ | ! Transport | ||
+ | | <nowiki>-</nowiki> | ||
+ | |- | ||
+ | ! rowspan="2" | Application | ||
+ | | flux de grande volume - <abbr title="Network File System">NFS</abbr>, <abbr title="Secure SHell">SSH</abbr>/<abbr title="Secure File Transfer Protocol">SFTP</abbr> | ||
+ | |- | ||
+ | | flux de faible volume - <abbr title="Domain Name System">DNS</abbr>, <abbr title="Hypertext Transfer Protocol">HTTP</abbr> | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | ===Semaine 7=== | ||
+ | Maintenant, il fallait ajouter le fonctionnement de <code>thread</code> dans le programme pour pouvoir gérer plusieurs paquets qui arrivent sur la machine. Ces <code>threads</code> seront lancés dès qu’un paquet arrive. De ce fait, on n’a pas besoin d’attendre que l’autre fonction finisse à traiter les données pour pouvoir faire la suite. Chaque <code>thread</code> lancé sera capable d’ouvrir une poignée (handle) vers le périphérique du son et lui envoyer des données. | ||
+ | ===Semaine 8=== | ||
+ | Cette semaine, j’ai ajouté un fonctionnement de réglage de son pour chaque thread lancé. La fonction de réglage modifiera le pourcentage du son à produire sur la périphérique <code>Master</code> de la carte son. | ||
+ | ===Semaine 9=== | ||
+ | Lors de test de fonctionnement de la fonction de réglage de son, quelques bugs ont été trouvés: | ||
+ | *Impossible de régler le son après avoir commencé à écrire les données sur le périphérique | ||
+ | *Test avec mode écriture non-bloqué sur le périphérique a échoué | ||
+ | Puisque le mode non-bloqué a échoué, je maintiens le mode bloqué. De ce fait, le problème de réglage de son persiste. | ||
+ | ===Semaine 10=== | ||
+ | Appariement avec <code>LSF</code> les fonctions de lancer un thread et les fonctions de production de son. | ||
+ | ===Semaine 11=== | ||
+ | J’ai commencé à concevoir une interface graphique avec logiciel <code>Glade</code> ce qui va générer des fichiers <abbr title="Extensible Markup Language">XML</abbr>. Ce fichier sera ensuite utilisé pour créer l’interface graphique avec GTK+ | ||
+ | [[Fichier:Gladeobj.png|thumb|200px|center|Outils Glade]] | ||
+ | ===Semaine 12=== | ||
+ | *Prise en main de GTK+ en C | ||
+ | *Ajout des événements pour chaque boutons | ||
+ | [[Fichier:Glade.png|thumb|250px|center|Fenêtre en GTK+]] | ||
+ | |||
== Fichiers Rendus == | == Fichiers Rendus == | ||
+ | === Rapport === | ||
+ | Fichier [[Media:Rapport_projet_S8_SEKAR.pdf |PDF]] du rapport | ||
+ | |||
+ | === Code source === | ||
+ | [[Fichier:Projet_S8_SEKAR.zip]] | ||
+ | |||
+ | ==Références== | ||
+ | #[[#Choix techniques : matériel et logiciel|^]]<em>Détails de l'API libsndfile sur [http://www.mega-nerd.com/libsndfile libsndfile AppStore] par Erik de Castro Lopo</em> | ||
+ | #[[#Choix techniques : matériel et logiciel|^]]<em>Détails de l'API libasound sur [http://www.alsa-project.org/alsa-doc/alsa-lib ALSA Project - the C library reference] par Jaroslav Kysela, Abramo Bagnara, Takashi Iwai et Frank van de Pol</em> | ||
+ | #[[#Choix techniques : matériel et logiciel|^]]<em>Paquetage [https://packages.debian.org/search?suite=wheezy&arch=any&searchon=contents&keywords=sndfile.h libsndfile1-dev] sur le site officiel de Debian</em> | ||
+ | #[[#Choix techniques : matériel et logiciel|^]]<em>Paquetage [https://packages.debian.org/search?mode=exactfilename&searchon=contents&keywords=asoundlib.h libasound2-dev] sur le site officiel de Debian</em> |
Version actuelle datée du 15 juin 2015 à 15:36
Cahier des charges
Présentation générale du projet
Contexte
Dans un réseau informatique, il est important, pour un administrateur, de connaître l’état de son réseau à un moment donné. En revanche, ce travail est très prenant et pénible à faire car il devrait étudier les paquets un par un et filtrer que les informations utiles. C’est pour ça qu’il est intéressant de filtrer les paquets utiles et avertir l’administrateur (par l’intermédiaire du son) de l’arrivée de tels types de paquets dans le réseau.
Objectif du projet
Le but de ce projet est de récupérer et analyser les paquets qui circulent dans le réseau et produire des mélopées qui leurs correspondent. Celle-ci simplifie le travail d’un administrateur en lui aidant à identifier les paquets sans qu'il les étudie en détails.
Description du projet
Ce projet se consiste à :
- Récupérer les paquets avec LSF
- Analyser des paquets sur différentes couches OSI (liaison de données, réseau, transport, application)
- Ecrire un programme (en utilisant la bibliothèque de son) pour pouvoir produire de son par rapport au type de paquets
Choix techniques : matériel et logiciel
Dans le cadre de ce projet, le matériel qui sera utilisé est un PC sous Linux. Au niveau de logiciel, l’outil LSF
, les APIs de libsndfile
[1] et libasound
[2] (bibliothèque d’ALSA) seront utilisés pour faire la programmation en C. LSF
est un outil/mécanisme de socket brut (raw) qui a l’accès direct de la carte réseau sachant qu'il est attaché au noyau du système d'exploitation. Un avantage de cet outil est que les paquets de données ne sont pas modifiés. libsndfile
est une bibliothèque qui permet de lire/écrire des fichiers audio. libasound
est, quant à elle, utilisée afin de produire du son sur la périphérique audio.
Les paquetages[3][4] qui sont nécessaires pour ce projet sont : libsndfile1
, libsndfile1-dev
, libasound2
, et libasound2-dev
.
Etapes globales du projet
- Etude de la bibliothèque API de
libsndfile
etlibasound
- Prise en main de la bibliothèque
libsndfile
afin de lire des fichiers audio - Prise en main de la bibliothèque
libasound
pour produire du son correspondant au fichier audio lu - Appariement des son correspondants aux paquets étudiés en fusionnant
LSF
avec le programme créé précédemment
Avancement du Projet
Semaine 1
Durant cette première séance du projet, j’ai pris en main l’API de libsndfile
en commençant par étudier les fonctions définies dans cette bibliothèque. Cette étude m’a permet de récupérer que les fonctions qui seront utilisées pour lire un fichier de type audio. Pour réduire la complexité du code, j’ai choisi de prendre en compte que les fichiers de type WAV (codé en PCM). Les étapes réalisées lors de cette séance sont :
- Installer le paquetage
libsndfile1
etlibsndfile1-dev
- Ouvrir un fichier audio de type
.wav
- Récupérer ses caractéristiques (taux d’échantillonnage, codage utilisé, nombre de canaux, durée)
- Lire des données depuis ce fichier audio
Semaine 2
Lors de la deuxième séance, j’ai commencé à étudier la bibliothèque libasound (ALSA
) afin de pouvoir produire du son en directement configurant la carte son (étant donné que c’est une bibliothèque du bas niveau). Il y existe deux types de configuration : matériel (hardware) et logiciel (software). Mais, il existe une configuration simple qui permet de les paramétrer avec une seule fonction de la bibliothèque. Les étapes réalisées lors de la deuxième semaine sont :
- Créer une poignée (handle) vers le periphérique du son
- Parametrer la configuration matériel et logiciel de libasound
- Passer les données (de fichier audio) lues précedemment à la fonction de
libasound
afin de produire du son à la sortie
Semaine 3
Jusqu’à maintenant, le programme prend en compte qu’un fichier audio. Pour pouvoir récupérer plusieurs fichiers audio et ses caractéristiques, il a fallu créer une structure de type :
struct snd_data { int *data; int frames; SF_INFO sfinfo; }; |
Dans cette structure, il y a :
- Pointeur sur un entier qui sera initialisé avec les données audio
- Un entier (frames) qui contient le nombre de données lu depuis un fichier audio
- Une structure
SF_INFO
qui contient les caractéristique du fichier son
Afin de produire un son (sans perte d’information ou altération), il faut changer la configuration software et/ou hardware à chaque changement de fichier audio tels que la période les canaux, etc..
Remarque : Normalement, on aurait dû utiliser une fonction asynchrone pour produire du son à moment donné (avec signaux ou autre types de communication). En revanche, cette fonction est dépréciée dans certains systèmes à cause de l’incompatibilité avec le logiciel de son tels que PulseAudio.
Semaine 4
Lors de cette semaine, j’ai commencé à programmer la communication interprocessus (par l’intermédiaire de mémoire partagée). Cette communication (IPC) sera utilisé plus tard pour communiquer l’information venant du programme coté réseau (LSF) vers coté audio (libasound). L’information qui sera communiquée entre 2 processus est un entier qui va déterminer quel type de son à appliquer sur la sortie (périphérique). Par exemple, le programme coté LSF va modifier cet entier par rapport au paquet étudié et le programme coté audio verra cette modification (et il va changer le type de son à produire).
Remarque : Pour ce moment, la communication interprocessus se passe entre un fichier test (en C) et le programme audio (déjà écrit aux séances précédentes). Il sera implémenté plus tard dans LSF.
Semaine 5
- Prise en main de
LSF
- Etude de différent paquets analysable avec
LSF
Semaine 6
Cette semaine, j’ai commencé à regarder les différents paquets à analyser et produire du son correspondant. Le tableau ci-dessous résume cette analyse :
Couche | Type/caractéristique du trame |
---|---|
Liaison de données | broadcast - ARP |
Réseau | IP - flux local |
IP - flux distant | |
ICMP - requête ping | |
Transport | - |
Application | flux de grande volume - NFS, SSH/SFTP |
flux de faible volume - DNS, HTTP |
Semaine 7
Maintenant, il fallait ajouter le fonctionnement de thread
dans le programme pour pouvoir gérer plusieurs paquets qui arrivent sur la machine. Ces threads
seront lancés dès qu’un paquet arrive. De ce fait, on n’a pas besoin d’attendre que l’autre fonction finisse à traiter les données pour pouvoir faire la suite. Chaque thread
lancé sera capable d’ouvrir une poignée (handle) vers le périphérique du son et lui envoyer des données.
Semaine 8
Cette semaine, j’ai ajouté un fonctionnement de réglage de son pour chaque thread lancé. La fonction de réglage modifiera le pourcentage du son à produire sur la périphérique Master
de la carte son.
Semaine 9
Lors de test de fonctionnement de la fonction de réglage de son, quelques bugs ont été trouvés:
- Impossible de régler le son après avoir commencé à écrire les données sur le périphérique
- Test avec mode écriture non-bloqué sur le périphérique a échoué
Puisque le mode non-bloqué a échoué, je maintiens le mode bloqué. De ce fait, le problème de réglage de son persiste.
Semaine 10
Appariement avec LSF
les fonctions de lancer un thread et les fonctions de production de son.
Semaine 11
J’ai commencé à concevoir une interface graphique avec logiciel Glade
ce qui va générer des fichiers XML. Ce fichier sera ensuite utilisé pour créer l’interface graphique avec GTK+
Semaine 12
- Prise en main de GTK+ en C
- Ajout des événements pour chaque boutons
Fichiers Rendus
Rapport
Fichier PDF du rapport
Code source
Références
- ^Détails de l'API libsndfile sur libsndfile AppStore par Erik de Castro Lopo
- ^Détails de l'API libasound sur ALSA Project - the C library reference par Jaroslav Kysela, Abramo Bagnara, Takashi Iwai et Frank van de Pol
- ^Paquetage libsndfile1-dev sur le site officiel de Debian
- ^Paquetage libasound2-dev sur le site officiel de Debian