4.4 Parallélisme avec des RPC

1. Transfert d'informations de contrôle

Dans quels cas a-t-on besoin de contrôle à distance ?

. Dans la plupart des applications réparties, il faut transmettre non
seulement des données mais aussi des informations de contrôle
. Exemples:
o il faut pouvoir faire les mêmes opérations sur les fichiers
distants que sur les fichiers locaux
. transfert de données (read, write)
. contrôle (open, lock, close, fcntl)
o périphériques distants idem + ioctl
o services distants [pic]par exemple impression.
Les informations de contrôle ne doivent pas être traitées comme des
données
. Comment faire la différence sur le réseau entre données et
informations de contrôle?
exemple
flow control: [pic]
[pic]
si la file d'entrée du processus A est pleine [pic]En réalité, afin de
disposer d'un peu de mou, un ordre «source squench» est en général
envoyé quand un certain niveau de remplissage est atteint, pas quand
elle est complètement saturée et si A demande au processus B d'arrêter
d'émettre, celui-ci devrait s'arrêter immédiatement, et non après
avoir traité ce qui se trouve avant la demande d'arrêt dans la file.
. Les solutions possibles avec les sockets TCP/IP sont:
a. insérer les informations de contrôle dans le flux de données
ordinaires
o il faut des entêtes pour distinguer informations de contrôle et
données [pic]Dans le champ "user data" de datagrammes ou dans le
flot de données.
o les informations ne seront traitées par le récepteur que quand
toutes les données précédentes auront été traitées.
b. utiliser une deuxième association pour les informations de contrôle
c. utiliser une seule association et des données exprèsses
o un canal distinct de faible capacité pour les informations de
contrôle
o dépassent les données du canal principal (on traite d'abord les
données exprèsses)
données exprèsses «OUT-OF-BAND (OOB) data» avec les sockets:
. TCP supporte des données exprèsses=> disponible quand
utilise des sockets STREAM avec TCP
. émission de données exprèsses: asserter le flag MSG_OOB
dans send
Exemple:
|send(int sd, char *ctlmsg, int ctlmsglen, |
|MSG_OOB); |


. réception de données exprèsses: asserter le flag MSG_OOB
dans recv
. quand faut-il lire les données exprèsses: [pic]La raison
d'être du canal spécial pour les données exprèsses est que
les données envoyées par ce canal doivent être lues dès
qu'elles arrivent et doivent subir un traitement spécial
utiliser select()
|fd_set dataset, ctlset; [pic]Ensembles de descripteurs de |
|fichiers pour les données à lire et les infos de contrôle à|
|recevoir. |
|int sdw, sd2; [pic]descripteurs de sockets, nous supposons |
|que l'association TCP est déjà établie. |
|char ctlmsg[MSGLEN]; [pic]undefined |
|FD_ZERO (& dataset); FD_ZERO(&ctlset); |
|[pic]Supposons que nous ayons ouvert une connexion (sockets|
|sdw, sd2), 1 fichier + stdin, stdout, stderr. |
|FD_SET(sd2, &dataset); FD_SET(sd2, &ctlset); |
| |
|select(NBR_FD,&dataset, 0, &ctlset, 0); [pic]le premier 0 |
|signifie: nous n'écrivons pas |
|le second 0 signifie: pas de time-out: attendez |
|indéfiniment. |


. La seule exception qui peut se produire sur un socket TCP
socket est l'arrivée de données exprèsses:
|if (FD_ISSET(sd2, &ctlset)) { |
|recv(sd2, &ctlmsg, MSGLEN, MSG_OOB); /*process ctlmsg here|
|*/ |
|} else { |
|recv(sd2, &buf, BUFLEN, 0); /* process data received in |
|buf */ |
|} |


d. il est aussi possible de demander d'insérer les données exprèsses
dans le flot de données ordinaires
o extraire les données exprèsses du flot de données est plus
difficile que d'un canal distinct
o les données exprèsses peuvent servir de séparateur entre les
données reçues avant (parfois à jeter) et celles reçues après
les données exprèsses
o si elles sont insérées dans le flot de données ordinaires, elles
ne risquent pas de se perdre
sinon, si les données exprèsses arrivent à un rythme plus élevé
que celui auquel on peut les traiter, on risque d'en perdre
o pour demander d'insérer les données exprèsses dans le flot de
données ordinaires:
|int optval = 1; |
|setsockopt (sd2, SOL_SOCKET, SO_OOBINLINE, |
|&optval,sizeof(optval)); |


o select annonce l'arrivée de données exprèsses dans le flot de
données comme il le ferait dans le canal spécial
o pour localiser les données exprèsses dans le flot de données
ordinaires, utilisez read (ou recv etc...) et ioctl [pic]Si des
données exprèsses devaient se trouver dans les données à lire,
l'appel système «read» donnerait moins de bytes que demandé et
il s'arrêterait juste avant les données esprèsses
. read ne mélange jamais données ordinaires et données
exprèsses
. ioctl permet de vérifier si le prochain byte à lire est le
début des données exprèsses
|#include |
| |
| |
|int atoobmark; |
|ioctl(sd2, SIOCATMARK, |
|&atoobmark); |
|if (atoobmark){ |
|/* read OOB data */ |
|} else { |
|/* read more regular data */ |
|} |


e. il est également possible d'être prévenu de l'arrivée de données
exprèsses au moyen du signal SIGURG
[pic]En fait, SIGURG permet le traitement asynchrone des données
exprèsses de la même manière que SIGIO le permet pour les données
ordinaires
Le mécanisme est le même que celui de SIGIO pour les I/O asynchrones
[pic]L'agent local pourrait aussi être incorporé au noyau plutôt que
dans un processus utilisateur. Cette approche a été retenue pour le
système RFS pour implémenter l'accès à des périphériques distants

2. Architecture du client local

. La manière d'accéder à des ressources distantes, que ce soit pour y
transférer des données ou pour les contrôler se fait de façon
différente que l'accès à des ressources locales.
|local | |distant |
| |
|open | |socket |
|read, | |read, write, |
|write | |send, recv |
|ioctl | |OOB message |
|fcntl | |OOB message |


. Est-il souhaitable que le processus utilisateur se rende compte que
ses ressources sont distantes ?
|si |
|OUI |


o le programme utilisateur doit être modifié pour pouvoir utiliser
aussi des ressources distantes, ou il faut deux programmes
différents pour les ressources locales et distantes.
examples:
. back up sur une unité à bande locale: dump
. back up sur une unité à bande distante: rdump (utilise un
serveur appelé /etc/rmt)

Le client=le processus utilisateur modifié (ou spécial)
Le serveur=le processus distant qui accède à la ressource
|Si NON|


o le processus utilisateur local n'est pas modifié
o une ressource virtuelle est nécessaire localement dans le
système (pseudo pilote de périphérique)
o les requêtes adressées à la ressource virtuelle doivent, par
exemple, être redirigées vers un processus agent local
o le processus agent local transmet la requète au serveur distant
et, le cas échéant, reçoit les résultats. [pic]
[pic]
[pic]L'agent local est un processus utilisateur afin d'avoir une
entité ordonnancée qui puisse attendre les réponses aux requêtes
envoyées au serveur distant.
o Le seul pseudo pilote de périphérique disponible actuellement
est la pseudo interface terminal (pty).
Pourquoi: il y a tellement de programmes qui utilisent les
terminaux qu'il eût été impensable de les modifier tous!
D'autres périphériquess (p. ex.. les dispositifs de back up) ne
sont utilisés que par quelques programmes. [pic]Il était plus
facile de ne modifier que le programme "dump"
Note: RFS, qui implémente l'accès à distance à tous les
périphériques, a été conçu plus de 5 ans après les sockets et
les pty's.
. Exemple TELNET [pic]
[pic]
Note importante
L'utilisateur humain est sur un terminal de la machine B.
Il décide d'utiliser un processus de la machine A
=> telnet est l'initiateur de l'association; telnetd est le répondeur
telnet est appelé client et telnetd est appelé server dans ce cas
[pic]Les sockets ne sont pas une interface de