Mini-projet2

Cours: INF4402
Projet: 2
Nom de famille: Pieraut, Prénom: Francis, Matricule: 60104
Nom de famille: AZIZI, Prénom: Oussama, Matricule: 1006964

Introduction

Corba est née du besoin d’interopérabilité entre le nombre toujours grandissant de différents produit logiciel et matériels. Il a été fondé par L'Object Management Group (OMG) qui est un consortium international (fondé en 1989) regroupant actuellement environ 600 membres. L'OMG vise à promouvoir les technologies orientées objets pour la conception d'applications informatiques distribuées, interopérables et ouvertes. L'OMG a ainsi défini dans l'Object Management Architecture Guide (OMA) son modèle d'objets distribués et inter opérables. Ce modèle est supporté par l'architecture CORBA (Common Object Request Broker Architecture). CORBA définit un ensemble de composants : le langage IDL, les projections, l'ORB, l'Interface Repository, la DII, le BOA. L'interface fonctionnelle de ces objets est décrite grâce au langage IDL (Interface Description Language). L'IDL est un langage de description d'interfaces totalement indépendant du langage de programmation. La projection (ou mapping) permet de générer du code pour exploiter le type d'objet a partir d'un langage de programmation. Ce mécanisme est dépendant du langage cible. Avec Corba, les utilisateurs ont accès à l’information de façon transparente, sans se soucier du logiciel ou du matériel.

L'Object Management Group propose une solution globale pour la construction d'applications distribuées résolvant les problèmes de communication, d'hétérogénéité, d'intégration et d'interopérabilité. 

Orbit est le système que nous allons utiliser pour faire ce travaille pratique. Orbit est une implementation respectant  les spécifications de CORBA 2.2 Object Request Broker (ORB).

Dans ce travail pratique nous avons programmé un client et un serveur qui utilise Corba pour communiquer. Le serveur est un serveur de fichier qui limite l'accès à un repertoire spécifique. Le client fait des requêtes à ce serveur afin d'aller récuperer un fichier qui se trouve dans le répertoire spécifique du server. Le mécanime implanté permet aussi d'aller chercher de l'information sur le fichier demandé tel sa taille et sa date de dernière modification.  Une fois ces mécanismes implantés, nous avons fait des analyses de performance en évaluant le temps requis pour faire des appels simples, des appels à travers CORBA sur un même ordinateur et des appels CORBA à travers le réseau. Par la suite nous avons évaluer le temps requis pour faire des lectures d'un document en local, par réseau avec NFS, à travers CORBA en local, et à travers CORBA par le réseau.

 

Description de l'implantation

Côté serveur:

Afin de simplifier les analyses à faire, nous avons ajouté l'option -s au serveur afin de faire les appels Corba simples. Donc dans le code du serveur nous retrouvons le code suivant :

if(appel_simple)
{ 
    time(&t_before);
    for(i = 0 ; i < nb ; i++) {
        do_getServerInfo(server, version, &info, &date, &ev);
    ...

}

Le serveur fait une vérification des accès du client en vérifiant la présence de ".." dans le nom du fichier demandé. Ceci est fait de la facon suivante dans la fonction do_openfile(..):

if(strstr(nomFichier,"..") != NULL)
{
    sprintf(message_erreur,"Ce fichier %s fait reference a un repertoire parent\n",nomFichier);
    (*erreur) = CORBA_string_dup((CORBA_char *) strdup(message_erreur));
    return ERROR;
}

La validité du repertoire spécifier du coté serveur à été vérifier de la facon suivante:

//Verification de la validite du repertoire
if (repertoire_requetes!=NULL)
{
    if (stat (repertoire_requetes, &stat_repertoire) < 0 || S_ISDIR (stat_repertoire.st_mode)== 0)
    {
        printf("Le repertoire entre n'existe pas \n");
        return ERROR; 
    }
}

Afin de réaliser les fonctions désirées, nous avons défini l'interface IDL suivante:

typedef sequence<octet> ByteSequence;
typedef char Version[12];

interface DocumentServer
{
void getServerInfo(out Version version, out ByteSequence info, 
out string date);
long openFile(in string nomFichier, out long taille, out string derniereModification, out string erreur);
short closeFile(in long pFILE);
short getDocument(in long pFILE, out ByteSequence byteSeq);

}; 

Côté client et serveur:

Nous avons ajouté l'option -o afin de spécifier le nombre d'ouverture du fichier. 

Mode d'utilisation de notre client et serveur: 

Usage: httpclient -n nom du fichier ds lequel placer l'adresse (par defaut doc.ior)
                          -p nom du repertoire a partir duquel servir les requetes
                          -o nombre d'ouverture locale du fichier 
                          -s nombre d'appel a la fct getServerInfo 

Usage: httpServer -n nom du fichier dans lequel placer l'adresse (par defaut doc.ior)
                          -p nom du repertoire a partir duquel servir les requetes
                          -o nombre d'ouverture locale du fichier DocumentServer.idl
                          -s nombre d'appels simple a la fct getServerInfo 

... (liens vers les fichiers source) DocumentServer-client.c DocumentServer-server.c et DocumentServer.idl

Description de l'environnement de test

Les tests ont été fait dans le laboratoire CASI (centre d'analyse des systèmes informatique). C'est un réseau LINUX de plusieurs PC. Nous avons effectué nos tests à partir de deux des machines de ce réseau, soit Phenergan et Mario (2 PIII/500mhz)

Présentation et discussion des résultats obtenus

Voici les résultats des appels à la fonction GetServerInfo

Appels Corba simples  Appels Corba Locaux Applels Corba réseau
10 000 100 000 10 000 100 000 10 000 100 000
Phenergan 2 sec. 19 sec. 3 sec. 34 sec. 7 sec. 68 sec.
Mario 2 sec. 21 sec. 34 sec. 35 sec. 7 sec. 68 sec.

 Voici les résultats des appels à la lecture du fichier DocumentServer.idl sur la partition locale et sur la partition NFS

Appels Corba simples  Appels Corba Locaux Appels Corba réseau
1 000 10 000 1 000 10 000 1 000 10 000
Mario (local) 1 sec. 9 sec. 1 sec. 15 sec. 3 sec. 29 sec.
Mario (NFS) 1 sec. 10 sec. 1 sec. 12 sec. 2 sec. 27 sec.

Conclusion

Discussion des résultats

Notre implnatation du serveur de fichier et d'un client fonctionne parfaitement. L'analyse de performance nous à permis d'avoir une idée des performances des appels corba réseaux en les comparant avec des appels locaux ainsi que des appels simples. Il prend en moyenne 3 fois plus de temps faire un appel réseau d'un appel  Corba simple et 2 fois plus de temps qu' un appel Corba local.

Difficultés rencontrées

Les seules difficultés que nous avons rencontrées sont de trouver ou il fallait placer les noms de nos fonctions afin qu'elles puissent etre utilisées ainsi que des problèmes de débuggage avec les paramètres  Corba des fonctions du serveur.

Avantages et inconvénients de l'utilisation de CORBA pour les services répartis

Programmer en Corba est bien plus pratique que de programmer directement sur la couche TCP tel que fait durant le TP1. La couche TCP est transparente et cela permet de programmer des systèmes distribués bien plus facilement. Corba ne permet pas d'envoyé des objets en paramètre et cela peut-être ennuyeux par la programmation objet. L'utilisation de type Corba ajoute une petite complexité à son l'utilisation et oblige des modifications de structures lorsqu'on veut l'intégrer à un projet.