Pour vérifier les fonctions de gestion du traffic en ATM (et tester les performances des liaisons), nous avons écrit un programme qui s'appui sur le couple cli_fork et serv_fork. Celui se comporte comme un serveur sur une machine, et comme un client sur une autre.
Dans la partie serveur, on donne comme argument le device à utiliser et le SAP sur lequel on attends les demandes connexions.
ligne de commande : qos_test_avec_contrat fa0 -c <SAP>
Dans la partie client, on donne :
Il existe deux versions du programme (qos_test_avec_contrat et qos_test_sans_contrat). La première version respecte le contrat de traffic passé avec le réseau (à quelques Ko/s près). La seconde version ne respecte pas le contrat et envoie tout le temps des données sur la connexion.
Les sources sont disponibles : qos_test_sans_contrat.c et qos_test_avec_contrat.c
/* Includes ATM */
#include <sys/file.h>
#include <sys/fcntl.h>
#include <fore_atm/fore_atm_user.h>
Ce sont les variables minimales pour ouvrir une connexion ATM :
/* Variables ATM */
int fd;
Atm_info info;
Atm_endpoint dst;
Atm_qos qos;
Atm_qos_sel qos_selected;
Atm_sap ssap;
Aal_type aal = aal_type_5;
Atm_dataflow dataflow = duplex;
fd : le descripteur qui sert à adresser la connexion.info: les caractéristiques du device (uniquement
MTU pour l'instant).dst: l'équivalent du sockaddr_in de
l'IP. Designe un couple machine (adresse
ATM) / SAP.qos: la QoS demandée
de la connexion.qos_selected: la QoS
obtenue.ssap: le numéro de SAP
local.aal: le type d'AAL (et
aussi) à utiliser pour connexion.dataflow: le type
de connexion à utiliser (mono ou bi-directionnelle)Le compilateur utilisé est gcc. Il faut noter que les machines SunOS équipées d'une carte ATM sont phedre, cherubin, tartuffe, dorante et portent respectivement les noms phedre-atm, cherubin-atm, tartuffe-atm, dorante-atm dans le réseau ATM natif.
Les options de compilation sont
-Wall -ansi -O3 -I/opt/FOREatm/include -L/opt/FOREatm/lib -latm
L'option -ansi pose des problèmes si on utilise des long
long (64 bits), dans ce cas, on enlève cette option.
En utilisant ces options de compilations, il y a toujours un warning, qui
a trait à rcs (que nous n'utilisons pas).
Le programme de test de la QoS fourni par contre des informations beaucoup plus intéressantes...
D'une part, en spécifiant des valeurs différentes de la QoS demandée pour la connexion, on a pu voir que le débit minimal d'une connexion était fixé à 66 Ko/s, et le débit maximal à 16562 Ko/s (132500 kilobits par seconde). On voit tout de suite, en regardant les statistiques fournies par les programmes, que ce débit n'est pas atteint !
Exemple, en demandant 2500 Ko/s, on obtient une QoS de 2472
Ko/s et un débit réel de 2110 Ko/s. En demandant 18000 Ko/s,
on obtient 16562 Ko/s (le maximum possible avec cette liaison), et le débit
réel est de 14800 Ko/s. (soit 1 Go en moins de 71 secondes....
;-).
Les perfomances sont impressionantes, mais le fait que le débit réel
ne corresponde pas au débit demandé est génant. Même
à faible débit (200 Ko/s) on obtient pas plus de 165 Ko/s de
débit réel...
On remarque aussi que lorsque le réseau diminue la QoS de la connexion,
il ne touche qu'au débit crête. La valeur du débit moyen
reste la même, et ce même si elle est irréalisable.
La connexion peut aussi être directement refusée par le réseau
(sans même que le destinataire ne soit averti de la demande de connexion)
si il estime qu'il ne peut pas remplir la QoS demandée. (ie: la différence
entre la bande passante disponible et celle demandée est trop grande).
La plupart du temps, le réseau se contente d'abaisser la QoS avant
de soumettre la demande de connexion au destinataire.