Exercices technologie pour les applications (client-serveur)

Série d’exercices : Etudes de cas

Exercice 7 : Conception d’une application de niveau session

Une application de longue durée (de type traitement par lots ou transfert de fichier) est réalisée à distance à partir d’un calculateur émetteur E sur un calculateur récepteur R. Le site E émet des suites de messages correspondant à des données à transmettre (par exemple des articles d’un fichier). La conception de l’application doit prendre en compte des objectifs de reprise et amène donc à transmettre les données par groupe de 100 messages et à valider la transmission des messages d’un groupe avant de passer au suivant.
1 Le concepteur utilise la notion de point de synchronisation définie dans la couche session OSI et utilisable par les applications au moyen des protocoles RTS et présentation OSI.
Rappelez la définition et l’usage des différentes notions de synchronisation mineure, majeure, dialogue de session, activité de session.
Le service de synchronisation majeure comporte quatre unités de service qui sont:
S-SYNC-MAJOR.request
S-SYNC-MAJOR.indication
S-SYNC-MAJOR.response
S-SYNC-MAJOR.confirmation
Donnez l’automate du service de demande de pose de point de synchronisation majeur (c’est l’automate de service du coté émetteur qui demande la pose). Cet automate ne comporte donc que des émissions d’unités de service et des arrivées d’unités de service.
On suppose que l’émetteur possède le jeton de synchronisation majeure et d’activité et qu’il peut donc poser un point de synchronisation majeur. Pour cet automate on ne s’intéresse qu’au mode de fonctionnement normal dans lequel aucune panne n’intervient (ni panne de site, d’entité distante, …).
Pour chaque état on définira clairement en une phrase la situation à laquelle correspond cet état. Pour chaque transition on donnera la condition et l’action associée en les justifiant.

2 On souhaite ajouter au mécanisme précédent l’acquisition du jeton de synchronisation majeure et d’activité lorsque le site n’en dispose pas (par exemple au début de l’échange).
Les unités de service pour la demande du jeton sont:
S-TOKEN-PLEASE.request
S-TOKEN-PLEASE.indication
Les unités de service pour la cession du jeton sont:
S-TOKEN-GIVE.request
S-TOKEN-GIVE.indication
On suppose l’existence d’une variable booléenne « jeton_majeur » indiquant la présence du jeton majeur. Donnez l’automate du service de demande de cession et d’obtention du jeton majeur. Là encore on ne s’intéresse qu’au fonctionnement sans pannes.

3 On souhaite enfin définir le comportement de l’émetteur qui transmet entre deux synchronisations majeures 100 messages de données normales au moyen de:
S-DATA.request
S-DATA.indication
Donnez l’automate de ce dernier comportement (dans les mêmes conditions que précédemment).
4 En déduire l’automate complet comprenant vos réponses aux questions 2, 3, 4.

Exercice 8 : Comparaison de la programmation d’applications réparties avec TCP et avec CORBA

Pour comparer les deux modes de communication on étudie une application de commerce électronique, qui consiste à obtenir d’un site serveur distant une cotation pour une valeur boursière. La solution en mode message utilise le niveau transport TCP avec l’interface socket et la solution en mode RPC utilise l’approche objets répartis CORBA.Ce problème ne traite que des comportements d’un client. Il n’est pas nécessaire de comprendre très en détail les codes présentés en C ou en C++ pour répondre aux questions d’ordre général concernant les aspects réseaux des deux solutions.

Utilisation du niveau transport TCP avec l’interface Socket

L’application considérée est celle d’un mode client serveur basique avec un message requête de demande de cotation et un message réponse contenant le cours de bourse. On identifie donc comme premier élément du protocole (message et donnée à échanger dans le message) une requête qui comporte un nom de valeur boursière à coter. C’est une chaîne de caractères de longueur variable. La longueur est codée sur un entier long (valeur maximum 100 octets). La réponse comporte la cotation demandée (codée pour simplifier sous la forme d’un entier long). Elle comporte aussi un code réponse entier au cas ou des erreurs auraient rendu l’opération impossible. Les structures de données échangées dans les messages en langage C sont donc décrites comme suit :
#define MAXSTOCKNAMELEN 100
struct Quote_Request
{
long len; /* Longueur de la requête */
char name[MAXSTOCKNAMELEN]; /* Nom de la valeur à coter */
};
struct Quote_Response
{
long value; /* Cours de la valeur */
long errno; /* 0 si succès, code d’erreur sinon */
};
On rassemble, dans une procédure utilisée par le client (connect_quote_server), les instructions nécessaires pour la mise en connexion du client avec le serveur, selon les primitives de l’interface socket.
– En entrée de la procédure, server est une chaîne de caractères qui définit le nom du service de cotation.
– En entrée de la procédure, port contient le numéro de port du service de cotation.
– En résultat HANDLE est un entier qui contient la référence du descriptif de la socket.

typedef int HANDLE;
HANDLE connect_quote_server (const char server[], u_short port)
{
struct sockaddr_in addr;
struct hostent *hp;
HANDLE sd;
/* Création de la terminaison locale */
sd = socket (AF_INET, SOCK_STREAM, 0);