exercices applications reparties - Deptinfo - Cnam

Exercice 2 :Désignation des fichiers dans le système de fichiers répartis NFS .... A) Utilisation du niveau transport TCP avec l'interface Socket ..... Question 4 - Définir le protocole d'accès au serveur (format des requêtes, des ...... en les adaptant à l'univers des téléphones portables c'est à dire à de petits terminaux sans fils.


un extrait du document









Sujets des exercices dirigés

Technologie pour les applications
client-serveur

UE RSX 102



Année 2007-2008




G. Florin, S. Natkin, E. Gressier,
L. Duchien, J.M. Farinone
Table des matières
 TOC \o "1-3" PREMIER CHAPITRE  PAGEREF _Toc190074228 \h 4
EXERCICES CONTROLE REPARTI  PAGEREF _Toc190074229 \h 4
Série d'exercices mode message  PAGEREF _Toc190074230 \h 4
Exercice 1: Automate de connexion TCP  PAGEREF _Toc190074231 \h 4
Série d'exercices : Appel de procédure distante  PAGEREF _Toc190074232 \h 6
Exercice 2 : Traitement des pertes de messages  PAGEREF _Toc190074233 \h 6
Exercice 3 : Exécutions très longues.  PAGEREF _Toc190074234 \h 6
Exercice 4 : Appels en parallèle (redondance massive)  PAGEREF _Toc190074235 \h 6
Exercice 5 : Serveurs multiples (redondance sélective)  PAGEREF _Toc190074236 \h 6
Exercice 6 : Parallélisme et performance des communications en RPC  PAGEREF _Toc190074237 \h 7
Série d'exercices : Etudes de cas  PAGEREF _Toc190074238 \h 9
Exercice 7 : Conception d'une application de niveau session  PAGEREF _Toc190074239 \h 9
Exercice 8 : Comparaison de la programmation d'applications réparties avec TCP et avec CORBA  PAGEREF _Toc190074240 \h 11
Exercice 9 : Objets répartis en CORBA  PAGEREF _Toc190074241 \h 16
SECOND CHAPITRE  PAGEREF _Toc190074242 \h 18
EXERCICES PRÉSENTATION DES DONNEES  PAGEREF _Toc190074243 \h 18
Série d'exercices conversions  PAGEREF _Toc190074244 \h 18
Exercice 1 : Optimisation des conversions  PAGEREF _Toc190074245 \h 18
Exercice 2 : Problème des formats de mémoire (petit boutiste, grand boutiste)  PAGEREF _Toc190074246 \h 18
Exercice 3 : Définition de syntaxe ASN1  PAGEREF _Toc190074247 \h 19
Exercice 4 : Définition de format de transfert ASN1  PAGEREF _Toc190074248 \h 20
Exercice 5 : Définition de données en ASN1 et de leur format de transfert.  PAGEREF _Toc190074249 \h 20
Exercice 6 : Problème général ASN1  PAGEREF _Toc190074250 \h 21
Exercice 7 : Définition d'une traduction du langage IDL de CORBA vers le langage Pascal  PAGEREF _Toc190074251 \h 22
Exercice 8 : CORBA  PAGEREF _Toc190074252 \h 24
Série d'exercices sécurité  PAGEREF _Toc190074253 \h 29
Exercice 9 : Cryptogramme 1  PAGEREF _Toc190074254 \h 29
Exercice 10 : Cryptogramme n° 2  PAGEREF _Toc190074255 \h 29
Exercice 11 : Cryptogramme n° 3  PAGEREF _Toc190074256 \h 29
Exercice 12 : Etude du système de chiffrement à clé publique RSA  PAGEREF _Toc190074257 \h 30
Exercice 13 : Kerberos  PAGEREF _Toc190074258 \h 31
Exercice 14 : Partage d'un secret  PAGEREF _Toc190074259 \h 34
Exercice 15 : Problème de notarisation  PAGEREF _Toc190074260 \h 34
Exercice 16 : Gestion d'une connexion sécurisée  PAGEREF _Toc190074261 \h 36
Exercice 17 : Changement périodique de clés en cryptographie à clés publiques.  PAGEREF _Toc190074262 \h 38
Exercice 18 : Commerce électronique sur Internet: SET ("Secure Electronic Transactions")  PAGEREF _Toc190074263 \h 41
Exercice 19 : Authentification des usagers et autorisation des requêtes dans le WEB  PAGEREF _Toc190074264 \h 45
Exercice 21 : Sécurisation des communications en Internet avec SSL-TLS  PAGEREF _Toc190074265 \h 49
Exercice 22 : Protocole de micro-paiement sur Internet  PAGEREF _Toc190074266 \h 52
Exercice 23 : Sécurisation du DNS : les normes DNSSEC-1  PAGEREF _Toc190074267 \h 55
TROISIEME CHAPITRE  PAGEREF _Toc190074268 \h 59
EXERCICES APPLICATIONS REPARTIES  PAGEREF _Toc190074269 \h 59
Exercice 1 : Système de fichiers répartis NFS et réplication  PAGEREF _Toc190074270 \h 59
Exercice 2 :Désignation des fichiers dans le système de fichiers répartis NFS  PAGEREF _Toc190074271 \h 60
Exercice 3 : Messagerie X400  PAGEREF _Toc190074272 \h 62
Exercice 4 : Transactionnel réparti OSI-TP  PAGEREF _Toc190074273 \h 64
Exercice 5 : Transactionnel réparti  PAGEREF _Toc190074274 \h 65
Exercice 6 : Système transactionnel réparti  PAGEREF _Toc190074275 \h 66
Exercice 7 : CORBA et le transactionnel  PAGEREF _Toc190074276 \h 68
Exercice 8 : Administration de réseaux avec SNMP  PAGEREF _Toc190074277 \h 70
Exercice 9 : Échange de données informatisées EDI  PAGEREF _Toc190074278 \h 75
Exercice 10 : XML  PAGEREF _Toc190074279 \h 77
Exercice 11 : Étude du protocole HTTP  PAGEREF _Toc190074280 \h 79
Exercice 12 : DNS ('Domain Name System') sujet 1  PAGEREF _Toc190074281 \h 82
Exercice 13 : DNS ('Domain Name System') Sujet 2  PAGEREF _Toc190074282 \h 84
Exercice 14 : Services et protocoles d'annuaires répartis  PAGEREF _Toc190074283 \h 85
Exercice 15 : Messagerie Internet SMTP  PAGEREF _Toc190074284 \h 91
Exercice 16 : DNS et messagerie Internet/l'approche SPF  PAGEREF _Toc190074285 \h 96
Exercice 17 : Messagerie Internet: Analyse du contenu d'un courrier  PAGEREF _Toc190074286 \h 98
Exercice 18 : Utilisation d'un résolveur DNS  PAGEREF _Toc190074287 \h 101
Exercice 19 : IMAP (‘Internet Message Access Protocol’)  PAGEREF _Toc190074288 \h 104
Exercice 20 : WAP ('Wireless Application Protocol')  PAGEREF _Toc190074289 \h 106
Exercice 21 : Services sur la toile ('Web Services')  PAGEREF _Toc190074290 \h 111
Exercice 22 : Protocole SIP ('Session Initiation Protocol')  PAGEREF _Toc190074291 \h 115
Exercice 23 : Protocole UPnP ('Universal Plug and Play)  PAGEREF _Toc190074292 \h 120

PREMIER CHAPITRE
EXERCICES CONTROLE REPARTI


Série d'exercices mode message


Exercice 1: Automate de connexion TCP


1) Citez différentes raisons qui justifient l'introduction de la couche transport dans la pile des protocoles de communication OSI.

2) Rappelez les principaux choix de conception du protocole de transport TCP.(quelles sont les fonctions réalisées par TCP?).

3) Une vision partielle de l'automate de l'ouverture de connexion et de la fermeture de connexion en TCP est donnée par la figure page suivante. Déterminez les éléments de service et les éléments de protocole utilisés dans cet automate?

4) Examinez l’automate en suivant les transitions portées en traits gras. Il s’agit d’une ouverture de connexion suivie d’une fermeture. Analysez les principales options de conception de cette séquence de connexion déconnexion en TCP.

5) Complétez la lecture de l’automate en examinant d’autres états et d’autres transitions (ouverture passive, …).
 EMBED Word.Picture.8 


Série d'exercices : Appel de procédure distante


Exercice 2 : Traitement des pertes de messages

On souhaite réaliser très efficacement des appels de procédure distants en se plaçant non pas au dessus d'une couche transport fiable mais au dessus d'une couche réseau sans contrôle d'erreur.
Proposez des solutions efficaces au problème des pertes de messages d'appel et de réponse.


Exercice 3 : Exécutions très longues.

On souhaite exécuter en mode appel de procédure distante des traitements de durée non prévisible (par exemple des interrogations distantes de bases de données dont les réponses peuvent prendre des durées très variables et très longues).
Proposez une solution pour le contrôle de l'exécution distante, en particulier pour pouvoir distinguer une panne de serveur d'une exécution longue.


Exercice 4 : Appels en parallèle (redondance massive)

L'appel distant active une seule procédure à distance à chaque fois. Un utilisateur peut souhaiter faire réaliser n exécutions à distance simultanément en lançant en diffusion une requête.
Explicitez le schéma du fonctionnement ainsi défini.
Utilisez le dans le cas de données répliquées. On suppose que l'on a n serveurs de données en copies multiples (pour la sécurité) qui peuvent réaliser les mêmes opérations lire et écrire. Comment sont réalisées les lectures, les écritures. Quelle propriété minimum doivent satisfaire les requêtes pour maintenir la cohérence des données si l'on considére qu'il n'y a pas de partage de données entre plusieurs activités?


Exercice 5 : Serveurs multiples (redondance sélective)

Dans certains types de service on souhaite disposer de plusieurs instances du même service sur plusieurs machines différentes (par exemple pour un service de compilation). L'appel distant active une seule exécution à distante à chaque fois.
Dans quel but utiliserait-on de tels services à instances multiples?
Proposez une organisation pour rendre efficacement un tel service.


Exercice 6 : Parallélisme et performance des communications en RPC


Un appel de procédure distante présente les caractéristiques temporelles suivantes (valeurs données à titre d'exemple):
Traitements client de préparation d'appel: 5 ms

- Traitements RPC émission de la requête coté client
Traitements de la souche client: 0,5 ms
Traitements logiciels réseaux coté client: 0,3 ms
- Réseau
Acheminement d’un message entre le client et le serveur 3 ms
- Traitements RPC réception de la requête coté serveur
Traitements logiciels réseaux coté serveur: 0,3 ms.
Traitements de la souche serveur: 0,5 ms

Traitements serveur de l’appel (exécution de la procédure): 10 ms

- Traitements RPC émission de la réponse coté serveur
Traitements de la souche serveur: 0,5 ms
Traitements logiciels réseaux coté serveur: 0,3 ms
- Réseau
Acheminement d’un message entre le serveur et le client 3 ms
- Traitements RPC réception de la réponse coté client
Traitements logiciels réseaux coté client: 0,3 ms.
Traitements de la souche client: 0,5 ms
Un client souhaite exécuter sur un même serveur deux appels de procédures distantes indépendantes (non reliées) ayant les caractéristiques temporelles précédentes.

1) On fait l'hypothèse que les RPC sont synchrones. Rappelez la définition d’un RPC synchrone.

2) On fait l'hypothèse que client et serveur travaillent séquentiellement. Le client exécute les deux appels au moyen d’un seul processus séquentiel. La procédure distante est exécutée pour les deux fois par le même processus. Quelle est la durée totale nécessaire à la réalisation des deux appels?

3) On cherche maintenant une exécution parallèle efficace en utilisant le parallélisme chez le client et chez le serveur . La procédure distante est toujours en mode synchrone. Le client et le serveur utilisent des processus sur la machine client et la machine serveur ("multi processing"). Les appels sont donc réalisés sur le client au moyen de deux processus parallèles associés aux deux appels indépendants. Les traitements sont réalisés sur le serveur au moyen de deux processus lancés en parallèle associés à chaque appel de procédure distante. On néglige les temps de commutation de contexte entre les processus. On se place dans le cas de machines mono processeur c’est à dire que les exécutions lancées en parallèles sont exécutées par un seul processeur (pseudo parallélisme).
Dessinez le diagramme d’ordonnancement des opérations dans le cas de l’ordonnancement parallèle le plus efficace des opérations client et serveur. Représentez par des segments verticaux sur un dessin les différentes opérations selon les quatre fils d’exécution associés aux quatre processus Représentez également les messages de requête et de réponse? Quelle est la durée totale du traitement des deux appels?

4) On suppose maintenant que l'on dispose d'un RPC asynchrone. Rappelez la définition d’un RPC asynchrone ?

5) Le RPC asynchrone ne suppose pas l’existence de parallélisme sur le site client pour améliorer les performances. On considère dans cette question, que les clients et serveurs sont purement séquentiels. Le processus client réalise deux appels en RPC asynchrone et le processus serveur réalise les deux traitements des appels asynchrones. Dessinez l’ordonnancement le plus efficace des opérations pour les deux processus associés au client et au serveur. Représentez les messages échangés entre les deux processus. Quelle est la durée totale du traitement des deux appels ?



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.

A) 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);

/* Détermination adresse du serveur */
hp = gethostbyname(server);

/* Remise à zéro de la zone adresse et initialisation adresse du serveur */
memset ((void *) &addr, 0, sizeof addr);
addr.sin_family = AF_INET;
addr.sin_port = htons (port);
memcpy (&addr.sin_addr, hp->h_addr, hp->h_length);

/* Ouverture de la connexion avec le serveur */
connect (sd,(struct sockaddr *)&addr, sizeof addr);
return sd;
}

1) A quoi sert la primitive socket ? Pourquoi utiliser le paramètre AF-INET ? Pourquoi utiliser le paramètre SOCK-STREAM ?

2) A quoi sert la primitive gethostbyname. Quel est le nom de l’application Internet qui est utilisée par la primitive gesthostbyname. Quel doit donc être le format d’un nom de service ?

3) Quel est le rôle de la primitive connect ?

Une seconde procédure utilisée par le client send_request rassemble toutes les instructions nécessaires pour la transmission de la requête.
En paramètre entrée de la procédure, sd est le descriptif de la socket.
En paramètre entrée stock_name contient le nom de la valeur boursière à coter.
Il n’y a pas de résultat (void).

void send_request (HANDLE sd ,const char stock_name[])
{
struct Quote_Request req;
size_t w_bytes;
size_t packet_len;
int n;

/* Détermination longueur du nom de valeur boursière et */
/* recopie du nom de valeur boursière dans la requête */
packet_len = strlen (stock_name);
if (packet_len > MAXSTOCKNAMELEN)
packet_len = MAXSTOCKNAMELEN;
strncpy (req.name, stock_name, packet_len);

/* Calcul longueur totale de la requête et conversion vers l’ordre des octets réseau */
packet_len = packet_len + sizeof req.len;
req.len = htonl (packet_len);

/* Envoyer le message au serveur */
n = send (sd, ((const char *) &req),packet_len , 0);
}

4) Dans la procédure précédente send_request la primitive htonl est appliquée à la longueur du paquet packet_len pour fabriquer la zone req.len (longueur de la requête). Htonl (littéralement ‘host to network long integer’) convertit l’ordre des octets de la machine client dans l’ordre réseau. Pourquoi effectuer une telle conversion. Sous quel nom est connu le problème résolu par htonl?

On rassemble dans la procédure client recv_response la collecte d’un message de réponse à une requête de cotation. La structure de donnée d’un message de réponse Quote_Response a été définie plus haut.

int recv_response (HANDLE sd, long *value)
{
struct Quote_Response res;
recv (sd, (char*) &res, sizeof res, 0);
errno = ntohl (res.errno);
if (errno > 0) /* Erreur */
return -1;
else { /* Succès */
*value = ntohl (res.value);
return 0;
}
}

5) A quoi servent les primitives ntohl utilisées dans le code recv_response ?

6) On souhaite évaluer la solution proposée de programmation client-serveur en mode message avec les sockets relativement à l’assemblage des données dans les messages. Quel est le point de vue adopté relativement aux conversions dans ce programme (quel est le niveau d’interopérabilité de la solution) ?


B) Utilisation de l’approche objets répartis avec Corba


On se propose d’étudier la solution au problème de cotation précédent en utilisant l’approche objet réparti CORBA.

7) Rappelez les principes généraux de l’approche CORBA ? Comment est réalisée l’invocation à distance en CORBA ?


Le code IDL suivant décrit l’accès au serveur de cotation :

module Stock {
exception Invalid_Stock {};
interface Quoter {
long get_quote (in string stock_name)
raises (Invalid_Stock);
};
};

8) A quoi sert la déclaration ‘interface Quoter’. A quoi sert la déclaration ‘long get_quote (in string stock_name)’ (à quoi correspond elle dans le programme socket) ? A quoi sert l’exception exception Invalid_Stock {}; (qu’est ce qu’elle remplace dans le programme socket) ?

Un programme client CORBA pour l’invocation du service de cotation est le suivant:

int main (int argc, char *argv[])
{
// Nom du service de cotation invoqué.
const char *name = "Quoter";
Name service_name;
service_name.length(1);
service_name[0].id = name;

// Obtention objet obj invoqué localement (tous les traitements
// nécessaires sont résumés par une procédure bind_service)
Object_var obj = bind_service (argc, argv, service_name);

int result = 1;
try {

// Obtention d’une référence q sur obj (avec vérification de type)
Quoter_var q = Quoter::_narrow (obj);

// Invocation sur obj du service de cotation distante pour la valeur IBM
const char *stock_name = "IBM";
long value = q->get_quote (stock_name);

// Edition du résultat et traitement des erreurs
cout