Selon l'expert bien connu dans le domaine de l'informatique E. Tanenbaum, il n'y a pas de définition généralement acceptée et en même temps stricte d'un système distribué. Certains esprits soutiennent que la distribution est telle système informatique, dans lequel un dysfonctionnement d'un ordinateur, dont les utilisateurs ne soupçonnaient même pas l'existence auparavant, entraîne l'arrêt de tous leurs travaux. Une partie importante des systèmes informatiques distribués, malheureusement, satisfont à cette définition, mais formellement, il ne se réfère qu'aux systèmes avec un point de vulnérabilité unique ( point de défaillance unique).

Souvent, lors de la définition d'un système distribué, l'accent est mis sur la répartition de ses fonctions entre plusieurs ordinateurs. Avec cette approche, tout est distribué système informatique où le traitement des données est réparti entre deux ou plusieurs ordinateurs. Sur la base de la définition d'E. Tanenbaum, un système distribué un peu plus étroitement peut être défini comme un ensemble d'ordinateurs indépendants connectés par des canaux de communication, qui, du point de vue d'un utilisateur de certains logiciels, ressemblent à un tout.

Cette approche pour définir un système distribué a ses inconvénients. Par exemple, tout ce qui est utilisé dans un tel système distribué Logiciel pourrait fonctionner sur un seul ordinateur, mais du point de vue de la définition ci-dessus, un tel système ne sera plus distribué. Par conséquent, le concept d'un système distribué devrait probablement être basé sur l'analyse du logiciel qui forme un tel système.

Comme base pour décrire l'interaction de deux entités, considérons le modèle général d'interaction client-serveur, dans lequel l'une des parties (le client) initie l'échange de données en envoyant une requête à l'autre partie (le serveur). Le serveur traite la requête et, si nécessaire, envoie une réponse au client (Fig. 1.1).

Riz. 1.1.

L'interaction dans le cadre du modèle client-serveur peut être soit synchrone, lorsque le client attend que le serveur traite sa requête, soit asynchrone, dans laquelle le client envoie une requête au serveur et poursuit son exécution sans attendre la réponse. Le modèle client et serveur peut être utilisé comme base pour décrire diverses interactions. Pour ce cours, l'interaction des éléments constitutifs du logiciel qui forme un système distribué est importante.

Riz. 1.2.

Considérons une certaine application typique, qui, conformément aux concepts modernes, peut être divisée en niveaux logiques suivants (Fig. 1.2): interface utilisateur(PI), logique d'application (LP) et accès aux données (DD), travaillant avec la base de données (DB). L'utilisateur du système interagit avec lui via l'interface utilisateur, la base de données stocke des données décrivant le domaine d'application et la couche logique d'application implémente tous les algorithmes liés à Domaine.

Étant donné que, dans la pratique, différents utilisateurs du système sont généralement intéressés à accéder aux mêmes données, la séparation la plus simple des fonctions d'un tel système entre plusieurs ordinateurs sera la séparation des couches logiques de l'application entre une partie serveur de l'application. responsable de l'accès aux données et aux parties clientes situées sur plusieurs ordinateurs mettant en œuvre l'interface utilisateur. La logique d'application peut être attribuée au serveur, aux clients ou partagée entre eux (Figure 1.3).

Riz. 1.3.

L'architecture des applications construites sur ce principe est appelée client-serveur ou bi-tiers. En pratique, de tels systèmes ne sont souvent pas classés comme distribués, mais formellement, ils peuvent être considérés comme les représentants les plus simples des systèmes distribués.

Le développement de l'architecture client-serveur est une architecture à trois niveaux, dans laquelle l'interface utilisateur, la logique d'application et l'accès aux données sont séparés en composants indépendants du système qui peuvent fonctionner sur des ordinateurs indépendants (Fig. 1.4).

Riz. 1.4.

La demande de l'utilisateur dans de tels systèmes est traitée séquentiellement par la partie cliente du système, le serveur logique d'application et le serveur de base de données. Cependant, un système distribué est généralement compris comme un système avec une architecture plus complexe qu'un système à trois niveaux.

Dans le chapitre précédent, nous avons examiné des systèmes multiprocesseurs étroitement couplés avec une mémoire partagée, des structures de données de noyau partagées et un pool partagé à partir duquel les processus sont appelés. Souvent, cependant, il est souhaitable d'allouer les processeurs de manière à ce qu'ils soient autonomes par rapport à l'environnement d'exploitation et aux conditions d'exploitation à des fins de partage des ressources. Supposons, par exemple, qu'un utilisateur d'un ordinateur personnel ait besoin d'accéder à des fichiers situés sur une machine plus grande, tout en conservant le contrôle de l'ordinateur personnel. Bien que certains programmes, tels que uucp, prennent en charge le transfert de fichiers réseau et d'autres fonctions réseau, leur utilisation ne sera pas cachée à l'utilisateur, car l'utilisateur sait qu'il utilise le réseau. De plus, il convient de noter que les programmes tels que les éditeurs de texte ne fonctionnent pas avec les fichiers supprimés, comme avec les fichiers ordinaires. Les utilisateurs doivent disposer de l'ensemble standard des fonctions du système UNIX et, mis à part le goulot d'étranglement potentiel des performances, ne doivent pas ressentir le franchissement des limites de la machine. Ainsi, par exemple, le travail des fonctions système ouvertes et lues avec des fichiers sur des machines distantes ne devrait pas différer de leur travail avec des fichiers appartenant à des systèmes locaux.

L'architecture du système distribué est illustrée à la Figure 13.1. Chaque ordinateur illustré dans la figure est une unité autonome composée d'un processeur, d'une mémoire et de périphériques. Le modèle ne casse pas même si l'ordinateur n'a pas de système de fichiers local : il doit avoir des périphériques pour communiquer avec d'autres machines, et tous les fichiers qui lui appartiennent peuvent se trouver sur un autre ordinateur. La mémoire physique disponible pour chaque machine est indépendante des processus exécutés sur les autres machines. À cet égard, les systèmes distribués diffèrent des systèmes multiprocesseurs étroitement couplés discutés dans le chapitre précédent. En conséquence, le cœur du système sur chaque machine fonctionne indépendamment des conditions de fonctionnement externes de l'environnement distribué.

Graphique 13.1. Modèle de système d'architecture distribuée

Les systèmes distribués, bien décrits dans la littérature, entrent traditionnellement dans les catégories suivantes :

Les systèmes périphériques, qui sont des groupes de machines qui ont une forte similitude et sont associés à une machine (généralement plus grande). Les processeurs périphériques partagent leur charge avec le processeur central et lui transfèrent tous les appels vers le système d'exploitation. L'objectif d'un système périphérique est d'augmenter les performances globales du réseau et de fournir la possibilité d'allouer un processeur à un seul processus dans un environnement d'exploitation UNIX. Le système démarre en tant que module séparé ; Contrairement à d'autres modèles de systèmes distribués, les systèmes périphériques ne disposent pas d'une réelle autonomie, sauf dans les cas liés au dispatching des processus et à l'allocation de mémoire locale.

Systèmes distribués tels que "Newcastle", permettant la communication à distance par les noms de fichiers distants dans la bibliothèque (le nom est tiré de l'article "The Newcastle Connection" - voir). Les fichiers supprimés ont une nomenclature (nom distinctif) qui, dans le chemin de recherche, contient des caractères spéciaux ou un composant de nom facultatif qui précède la racine du système de fichiers. La mise en œuvre de cette méthode n'implique pas d'apporter des modifications au noyau du système, et par conséquent, elle est plus simple que les autres méthodes décrites dans ce chapitre, mais moins flexible.

Les systèmes distribués sont complètement transparents, dans lesquels les noms distinctifs standard sont suffisants pour faire référence à des fichiers situés sur d'autres machines ; c'est au noyau de reconnaître ces fichiers comme supprimés. Les chemins de recherche de fichiers spécifiés dans leurs noms composites traversent les frontières de la machine aux points de montage, quel que soit le nombre de ces points formés lorsque les systèmes de fichiers sont montés sur des disques.

Dans ce chapitre, nous examinerons l'architecture de chaque modèle ; toutes les informations fournies ne sont pas basées sur les résultats de développements spécifiques, mais sur des informations publiées dans divers articles techniques. Cela suppose que les modules de protocole et les pilotes de périphérique sont responsables de l'adressage, du routage, du contrôle de flux, de la détection et de la correction des erreurs, en d'autres termes, que chaque modèle est indépendant du réseau utilisé. Les exemples d'utilisation des fonctions système présentés dans la section suivante pour les systèmes périphériques fonctionnent de manière similaire pour des systèmes comme Newcastle et pour des systèmes complètement transparents, ce qui sera discuté plus tard ; par conséquent, nous les examinerons en détail une fois, et dans les sections consacrées aux autres types de systèmes, nous nous concentrerons principalement sur les caractéristiques qui distinguent ces modèles de tous les autres.

13.1 PROCESSEURS PÉRIPHÉRIQUES

L'architecture du système périphérique est illustrée à la figure 13.2. L'objectif de cette configuration est d'améliorer les performances globales du réseau en réaffectant les processus en cours d'exécution entre le CPU et les processeurs périphériques. Chacun des processeurs périphériques ne dispose pas d'autres périphériques locaux que ceux dont il a besoin pour communiquer avec l'unité centrale. Le système de fichiers et tous les périphériques sont à la disposition du processeur central. Supposons que tous les processus utilisateur soient exécutés sur le processeur périphérique et ne se déplacent pas entre les processeurs périphériques ; une fois transférés au processeur, ils y restent jusqu'à la fin. Le processeur périphérique contient une version allégée du système d'exploitation, conçue pour gérer les appels locaux au système, la gestion des interruptions, l'allocation de mémoire, le travail avec les protocoles réseau et avec un pilote de périphérique pour la communication avec le processeur central.

Lorsque le système est initialisé sur le processeur central, le cœur charge le système d'exploitation local sur chacun des processeurs périphériques via des lignes de communication. Tout processus s'exécutant sur la périphérie est associé à un processus satellite appartenant au processeur central (voir) ; lorsqu'un processus s'exécutant sur un processeur périphérique appelle une fonction système qui requiert uniquement les services du processeur central, le processus périphérique communique avec son satellite et la requête est envoyée au processeur central pour traitement. Le processus satellite exécute une fonction système et renvoie les résultats au processeur périphérique. La relation entre un processus périphérique et son satellite est similaire à la relation client-serveur dont nous avons parlé en détail au chapitre 11 : le processus périphérique agit comme un client de son satellite, qui prend en charge les fonctions de travail avec le système de fichiers. Dans ce cas, le processus du serveur distant n'a qu'un seul client. Dans la section 13.4, nous examinerons les processus serveur avec plusieurs clients.

Graphique 13.2. Configuration du système périphérique

Graphique 13.3. Formats des messages

Lorsqu'un processus périphérique appelle une fonction système qui peut être traitée localement, le noyau n'a pas besoin d'envoyer une requête au processus satellite. Ainsi, par exemple, afin d'obtenir de la mémoire supplémentaire, un processus peut appeler la fonction sbrk pour une exécution locale. Cependant, si les services du processeur central sont requis, par exemple, pour ouvrir un fichier, le noyau encode les informations sur les paramètres passés à la fonction appelée et les conditions d'exécution du processus dans un message envoyé au processus satellite (Figure 13.3). Le message comprend un signe d'où il résulte que la fonction système est exécutée par le processus satellite pour le compte du client, des paramètres transmis à la fonction et des données sur l'environnement d'exécution du processus (par exemple, des codes d'identification d'utilisateur et de groupe), qui sont différent pour différentes fonctions. Le reste du message est constitué de données de longueur variable (par exemple, un nom de fichier composé ou des données à écrire avec la fonction d'écriture).

Le processus satellite attend les requêtes du processus périphérique ; lorsqu'une requête est reçue, il décode le message, détermine le type de fonction système, l'exécute et convertit les résultats en une réponse envoyée au processus périphérique. La réponse, en plus des résultats de l'exécution de la fonction système, comprend le message d'erreur (le cas échéant), le numéro de signal et un tableau de données de longueur variable contenant, par exemple, des informations lues à partir d'un fichier. Le processus périphérique est suspendu jusqu'à réception d'une réponse, après l'avoir reçue, il décrypte et transmet les résultats à l'utilisateur. Il s'agit du schéma général de gestion des appels au système d'exploitation ; Passons maintenant à un examen plus détaillé des fonctions individuelles.

Pour expliquer le fonctionnement du système périphérique, considérez un certain nombre de fonctions : getppid, open, write, fork, exit et signal. La fonction getppid est assez simple car elle traite de simples formulaires de demande et de réponse qui sont échangés entre le périphérique et le CPU. Le cœur sur le processeur périphérique génère un message qui a un signe, d'où il suit que la fonction demandée est la fonction getppid, et envoie la requête au processeur central. Le processus satellite sur le processeur central lit le message du processeur périphérique, décrypte le type de fonction système, l'exécute et obtient l'identifiant de son parent. Il génère ensuite une réponse et la transmet à un processus périphérique en attente à l'autre extrémité de la ligne de communication. Lorsque le processeur périphérique reçoit une réponse, il la transmet au processus qui a appelé la fonction système getppid. Si le processus périphérique stocke des données (telles que l'ID de processus du parent) dans la mémoire locale, il n'a pas du tout besoin de communiquer avec son compagnon.

Si la fonction système ouvert est appelée, le processus périphérique envoie un message à son compagnon, qui inclut le nom du fichier et d'autres paramètres. En cas de succès, le processus compagnon alloue un index et un point d'entrée à la table de fichiers, alloue une entrée dans la table de descripteurs de fichiers utilisateur dans son espace et renvoie le descripteur de fichier au processus périphérique. Pendant tout ce temps, à l'autre bout de la ligne de communication, le processus périphérique attend une réponse. Il ne dispose d'aucune structure permettant de stocker des informations sur le dossier en cours d'ouverture ; Le descripteur renvoyé par open est un pointeur vers une entrée du processus compagnon dans la table de descripteur de fichier utilisateur. Les résultats de l'exécution de la fonction sont illustrés à la figure 13.4.

Graphique 13.4. Appel de la fonction open à partir d'un processus périphérique

Si un appel à la fonction système d'écriture est effectué, le processeur périphérique génère un message composé d'un signe de la fonction d'écriture, d'un descripteur de fichier et de la quantité de données à écrire. Ensuite, à partir de l'espace du processus périphérique, il copie les données vers le processus satellite via la ligne de communication. Le processus satellite décrypte le message reçu, lit les données de la ligne de communication et les écrit dans le fichier correspondant (le descripteur contenu dans le message est utilisé comme pointeur vers l'index duquel et l'enregistrement à propos duquel dans la table des fichiers est utilisé ); toutes ces actions sont effectuées sur le processeur central. A la fin du travail, le processus satellite envoie au processus périphérique un message qui confirme la réception du message et contient le nombre d'octets de données qui ont été copiés avec succès dans le fichier. L'opération de lecture est similaire ; le satellite informe le processus périphérique du nombre d'octets réellement lus (en cas de lecture de données d'un terminal ou d'un canal, ce nombre ne coïncide pas toujours avec le nombre spécifié dans la requête). Pour exécuter l'une ou l'autre fonction, il peut être nécessaire d'envoyer plusieurs fois des messages d'information sur le réseau, ce qui est déterminé par la quantité de données envoyées et la taille des paquets réseau.

La seule fonction qui doit être modifiée lors de l'exécution sur le processeur est la fonction du système de fourche. Lorsqu'un processus exécute cette fonction sur le CPU, le noyau sélectionne un processeur périphérique pour lui et envoie un message à un processus spécial - le serveur, informant ce dernier qu'il va commencer à décharger le processus en cours. En supposant que le serveur a accepté la demande, le noyau utilise fork pour créer un nouveau processus périphérique, allouant une entrée de table de processus et un espace d'adressage. Le processeur central décharge une copie du processus qui a appelé la fonction de fourche au processeur périphérique, écrasant l'espace d'adressage nouvellement alloué, génère un satellite local pour communiquer avec le nouveau processus périphérique et envoie un message au périphérique pour initialiser le compteur de programme pour le nouveau processus. Le processus satellite (sur le CPU) est un descendant du processus appelé fork ; un processus périphérique est techniquement un descendant du processus serveur, mais logiquement c'est un descendant du processus qui a appelé la fonction fork. Le processus serveur n'a aucune connexion logique avec l'enfant lorsque le fork se termine ; le seul travail du serveur est d'aider à décharger l'enfant. Du fait de la forte connexion entre les composants du système (les processeurs périphériques n'ont pas d'autonomie), le processus périphérique et le processus satellite ont le même code d'identification. La relation entre les processus est illustrée à la figure 13.5 : la ligne continue montre la relation parent-enfant et la ligne pointillée montre la relation entre les pairs.

Graphique 13.5. Exécuter une fonction fork sur le CPU

Lorsqu'un processus exécute la fonction fork sur le processeur périphérique, il envoie un message à son satellite sur le CPU, qui exécute alors toute la séquence d'actions décrite ci-dessus. Le satellite sélectionne un nouveau processeur périphérique et fait les préparatifs nécessaires pour décharger l'image de l'ancien processus : il envoie une requête au processus périphérique parent pour lire son image, en réponse à laquelle le transfert des données demandées commence à l'autre extrémité du canal de communication. Le satellite lit l'image transmise et l'écrase sur le descendant périphérique. Lorsque le déchargement de l'image est terminé, le satellite traite le fork, créant son fils sur le CPU, et passe la valeur du compteur programme au périphérique fils pour que ce dernier sache à partir de quelle adresse commencer l'exécution. Évidemment, il serait préférable que le fils du processus compagnon soit affecté au fils périphérique en tant que parent, mais dans notre cas, les processus générés sont capables de s'exécuter sur d'autres processeurs périphériques, pas seulement celui sur lequel ils sont créés. La relation entre les processus à la fin de la fonction fork est illustrée à la figure 13.6. Lorsque le processus périphérique termine son travail, il envoie un message correspondant au processus satellite, et cela se termine également. Un processus compagnon ne peut pas initier un arrêt.

Graphique 13.6. Exécuter une fonction fork sur un processeur périphérique

Dans les systèmes multiprocesseurs et monoprocesseurs, le processus doit répondre aux signaux de la même manière : le processus soit termine l'exécution de la fonction système avant de vérifier les signaux, soit, au contraire, à la réception du signal, sort immédiatement de l'état suspendu et interrompt brutalement le travail de la fonction système, si cela est conforme à la priorité avec laquelle il a été suspendu. Le processus satellite assurant des fonctions système pour le compte du processus périphérique, il doit répondre aux signaux en coordination avec ce dernier. Si, sur un système monoprocesseur, un signal provoque l'abandon de la fonction par un processus, le processus compagnon sur un système multiprocesseur doit se comporter de la même manière. La même chose peut être dite du cas où le signal invite le processus à terminer son travail à l'aide de la fonction de sortie : le processus périphérique se termine et envoie le message correspondant au processus satellite, qui, bien sûr, se termine également.

Lorsqu'un processus périphérique appelle la fonction de système de signal, il stocke les informations actuelles dans des tables locales et envoie un message à son satellite l'informant si le signal spécifié doit être reçu ou ignoré. Le processus satellite ne se soucie pas de savoir s'il intercepte le signal ou l'action par défaut. La réaction d'un processus à un signal dépend de trois facteurs (Figure 13.7) : si un signal est reçu pendant que le processus exécute une fonction système, si une indication est faite en utilisant la fonction de signal pour ignorer le signal, si le signal se produit sur le même processeur périphérique ou sur un autre. Passons à l'examen des différentes possibilités.

algorithme sighandle / * algorithme de traitement du signal * /

if (le processus actuel est le compagnon de quelqu'un ou a un prototype)

si (le signal est ignoré)

if (le signal est arrivé pendant l'exécution d'une fonction système)

mettre un signal devant le processus satellite;

envoyer un message de signal à un processus périphérique ;

else (/ * processus périphérique * /

/ * si un signal a été reçu pendant l'exécution d'une fonction système ou non * /

envoyer un signal au processus satellite ;

algorithme satellite_end_of_syscall / * terminaison d'une fonction système appelée par un processus périphérique * /

information d'entrée: absent

empreinte : aucune

if (une interruption a été reçue pendant l'exécution d'une fonction système)

envoyer un message d'interruption, un signal au processus périphérique ;

else / * l'exécution de la fonction système n'a pas été interrompue * /

envoyer la réponse : activez le drapeau indiquant l'arrivée du signal ;

Graphique 13.7. Traitement du signal dans le système périphérique

Supposons qu'un processus périphérique ait suspendu son travail pendant que le processus satellite exécute une fonction système en son nom. Si le signal se produit ailleurs, le processus satellite le détecte plus tôt que le processus périphérique. Trois cas sont possibles.

1. Si, en attendant un événement, le processus satellite n'est pas entré dans l'état suspendu, dont il sortirait à la réception d'un signal, il exécute la fonction système jusqu'à la fin, envoie les résultats de l'exécution au processus périphérique et affiche lequel des signaux il a reçu.

2. Si le processus demande d'ignorer ce type de signal, le satellite continue de suivre l'algorithme d'exécution de la fonction système sans quitter l'état suspendu par longjmp. Dans la réponse envoyée au processus périphérique, il n'y aura pas de message de réception de signal.

3. Si, à la réception d'un signal, le processus satellite interrompt l'exécution d'une fonction système (par longjmp), il en informe le processus périphérique et lui communique le numéro du signal.

Le processus périphérique recherche des informations sur la réception de signaux dans la réponse reçue et, le cas échéant, traite les signaux avant de quitter la fonction système. Ainsi, le comportement d'un processus dans un système multiprocesseur correspond exactement à son comportement dans un système monoprocesseur : soit il sort sans quitter le mode noyau, soit il appelle une fonction de traitement de signal personnalisée, soit il ignore le signal et termine avec succès la fonction système.

Graphique 13.8. Interruption pendant l'exécution d'une fonction système

Supposons, par exemple, qu'un processus périphérique appelle une fonction de lecture à partir d'un terminal connecté au processeur central et interrompe son travail pendant que le processus satellite exécute la fonction (figure 13.8). Si l'utilisateur appuie sur la touche pause, le cœur du processeur envoie un signal au processus satellite. Si le satellite était dans un état suspendu, en attente d'une partie des données du terminal, il sort immédiatement de cet état et termine la fonction de lecture. Dans sa réponse à une requête d'un processus périphérique, le satellite fournit un code d'erreur et un numéro de signal correspondant à l'interruption. Le processus périphérique analyse la réponse et, puisque le message indique qu'une interruption est arrivée, s'envoie le signal. Avant de quitter la fonction de lecture, le noyau périphérique vérifie la signalisation, détecte un signal d'interruption du processus satellite et le traite comme d'habitude. Si, suite à la réception d'un signal d'interruption, le processus périphérique termine son travail en utilisant la fonction de sortie, cette fonction se charge de tuer le processus satellite. Si le processus périphérique intercepte des signaux d'interruption, il appelle la fonction de gestion des signaux définie par l'utilisateur et renvoie un code d'erreur à l'utilisateur lorsqu'il quitte la fonction de lecture. D'autre part, si le satellite exécute la fonction système stat pour le compte du processus périphérique, il n'interrompra pas son exécution lorsqu'il recevra un signal (la fonction stat est garantie de sortir de toute pause, car elle a un temps d'attente de ressource limité ). Le satellite termine l'exécution de la fonction et renvoie le numéro de signal au processus périphérique. Le processus périphérique s'envoie un signal et le reçoit en sortie de la fonction système.

Si un signal survient sur le processeur périphérique lors de l'exécution d'une fonction système, le processus périphérique ne sait pas s'il va bientôt reprendre le contrôle du processus satellite ou si ce dernier passe indéfiniment dans un état suspendu. Le processus périphérique envoie un message spécial au satellite, l'informant de l'apparition d'un signal. Le noyau du CPU décrypte le message et envoie un signal au satellite, dont la réaction à la réception du signal est décrite dans les paragraphes précédents (arrêt anormal de l'exécution de la fonction ou son achèvement). Le processus périphérique ne peut pas envoyer de message directement au satellite car le satellite est occupé à exécuter une fonction système et ne lit pas les données de la ligne de communication.

En se référant à l'exemple lu, il convient de noter que le processus périphérique n'a aucune idée si son compagnon attend une entrée du terminal ou exécute d'autres actions. Le processus périphérique envoie un message de signal au satellite : si le satellite est dans un état suspendu avec une priorité interruptible, il sort immédiatement de cet état et met fin à la fonction système ; sinon, la fonction est reportée jusqu'à l'achèvement réussi.

Enfin, considérons le cas de l'arrivée d'un signal à un instant non associé à l'exécution d'une fonction système. Si un signal provient d'un autre processeur, le satellite le reçoit en premier et envoie un message de signal au processus périphérique, que le signal concerne le processus périphérique ou non. Le noyau périphérique décrypte le message et envoie un signal au processus, qui y réagit de la manière habituelle. Si le signal provient du processeur périphérique, le processus effectue des actions standards sans recourir aux services de son satellite.

Lorsqu'un processus périphérique envoie un signal à d'autres processus périphériques, il code un message kill call et l'envoie au processus satellite, qui exécute la fonction appelée localement. Si certains des processus auxquels le signal est destiné se trouvent sur d'autres processeurs périphériques, leurs satellites recevront le signal (et y réagiront comme décrit ci-dessus).

13.2 TYPE DE COMMUNICATION NEWCASTLE

Dans la section précédente, nous avons considéré un type de système étroitement couplé, caractérisé par l'envoi de tous les appels aux fonctions du sous-système de gestion de fichiers qui surviennent sur le processeur périphérique à un processeur distant (central). Passons maintenant à l'examen des systèmes avec une connexion plus faible, qui consistent en des machines qui font des appels à des fichiers situés sur d'autres machines. Dans un réseau d'ordinateurs personnels et de postes de travail, par exemple, les utilisateurs accèdent souvent à des fichiers situés sur une grande machine. Dans les deux sections suivantes, nous examinerons les configurations système dans lesquelles toutes les fonctions système sont exécutées dans des sous-systèmes locaux, mais en même temps, il est possible d'accéder aux fichiers (via les fonctions du sous-système de gestion de fichiers) situés sur d'autres machines.

Ces systèmes utilisent l'un des deux chemins suivants pour identifier les fichiers supprimés. Sur certains systèmes, un caractère spécial est ajouté au nom de fichier composite : le composant de nom qui précède ce caractère identifie la machine, le reste du nom est le fichier sur cette machine. Ainsi, par exemple, le nom distinctif

"sftig! / fs1 / mjb / rje"

identifie le fichier "/fs1/mjb/rje" sur la machine "sftig". Ce schéma d'identification de fichier suit la convention uucp pour le transfert de fichiers entre des systèmes de type UNIX. Dans un autre schéma, les fichiers supprimés sont identifiés en ajoutant un préfixe spécial au nom, par exemple :

/../sftig/fs1/mjb/rje

où "/../" est un préfixe indiquant que le fichier est supprimé ; le deuxième composant du nom de fichier est le nom de la machine distante. Ce schéma utilise la syntaxe de nom de fichier UNIX familière, donc contrairement au premier schéma, les programmes utilisateur n'ont pas besoin de s'adapter à l'utilisation de noms avec une construction inhabituelle (voir).

Graphique 13.9. Formuler des requêtes au serveur de fichiers (processeur)

Nous consacrerons le reste de cette section à un modèle de système utilisant un lien Newcastle, dans lequel le noyau ne se préoccupe pas de reconnaître les fichiers supprimés ; cette fonction est entièrement affectée aux sous-programmes de la bibliothèque C standard, qui jouent dans ce cas le rôle d'interface système. Ces routines analysent le premier composant du nom de fichier, qui dans les deux méthodes d'identification décrites contient un signe de l'éloignement du fichier. Il s'agit d'une dérogation à la routine dans laquelle les routines de bibliothèque n'analysent pas les noms de fichiers. La figure 13.9 montre comment les requêtes adressées à un serveur de fichiers sont formulées. Si le fichier est local, le noyau du système local traite la requête normalement. Considérons le cas inverse :

open ("/../ sftig / fs1 / mjb / rje / file", O_RDONLY);

Le sous-programme open de la bibliothèque C analyse les deux premiers composants du nom de fichier distinctif et sait rechercher le fichier sur la machine distante « sftig ». Afin d'avoir des informations sur si le processus avait auparavant une connexion avec une machine donnée, le sous-programme démarre une structure spéciale dans laquelle il se souvient de ce fait, et en cas de réponse négative, établit une connexion avec le serveur de fichiers exécuté sur la télécommande. machine. Lorsque le processus formule sa première demande de télétraitement, le serveur distant confirme la demande, enregistre si nécessaire dans les champs des codes d'identification d'utilisateur et de groupe et crée un processus satellite qui agira pour le compte du processus client.

Pour répondre aux demandes des clients, le satellite doit avoir les mêmes autorisations de fichier sur la machine distante que le client. En d'autres termes, l'utilisateur "mjb" doit avoir les mêmes droits d'accès aux fichiers distants et locaux. Malheureusement, il est possible que le code d'identification du client "mjb" coïncide avec le code d'identification d'un autre client sur la machine distante. Ainsi, les administrateurs système sur les machines fonctionnant sur le réseau doivent soit s'assurer que chaque utilisateur se voit attribuer un code d'identification unique à l'ensemble du réseau, soit effectuer une conversion de code au moment de la formulation d'une demande de service réseau. Si cela n'est pas fait, le processus compagnon aura les droits d'un autre client sur la machine distante.

Un problème plus délicat est d'obtenir les droits de superutilisateur pour travailler avec des fichiers distants. D'une part, le client superutilisateur ne doit pas disposer des mêmes droits sur le système distant afin de ne pas induire en erreur les contrôles de sécurité du système distant. D'un autre côté, certains programmes, s'ils ne disposent pas de droits de superutilisateur, ne pourront tout simplement pas fonctionner. Un exemple d'un tel programme est le programme mkdir (voir chapitre 7), qui crée un nouveau répertoire. Le système distant ne permettrait pas au client de créer un nouveau répertoire car les droits de superutilisateur ne sont pas en vigueur lors de la suppression. Le problème de la création de répertoires distants constitue une raison sérieuse pour réviser la fonction système mkdir dans le sens d'étendre ses capacités à établir automatiquement toutes les connexions nécessaires à l'utilisateur. Cependant, c'est toujours un problème courant que les programmes setuid (tels que le programme mkdir) obtiennent des privilèges de superutilisateur sur les fichiers distants. La meilleure solution à ce problème serait peut-être de définir des caractéristiques supplémentaires pour les fichiers qui décrivent l'accès à ces derniers par les superutilisateurs distants ; Malheureusement, cela nécessiterait des modifications de la structure de l'index du disque (en termes d'ajout de nouveaux champs) et créerait trop de désordre dans les systèmes existants.

Si le sous-programme ouvert réussit, la bibliothèque locale laisse une note correspondante à ce sujet dans une structure accessible à l'utilisateur contenant l'adresse du nœud du réseau, l'ID de processus du processus satellite, le descripteur de fichier et d'autres informations similaires. Les routines de lecture et d'écriture de la bibliothèque déterminent, sur la base du descripteur de fichier, si le fichier est supprimé et, le cas échéant, envoient un message au satellite. Le processus client interagit avec son compagnon dans tous les cas d'accès aux fonctions système qui nécessitent les services d'une machine distante. Si un processus accède à deux fichiers situés sur la même machine distante, il utilise un satellite, mais si les fichiers sont situés sur des machines différentes, deux satellites sont déjà utilisés : un sur chaque machine. Deux satellites sont également utilisés lorsque deux processus accèdent à un fichier sur une machine distante. En invoquant la fonction système par satellite, le processus génère un message qui comprend le numéro de la fonction, le nom du chemin de recherche et d'autres informations nécessaires, similaires à celles incluses dans la structure du message dans le système avec les processeurs périphériques.

Le mécanisme d'exécution des opérations sur le répertoire courant est plus complexe. Lorsque le processus sélectionne un répertoire distant comme répertoire courant, la routine de bibliothèque envoie un message au satellite, qui modifie le répertoire courant, et la routine se souvient que le répertoire est supprimé. Dans tous les cas où le nom du chemin de recherche commence par un caractère autre qu'une barre oblique (/), le sous-programme envoie le nom à la machine distante, où le processus satellite l'achemine depuis le répertoire courant. Si le répertoire courant est local, la routine passe simplement le nom du chemin de recherche au noyau du système local. La fonction chroot système sur un répertoire distant est similaire, mais elle passe inaperçue pour le noyau local ; à proprement parler, le processus peut ignorer cette opération, puisque seule la bibliothèque enregistre son exécution.

Lorsqu'un processus appelle fork, la routine de bibliothèque appropriée envoie des messages à chaque satellite. Les processus satellites se ramifient et envoient leurs identifiants enfants au client parent. Le processus client exécute la fonction système fork, qui transfère le contrôle à l'enfant qu'il génère ; l'enfant local est en dialogue avec l'enfant satellite distant dont les adresses sont stockées par la routine de bibliothèque. Cette interprétation de la fonction fork permet aux processus satellites de contrôler plus facilement les fichiers ouverts et les répertoires actuels. Lorsque le processus travaillant avec les fichiers distants se termine (en appelant la fonction exit), le sous-programme envoie des messages à tous ses satellites distants afin qu'ils fassent de même lorsqu'ils reçoivent le message. Certains aspects de la mise en œuvre des fonctions du système d'exécution et de sortie sont abordés dans les exercices.

L'avantage d'un lien Newcastle est que l'accès d'un processus aux fichiers distants devient transparent (invisible pour l'utilisateur), sans qu'il soit nécessaire de modifier le noyau du système. Cependant, cette évolution présente un certain nombre d'inconvénients. Tout d'abord, lors de sa mise en œuvre, une diminution des performances du système est possible. En raison de l'utilisation de la bibliothèque C étendue, la taille de la mémoire utilisée par chaque processus augmente, même si le processus n'accède pas aux fichiers distants ; la bibliothèque duplique les fonctions du noyau et nécessite plus d'espace mémoire. L'augmentation de la taille des processus allonge la période de démarrage et peut créer plus de conflits pour les ressources mémoire, créant des conditions pour un déchargement et une pagination plus fréquents des tâches. Les requêtes locales seront exécutées plus lentement en raison de l'augmentation de la durée de chaque appel au noyau, et le traitement des requêtes distantes peut également être ralenti, le coût de leur envoi sur le réseau augmente. Le traitement supplémentaire des requêtes distantes au niveau de l'utilisateur augmente le nombre d'opérations de changement de contexte, de déchargement et d'échange. Enfin, pour accéder aux fichiers distants, les programmes doivent être recompilés à l'aide des nouvelles bibliothèques ; les anciens programmes et les modules objets livrés ne pourront pas travailler avec les fichiers distants sans cela. Tous ces inconvénients sont absents du système décrit dans la section suivante.

13.3 SYSTÈMES DE FICHIERS DISTRIBUÉS "TRANSPARENTS"

Le terme « allocation transparente » signifie que les utilisateurs sur une machine peuvent accéder aux fichiers sur une autre machine sans se rendre compte qu'ils traversent les limites de la machine, tout comme ils le sont sur leur machine lorsqu'ils passent d'un système de fichiers à un autre en traversant les points de montage. Les noms par lesquels les processus font référence aux fichiers situés sur les machines distantes sont similaires aux noms des fichiers locaux : ils ne contiennent aucun caractère distinctif. Dans la configuration illustrée à la figure 13.10, le répertoire "/usr/src" appartenant à la machine B est "monté" dans le répertoire "/usr/src" appartenant à la machine A. le même code source système, traditionnellement trouvé dans le "/ répertoire usr / src". Les utilisateurs s'exécutant sur la machine A peuvent accéder aux fichiers situés sur la machine B en utilisant la syntaxe habituelle d'écriture des noms de fichiers (par exemple : "/usr/src/cmd/login.c"), et le noyau lui-même décide si le fichier est distant ou local . Les utilisateurs fonctionnant sur la machine B ont accès à leurs fichiers locaux (ignorant que les utilisateurs de la machine A peuvent accéder aux mêmes fichiers), mais, à leur tour, n'ont pas accès aux fichiers situés sur la machine A. Bien sûr, d'autres options sont possibles, en en particulier, ceux dans lesquels tous les systèmes distants sont montés à la racine du système local, afin que les utilisateurs puissent accéder à tous les fichiers sur tous les systèmes.

Graphique 13.10. Systèmes de fichiers après le montage à distance

Les similitudes entre le montage de systèmes de fichiers locaux et l'autorisation d'accès aux systèmes de fichiers distants ont incité l'adaptation de la fonction de montage aux systèmes de fichiers distants. Dans ce cas, le noyau dispose d'une table de montage au format étendu. En exécutant la fonction de montage, le noyau organise une connexion réseau avec une machine distante et stocke les informations caractérisant cette connexion dans la table de montage.

Un problème intéressant concerne les noms de chemin qui incluent "..". Si un processus crée le répertoire courant à partir d'un système de fichiers distant, alors l'utilisation des caractères ".." dans le nom renverra plus probablement le processus au système de fichiers local plutôt que d'accéder aux fichiers au-dessus du répertoire courant. En revenant à nouveau à la Figure 13.10, notons que lorsqu'un processus appartenant à la machine A, ayant préalablement sélectionné le répertoire courant "/usr/src/cmd" situé dans le système de fichiers distant, va exécuter la commande

le répertoire courant sera le répertoire racine de la machine A, pas de la machine B. L'algorithme namei s'exécutant dans le noyau du système distant, après avoir reçu la séquence de caractères "..", vérifie si le processus appelant est un agent du client process, et si c'est le cas, définit si le client traite le répertoire de travail actuel comme la racine du système de fichiers distant.

La communication avec une machine distante prend l'une des deux formes suivantes : un appel de procédure distante ou un appel de fonction système distant. Dans la première forme, chaque procédure du noyau traitant des index vérifie si l'index pointe vers un fichier distant, et si c'est le cas, envoie une requête à la machine distante pour effectuer l'opération spécifiée. Ce schéma s'inscrit naturellement dans la structure abstraite de prise en charge des systèmes de fichiers de différents types, décrite dans la dernière partie du chapitre 5. Ainsi, un accès à un fichier distant peut initier le transfert de plusieurs messages sur le réseau, dont le nombre est déterminé par le nombre d'opérations implicites sur le fichier, avec une augmentation correspondante du temps de réponse à la requête, compte tenu du temps d'attente accepté dans le réseau. Chaque ensemble d'opérations distantes comprend au moins des actions de verrouillage d'index, de comptage de références, etc. Afin d'améliorer le modèle, diverses solutions d'optimisation ont été proposées liées à la combinaison de plusieurs opérations en une seule requête (message) et à la mise en mémoire tampon des données les plus importantes (cm. ).

13.11. Ouvrir un fichier distant

Considérez un processus qui ouvre un fichier distant "/usr/src/cmd/login.c", où "src" est le point de montage. En analysant le nom du fichier (en utilisant le schéma namei-iget), le noyau détecte que le fichier est supprimé et envoie une demande à la machine hôte pour obtenir l'index verrouillé. Ayant reçu la réponse souhaitée, le noyau local crée une copie de l'index en mémoire correspondant au fichier distant. Ensuite, le noyau vérifie les droits d'accès nécessaires au fichier (en lecture par exemple) en envoyant un autre message à la machine distante. L'algorithme ouvert se poursuit conformément au plan décrit au chapitre 5, en envoyant des messages à la machine distante selon les besoins, jusqu'à ce que l'algorithme soit terminé et que l'index soit libéré. La relation entre les structures de données du noyau à la fin de l'algorithme ouvert est illustrée à la Figure 13.11.

Si le client appelle la fonction read system, le noyau client verrouille l'index local, émet un verrou sur l'index distant, une requête de lecture, copie les données dans la mémoire locale, émet une requête pour libérer l'index distant et libère l'index local . Ce schéma est cohérent avec la sémantique du noyau monoprocesseur existant, mais la fréquence d'utilisation du réseau (appels multiples à chaque fonction système) réduit les performances de l'ensemble du système. Cependant, pour réduire le flux de messages sur le réseau, plusieurs opérations peuvent être combinées en une seule requête. Dans l'exemple avec la fonction read, le client peut envoyer au serveur une requête de "lecture" générale, et le serveur lui-même décide de récupérer et de libérer l'index lorsqu'il est exécuté. La réduction du trafic réseau peut également être obtenue en utilisant des tampons distants (comme nous l'avons vu ci-dessus), mais il faut veiller à ce que les fonctions du fichier système utilisant ces tampons soient exécutées correctement.

Dans la seconde forme de communication avec une machine distante (appel à une fonction système distante), le noyau local détecte que la fonction système est liée à un fichier distant et envoie les paramètres spécifiés dans son appel au système distant, qui exécute le fonction et renvoie les résultats au client. La machine cliente reçoit les résultats de l'exécution de la fonction et sort de l'état d'appel. La plupart des fonctions du système peuvent être exécutées en utilisant une seule requête réseau et en recevant une réponse après un délai raisonnable, mais toutes les fonctions ne rentrent pas dans ce modèle. Ainsi, par exemple, à la réception de certains signaux, le noyau crée un fichier pour le processus appelé « core » (chapitre 7). La création de ce fichier n'est pas associée à une fonction système spécifique, mais finit par effectuer plusieurs opérations telles que la création d'un fichier, la vérification des autorisations et l'exécution d'une série d'écritures.

Dans le cas de la fonction système ouvert, la demande d'exécution de la fonction envoyée à la machine distante comprend la partie du nom de fichier laissée après avoir exclu les composants de nom de chemin de recherche qui distinguent le fichier distant, ainsi que divers indicateurs. Dans l'exemple précédent d'ouverture du fichier "/usr/src/cmd/login.c", le noyau envoie le nom "cmd/login.c" à la machine distante. Le message comprend également des informations d'identification telles que des codes d'identification d'utilisateur et de groupe, qui sont nécessaires pour vérifier les autorisations de fichier sur une machine distante. Si une réponse est reçue de la machine distante indiquant une fonction d'ouverture réussie, le noyau local récupère un index libre dans la mémoire de la machine locale et le marque comme index de fichier distant, stocke des informations sur la machine distante et l'index distant, et alloue systématiquement une nouvelle entrée dans la table des fichiers. Comparé à l'index réel sur la machine distante, l'index détenu par la machine locale est formel et ne viole pas la configuration du modèle, qui est globalement la même que la configuration utilisée lors de l'appel de la procédure distante (Figure 13.11). Si une fonction appelée par un processus accède à un fichier distant par son descripteur, le noyau local sait à partir de l'index (local) que le fichier est distant, formule une requête qui inclut la fonction appelée et l'envoie à la machine distante. La requête contient un pointeur vers l'index distant par lequel le processus satellite peut identifier le fichier distant lui-même.

Ayant reçu le résultat de l'exécution de n'importe quelle fonction système, le noyau peut recourir aux services d'un programme spécial pour le traiter (à la fin duquel le noyau finira de travailler avec la fonction), car le traitement local des résultats utilisé dans un système monoprocesseur n'est pas toujours adapté à un système à plusieurs processeurs. En conséquence, des changements dans la sémantique des algorithmes du système sont possibles, visant à fournir un support pour l'exécution des fonctions du système distant. Cependant, dans le même temps, un flux minimum de messages circule dans le réseau, assurant le temps de réponse minimum du système aux requêtes entrantes.

13.4 MODÈLE DISTRIBUÉ SANS PROCESSUS DE TRANSFERT

L'utilisation de processus de transfert (processus satellites) dans un système distribué transparent facilite le suivi des fichiers supprimés, mais la table de processus du système distant est surchargée de processus satellites qui sont inactifs la plupart du temps. Dans d'autres schémas, des processus serveur spéciaux sont utilisés pour traiter les requêtes distantes (voir et). Le système distant dispose d'un ensemble (pool) de processus serveur qu'il affecte de temps en temps pour traiter les demandes distantes entrantes. Après avoir traité la demande, le processus serveur retourne au pool et entre dans un état prêt à traiter d'autres demandes. Le serveur ne sauvegarde pas le contexte utilisateur entre deux appels, car il peut traiter les requêtes de plusieurs processus à la fois. Ainsi, chaque message arrivant d'un processus client doit comporter des informations sur son environnement d'exécution, à savoir : codes d'identification des utilisateurs, répertoire courant, signaux, etc. fonctions.

Lorsqu'un processus ouvre un fichier distant, le noyau distant attribue un index pour les liens ultérieurs vers le fichier. La machine locale gère une table de descripteurs de fichiers personnalisés, une table de fichiers et une table d'index avec un ensemble régulier d'enregistrements, avec une entrée de table d'index identifiant la machine distante et l'index distant. Dans les cas où une fonction système (par exemple, lire) utilise un descripteur de fichier, le noyau envoie un message pointant vers l'index distant précédemment attribué et transfère les informations relatives au processus : code d'identification de l'utilisateur, taille maximale du fichier, etc. la machine dispose d'un processus serveur à sa disposition, l'interaction avec le client prend la forme décrite précédemment, cependant, la connexion entre le client et le serveur n'est établie que pour la durée de la fonction système.

L'utilisation de serveurs au lieu de processus satellites peut rendre la gestion du trafic de données, des signaux et des appareils distants plus difficile. Un grand nombre de requêtes vers une machine distante en l'absence d'un nombre suffisant de serveurs doit être mis en file d'attente. Cela nécessite un protocole de couche supérieure à celui utilisé sur le réseau principal. Dans le modèle satellite, en revanche, la sursaturation est éliminée car toutes les demandes des clients sont traitées de manière synchrone. Un client peut avoir au plus une demande en attente.

Le traitement des signaux qui interrompent l'exécution d'une fonction système est également compliqué lors de l'utilisation de serveurs, car la machine distante doit rechercher le serveur approprié servant à l'exécution de la fonction. Il est même possible qu'en raison de la surcharge de tous les serveurs, une demande de fonction système soit en attente de traitement. Des conditions pour l'émergence de la concurrence se présentent également lorsque le serveur renvoie le résultat de la fonction système au processus appelant et que la réponse du serveur comprend l'envoi d'un message de signalisation correspondant à travers le réseau. Chaque message doit être marqué afin que le système distant puisse le reconnaître et, si nécessaire, terminer les processus du serveur. Lors de l'utilisation de satellites, le processus qui gère l'exécution de la demande du client est automatiquement identifié, et en cas d'arrivée d'un signal, il n'est pas difficile de vérifier si la demande a été traitée ou non.

Enfin, si une fonction système appelée par le client provoque une pause indéfinie du serveur (par exemple, lors de la lecture de données à partir d'un terminal distant), le serveur ne peut pas traiter d'autres requêtes pour libérer le pool de serveurs. Si plusieurs processus accèdent à des équipements distants en même temps et si le nombre de serveurs est limité par le haut, il y a un goulot d'étranglement assez tangible. Cela ne se produit pas avec les satellites, puisqu'un satellite est alloué à chaque processus client. Un autre problème lié à l'utilisation de serveurs pour des périphériques distants sera traité dans l'exercice 13.14.

Malgré les avantages que procure l'utilisation de processus satellites, le besoin d'entrées libres dans la table de processus devient en pratique si aigu que dans la plupart des cas, les services de processus serveurs sont encore utilisés pour traiter des requêtes distantes.

Graphique 13.12. Schéma conceptuel de l'interaction avec les fichiers distants au niveau du noyau

13.5 CONCLUSION

Dans ce chapitre, nous avons considéré trois schémas pour travailler avec des fichiers situés sur des machines distantes, en traitant les systèmes de fichiers distants comme une extension du système local. Les différences architecturales entre ces dispositions sont illustrées à la figure 13.12. Tous, à leur tour, diffèrent des systèmes multiprocesseurs décrits dans le chapitre précédent en ce que les processeurs ici ne partagent pas de mémoire physique. Un système de processeur périphérique se compose d'un ensemble étroitement couplé de processeurs qui partagent les ressources de fichiers du processeur central. Une connexion de type Newcastle fournit un accès caché ("transparent") aux fichiers distants, mais pas via le noyau du système d'exploitation, mais via l'utilisation d'une bibliothèque C spéciale. Pour cette raison, tous les programmes qui ont l'intention d'utiliser ce type de lien doivent être recompilés, ce qui, en général, est un grave inconvénient de ce schéma. L'éloignement d'un fichier est indiqué par une séquence spéciale de caractères décrivant la machine sur laquelle se trouve le fichier, et c'est un autre facteur limitant la portabilité des programmes.

Dans les systèmes distribués transparents, une modification de la fonction de montage du système est utilisée pour accéder aux fichiers distants. Les index sur le système local sont marqués comme des fichiers distants et le noyau local envoie un message au système distant décrivant la fonction système demandée, ses paramètres et l'index distant. La communication dans un système distribué « transparent » est prise en charge sous deux formes : sous la forme d'un appel à une procédure distante (un message est envoyé à la machine distante contenant une liste d'opérations associées à l'index) et sous la forme d'un appel à une fonction système distante (le message décrit la fonction demandée). La dernière partie du chapitre aborde les problèmes liés au traitement des requêtes distantes à l'aide de processus et de serveurs satellites.

13.6 EXERCICES

*un. Décrire la mise en œuvre de la fonction de système de sortie dans un système avec des processeurs périphériques. Quelle est la différence entre ce cas et le moment où le processus se termine à la réception d'un signal non capté ? Comment le noyau doit-il vider le contenu de la mémoire ?

2. Les processus ne peuvent pas ignorer les signaux SIGKILL ; Expliquez ce qui se passe dans le système périphérique lorsque le processus reçoit un tel signal.

* 3. Décrire la mise en œuvre de la fonction système exec sur un système avec des processeurs périphériques.

*4. Comment le processeur central doit-il répartir les processus entre les processeurs périphériques afin d'équilibrer la charge globale ?

*5. Que se passe-t-il si le processeur périphérique n'a pas assez de mémoire pour accueillir tous les processus qui lui sont déchargés ? Comment procéder au déchargement et à l'échange de processus dans le réseau ?

6. Considérez un système dans lequel des demandes à un serveur de fichiers distant sont envoyées si un préfixe spécial est trouvé dans le nom de fichier. Laissez le processus appeler execl ("/../ sftig / bin / sh", "sh", 0); L'exécutable se trouve sur une machine distante, mais doit être exécuté sur le système local. Expliquez comment le module distant est migré vers le système local.

7. Si l'administrateur a besoin d'ajouter de nouvelles machines à un système existant avec une connexion comme Newcastle, alors quelle est la meilleure façon d'informer les modules de la bibliothèque C à ce sujet ?

*huit. Lors de l'exécution de la fonction exec, le noyau écrase l'espace d'adressage du processus, y compris les tables de bibliothèque utilisées par le lien Newcastle pour suivre les liens vers les fichiers distants. Après l'exécution de la fonction, le processus doit conserver la possibilité d'accéder à ces fichiers par leurs anciens descripteurs. Décrivez la mise en œuvre de ce point.

*9. Comme indiqué dans la section 13.2, l'appel de la fonction exit system sur les systèmes avec une connexion Newcastle entraîne l'envoi d'un message au processus compagnon, forçant ce dernier à se terminer. Cela se fait au niveau des routines de la bibliothèque. Que se passe-t-il lorsqu'un processus local reçoit un signal lui indiquant de quitter le mode noyau ?

*dix. Dans un système avec un lien Newcastle, où les fichiers distants sont identifiés en préfixant le nom avec un préfixe spécial, comment un utilisateur, en spécifiant ".." (répertoire parent) comme composant de nom de fichier, peut-il traverser le point de montage distant ?

11. Nous savons depuis le chapitre 7 que divers signaux amènent le processus à vider le contenu de la mémoire dans le répertoire courant. Que se passe-t-il si le répertoire actuel provient du système de fichiers distant ? Quelle réponse donneriez-vous si le système utilisait une relation comme Newcastle ?

*12. Quelles implications cela aurait-il pour les processus locaux si tous les processus satellites ou serveurs étaient supprimés du système ?

*treize. Considérez comment implémenter l'algorithme de liaison dans un système distribué transparent, dont les paramètres peuvent être deux noms de fichiers distants, ainsi que l'algorithme exec, associé à l'exécution de plusieurs opérations de lecture interne. Considérons deux formes de communication : un appel de procédure distante et un appel de fonction système distant.

*14. Lors de l'accès au périphérique, le processus serveur peut entrer dans l'état suspendu, à partir duquel il sera retiré par le pilote de périphérique. Naturellement, si le nombre de serveurs est limité, le système ne pourra plus satisfaire les requêtes de la machine locale. Proposez un schéma fiable dans lequel tous les processus du serveur ne sont pas suspendus en attendant la fin des E/S liées au périphérique. La fonction système ne se terminera pas tant que tous les serveurs sont occupés.

Figure 13.13. Configuration du serveur de terminaux

*15. Lorsqu'un utilisateur se connecte au système, la discipline de ligne de terminal stocke l'information selon laquelle le terminal est un terminal d'opérateur dirigeant un groupe de processus. Pour cette raison, lorsque l'utilisateur appuie sur la touche "break" du clavier du terminal, tous les processus du groupe reçoivent le signal d'interruption. Considérons une configuration système dans laquelle tous les terminaux sont physiquement connectés à une machine, mais l'enregistrement de l'utilisateur est logiquement implémenté sur d'autres machines (Figure 13.13). Dans chaque cas, le système crée un processus getty pour le terminal distant. Si les demandes adressées à un système distant sont traitées par un ensemble de processus serveur, notez que lorsque la procédure d'ouverture est exécutée, le serveur arrête d'attendre une connexion. Lorsque la fonction d'ouverture est terminée, le serveur retourne dans le pool de serveurs, coupant sa connexion au terminal. Comment un signal d'interruption est-il déclenché en appuyant sur la touche « break » envoyé aux adresses des processus inclus dans le même groupe ?

*seize. Le partage de mémoire est une fonctionnalité inhérente aux machines locales. D'un point de vue logique, l'allocation d'une zone commune de mémoire physique (locale ou distante) peut être réalisée pour des processus appartenant à des machines différentes. Décrivez la mise en œuvre de ce point.

* 17. Le processus de pagination et les algorithmes de pagination discutés au chapitre 9 supposent l'utilisation d'un pager local. Quelles modifications doivent être apportées à ces algorithmes afin de pouvoir prendre en charge les dispositifs de déchargement à distance ?

*dix-huit. Supposons que la machine distante (ou le réseau) rencontre une panne fatale et que le protocole de couche réseau local enregistre ce fait. Développer un schéma de récupération pour un système local faisant des requêtes à un serveur distant. En outre, développez un schéma de récupération pour un système serveur qui a perdu le contact avec les clients.

*dix-neuf. Lorsqu'un processus accède à un fichier distant, il est possible que le processus traverse plusieurs machines à la recherche du fichier. Prenons le nom "/usr/src/uts/3b2/os" comme exemple, où "/usr" est le répertoire appartenant à la machine A, "/usr/src" est le point de montage de la racine de la machine B, " /usr/src/uts/3b2 "est le point de montage de la racine de la machine C. Parcourir plusieurs machines jusqu'à sa destination finale s'appelle un multisaut. Cependant, s'il existe une connexion réseau directe entre les machines A et C, l'envoi de données via la machine B serait inefficace. Décrire les caractéristiques de la mise en œuvre du "multishopping" dans un système avec une connexion Newcastle et dans un système distribué "transparent".

V grandes exploitations des dizaines de milliers d'utilisateurs travaillent dans des filiales. Chaque organisation a ses propres processus d'affaires internes : approbation de documents, émission d'instructions, etc. Dans le même temps, certains processus dépassent les frontières d'une entreprise et affectent les employés d'une autre. Par exemple, le chef du siège social donne un ordre à la filiale, ou un salarié de la filiale envoie un accord pour accord avec les avocats de la maison mère. Cela nécessite une architecture complexe utilisant plusieurs systèmes.

De plus, au sein une entreprise de nombreux systèmes sont utilisés pour résoudre différents problèmes : un système ERP pour les opérations comptables, des installations séparées de systèmes ECM pour la documentation organisationnelle et administrative, pour les devis de conception, etc.

Le système DIRECTUM contribuera à assurer l'interaction de différents systèmes à la fois au sein de l'exploitation et au niveau d'une organisation.

DIRECTUM fournit des outils pratiques pour la construction architecture distribuée gérée organiser et résoudre les tâches suivantes :

• organisation de processus métiers de bout en bout et synchronisation des données entre plusieurs systèmes d'une même entreprise et dans la holding ;
• donnant accès aux données de différentes installations de systèmes ECM. Par exemple, rechercher un document dans plusieurs systèmes spécialisés : avec documentation financière, avec documentation de conception et devis, etc.
• administration de nombreux systèmes et services à partir d'un seul point de gestion et création d'une infrastructure informatique confortable ;
• distribution pratique du développement aux systèmes de production distribués.

Composants d'une architecture distribuée gérée

Mécanismes d'Interconnexion (DCI)

Les mécanismes DCI sont utilisés pour organiser les processus métier de bout en bout et synchroniser les données entre différents systèmes au sein d'une ou plusieurs organisations (holding).

La solution relie les processus commerciaux locaux existants dans les entreprises en un seul processus de bout en bout. Les employés et leurs managers travaillent avec l'interface déjà familière des tâches, des documents et des ouvrages de référence. Dans le même temps, les actions des employés sont transparentes à chaque étape : ils peuvent voir le texte de la correspondance avec une entreprise liée, voir l'état d'approbation du document avec l'organisation mère, etc.

Différentes installations DIRECTUM et d'autres classes de systèmes (ERP, CRM, etc.) peuvent être connectées à DCI. En règle générale, les installations sont divisées par domaines d'activité, en tenant compte de l'emplacement territorial ou juridique des organisations et d'autres facteurs.

Avec DCI, les composants de développement sont fournis avec une description détaillée et des exemples de code, grâce auxquels un développeur peut créer un algorithme pour les processus métier de son organisation.

Les mécanismes DCI sont capables de transmettre de grandes quantités de données et de supporter des charges de pointe. De plus, ils assurent la tolérance aux pannes en cas de panne de communication et la protection des données transmises.

Recherche fédérée

Avec la recherche fédérée, vous pouvez trouver les tâches ou les documents dont vous avez besoin à la fois dans tous les systèmes DIRECTUM individuels. Par exemple, lancez une recherche simultanément dans le système de travail et dans le système avec les documents archivés.

La recherche fédérée vous permet de :

• visualiser via le client web l'avancement de la validation d'un document sortant dans une filiale ;
• trouver des accords conclus avec une contrepartie dans toutes les filiales, par exemple, pour la préparation des négociations. Dans ce cas, vous pouvez accéder aux tâches dans lesquelles les contrats sont inclus ;
• vérifier l'état d'exécution de la commande envoyée de l'organisation mère à la filiale, ou des documents et tâches créés sur celle-ci ;
• trouver des documents simultanément dans plusieurs systèmes avec des spécialisations différentes, par exemple, avec des documents organisationnels et administratifs et avec des contrats ;
• trouver les documents comptables primaires pour audit ou rapprochement avec une contrepartie immédiatement dans le système de travail et dans le système avec une archive de documents ;
• échanger des liens vers des résultats de recherche avec des collègues.

L'administrateur peut modifier les recherches standard, en ajouter de nouvelles et également personnaliser les systèmes qui seront visibles par l'utilisateur.

Centre d'administration des services DIRECTUM

Le système DIRECTUM résout de nombreuses tâches différentes : interaction des employés, stockage de documents, etc. Cela est possible grâce au fonctionnement fiable de ses services. Et dans les grandes entreprises, ils allouent des installations entières du système DIRECTUM avec leur propre ensemble de services à une tâche spécifique, par exemple, pour le stockage de documents d'archives. Les installations et les services sont déployés sur plusieurs serveurs. Cette infrastructure doit être administrée.

Le centre d'administration des services DIRECTUM est un point d'entrée administratif unique pour la configuration, la surveillance et la gestion des services et systèmes DIRECTUM. Le Centre est un site d'outils de gestion pour Session Server, Workflow Service, Event Processing Service, File Storage Service, Input and Transform Services, Federated Search et Web Help.

La configuration visuelle pratique des systèmes et services distants simplifie le travail de l'administrateur. Il n'a pas besoin d'aller sur chaque serveur et d'apporter manuellement des modifications aux fichiers de configuration.

Les services sont arrêtés et activés en un clic. L'état des services s'affiche instantanément à l'écran.

La liste des paramètres peut être complétée et filtrée. Par défaut, le site n'affiche que les paramètres de base. Dans le même temps, pour tous les paramètres, vous pouvez voir des conseils avec des recommandations pour le remplissage.

Le système DIRECTUM organise efficacement le travail des organisations réparties et offre aux utilisateurs un échange transparent de documents, de tâches et d'enregistrements de répertoire.

Chaque composant d'une architecture distribuée gérée peut être utilisé séparément, mais ensemble, ils peuvent apporter une plus grande valeur commerciale à votre organisation.

Actuellement, tous les SI développés à des fins commerciales ont une architecture distribuée, ce qui implique l'utilisation de réseaux mondiaux et/ou locaux.

Historiquement, l'architecture de serveur de fichiers a été la première à se généraliser, car sa logique est simple et il est plus facile de transférer vers une telle architecture les SI déjà utilisés. Elle s'est ensuite transformée en une architecture serveur-client, qui peut être interprétée comme sa suite logique. Les systèmes modernes utilisés dans le réseau mondial INTERNET concernent principalement l'architecture des objets distribués (voir Fig. III‑15 )

On peut imaginer un SI constitué des éléments suivants (Fig. III-16)

III.03.2. a Applications de serveur de fichiers.

C'est historiquement la première architecture distribuée (Fig. III-17). C'est organisé très simplement : il n'y a que des données sur le serveur, et tout le reste appartient à la machine cliente. Les réseaux locaux étant assez bon marché, et du fait qu'avec une telle architecture le logiciel d'application est autonome, une telle architecture est souvent utilisée aujourd'hui. On peut dire qu'il s'agit d'une variante de l'architecture client-serveur, dans laquelle seuls les fichiers de données se trouvent sur le serveur. Différents ordinateurs personnels interagissent uniquement au moyen d'un magasin de données commun, par conséquent, les programmes écrits pour un ordinateur sont les plus faciles à adapter à une telle architecture.

Avantages:

Avantages d'une architecture de serveur de fichiers :

Facilité d'organisation;

Ne contredit pas les exigences nécessaires pour que la base de données maintienne l'intégrité et la fiabilité.

La congestion du réseau;

Réponse imprévisible à une demande.

Ces inconvénients s'expliquent par le fait que toute requête à la base de données entraîne le transfert de quantités importantes d'informations sur le réseau. Par exemple, pour sélectionner une ou plusieurs lignes des tables, la table entière est téléchargée sur la machine cliente et le SGBD y sélectionne déjà. Le trafic réseau important est particulièrement lourd avec l'organisation de l'accès à distance à la base de données.

III.03.2. b Applications client-serveur.

Dans ce cas, il y a une répartition des responsabilités entre le serveur et le client. Selon la façon dont ils sont séparés, distinguer gros et client léger.

Dans le modèle de client léger, tout le travail d'application et la gestion des données sont effectués sur le serveur. L'interface utilisateur de ces systèmes « migre » vers un ordinateur personnel et l'application logicielle elle-même remplit les fonctions d'un serveur, c'est-à-dire exécute tous les processus d'application et gère les données. Le modèle de client léger peut également être mis en œuvre lorsque les clients sont des ordinateurs ou des postes de travail. Les périphériques réseau exécutent le navigateur Internet et l'interface utilisateur implémentée dans le système.

Principale défaut modèles de client léger - charge élevée du serveur et du réseau. Tous les calculs sont effectués sur le serveur, ce qui peut entraîner un trafic réseau important entre le client et le serveur. Il y a assez de puissance de calcul dans les ordinateurs modernes, mais elle n'est pratiquement pas utilisée dans le modèle/client léger de la banque

En revanche, le modèle client lourd utilise la puissance de traitement des machines locales : l'application elle-même est placée sur l'ordinateur client. Un exemple de ce type d'architecture est celui des systèmes ATM, dans lesquels l'ATM est le client et le serveur est l'ordinateur central servant la base de données des comptes clients.

III.03.2. c Architecture client-serveur à deux et trois niveaux.

Toutes les architectures décrites ci-dessus sont à deux niveaux. Ils font la différence entre le niveau client et le niveau serveur. Au sens strict, le CI se compose de trois niveaux logiques :

· Niveau de l'utilisateur;

Niveau d'application :

· Couche de données.

Par conséquent, dans un modèle à deux niveaux, où seuls deux niveaux sont impliqués, il existe des problèmes d'évolutivité et de performances si le modèle de client léger est choisi, ou des problèmes de gestion du système si le modèle de client lourd est choisi. Ces problèmes peuvent être évités si l'on applique un modèle à trois niveaux, dont deux sont des serveurs (Fig. III-21).

Serveur de données

En effet, le serveur d'applications et le serveur de données peuvent être situés sur la même machine, mais ils ne peuvent pas remplir les fonctions l'un de l'autre. L'avantage du modèle à trois niveaux est qu'il sépare logiquement l'exécution des applications et la gestion des données.

Tableau III-5 Application de différents types d'architectures

Architecture	appendice
Client léger à deux niveaux	1 Systèmes hérités dans lesquels il n'est pas conseillé de séparer l'exécution des applications et la gestion des données. 2 Applications gourmandes en calcul avec peu de gestion de données. 3 Applications avec de grandes quantités de données, mais peu de calculs.
Client lourd à deux niveaux	1 Applications où l'utilisateur a besoin d'un traitement intensif des données, c'est-à-dire de la visualisation des données. 2 Applications avec un ensemble relativement constant de fonctions utilisateur appliquées à un environnement système bien géré.
Serveur-client à trois niveaux	1 Grandes applications avec des cellules et des milliers de clients 2 Applications dans lesquelles les données et les méthodes de traitement changent fréquemment. 3 Applications qui intègrent des données provenant de plusieurs sources.

Ce modèle convient à de nombreux types d'applications, mais il limite les développeurs de SI qui doivent décider où fournir les services, fournir un support pour l'évolutivité et développer des outils pour connecter de nouveaux clients.

III.03.2. d Architecture d'objets distribués.

Une approche plus générale est fournie par une architecture d'objets distribués, dont les objets sont les composants principaux. Ils fournissent un ensemble de services à travers leurs interfaces. D'autres objets envoient des requêtes sans faire la différence entre le client et le serveur. Les objets peuvent être situés sur différents ordinateurs du réseau et interagir via un middleware, similaire au bus système, qui vous permet de connecter différents périphériques et de prendre en charge la communication entre les périphériques matériels.

…

Gestionnaire de pilotes ODBC

Pilote 1

Pilote K

DB 1

DBK

Travailler avec SQL

…

L'architecture ODBC comprend des composants :

1. Application (par exemple IS). Il exécute des tâches : demande une connexion à la source de données, envoie des requêtes SQL à la source de données, décrit la zone de stockage et le format des requêtes SQL, gère les erreurs et en informe l'utilisateur, valide ou annule les transactions, demande une connexion à la la source de données.

2. Gestionnaire de périphériques. Il charge les pilotes à la demande des applications, offre une interface unique à toutes les applications, et l'interface administrateur ODBC est la même et quel que soit le SGBD avec lequel l'application interagira. Le gestionnaire de pilotes fourni par Microsoft est une bibliothèque à chargement dynamique (DLL).

3. Le pilote dépend du SGBD. Un pilote ODBC est une bibliothèque de liens dynamiques (DLL) qui implémente les fonctions ODBC et interagit avec une source de données. Un pilote est un programme qui traite une requête de fonction propre à un SGBD (il peut modifier les requêtes conformément au SGBD) et renvoie le résultat à l'application. Chaque SGBD qui prend en charge la technologie ODBC doit fournir aux développeurs d'applications un pilote pour ce SGBD.

4. La source de données contient les informations de contrôle spécifiées par l'utilisateur, des informations sur la source de données et est utilisée pour accéder à un SGBD spécifique. Dans ce cas, les moyens de l'OS et de la plate-forme réseau sont utilisés.

Modèle dynamique

Ce modèle revêt de nombreux aspects, pour lesquels au moins 5 diagrammes sont utilisés en UML, voir pp. 2.04.2- 2.04.5.

Considérez l'aspect gestion. Le modèle de gouvernance complète les modèles structurels.

Quelle que soit la manière dont la structure du système est décrite, il se compose d'un ensemble d'unités structurelles (fonctions ou objets). Pour qu'ils fonctionnent comme un tout, ils doivent être contrôlés et il n'y a aucune information de contrôle dans les diagrammes statiques. Les modèles de contrôle conçoivent le flux de contrôle entre les systèmes.

Il existe deux principaux types de contrôle dans les systèmes logiciels.

1. Gestion centralisée.

2. Gestion basée sur les événements.

La gestion centralisée peut être :

· Hiérarchique- sur la base du principe « call-return » (c'est ainsi que fonctionnent le plus souvent les programmes éducatifs)

· Modèle de répartiteur qui est utilisé pour les systèmes parallèles.

V modèles de répartiteur on suppose que l'un des composants du système est un répartiteur. Il gère à la fois le démarrage et l'arrêt des systèmes et la coordination du reste des processus du système. Les processus peuvent s'exécuter en parallèle. Un processus fait référence à un programme, un sous-système ou une procédure en cours d'exécution. Ce modèle peut également être appliqué dans des systèmes séquentiels, où le programme de contrôle appelle des sous-systèmes individuels en fonction de certaines variables d'état (via l'opérateur Cas).

Gestion d'événements suppose l'absence de tout sous-programme chargé de la gestion. Le contrôle est effectué par des événements externes : appui sur un bouton de la souris, appui sur un clavier, modification des lectures des capteurs, modification des lectures de la minuterie, etc. Chaque événement externe est codé et placé dans la file d'attente des événements. Si une réaction à un événement dans la file d'attente est fournie, la procédure (sous-programme) est appelée, qui exécute la réaction à cet événement. Les événements auxquels le système réagit peuvent se produire soit dans d'autres sous-systèmes, soit dans l'environnement externe du système.

Un exemple d'une telle gestion est l'organisation des applications sous Windows.

Tous les modèles structurels décrits précédemment peuvent être mis en œuvre à l'aide d'une gestion centralisée ou d'une gestion événementielle.

Interface utilisateur

Lors du développement d'un modèle d'interface, il convient de prendre en compte non seulement les tâches du logiciel conçu, mais également les caractéristiques du cerveau associées à la perception de l'information.

III.03.4. a Caractéristiques psychophysiques d'une personne associées à la perception et au traitement de l'information.

La partie du cerveau, que l'on peut appeler conventionnellement un processeur de perception, traite constamment, sans la participation de la conscience, les informations entrantes, les compare avec l'expérience passée et les stocke.

Lorsqu'une image visuelle attire notre attention, alors l'information qui nous intéresse arrive dans la mémoire à court terme. Si notre attention n'a pas été attirée, les informations stockées disparaissent et sont remplacées par les parties suivantes.

A chaque instant, le foyer d'attention peut être fixé en un point, donc s'il devient nécessaire de suivre simultanément plusieurs situations, alors le foyer se déplace d'un objet suivi à un autre. Dans le même temps, l'attention est dispersée et certains détails peuvent être négligés. Il est également significatif que la perception soit largement basée sur la motivation.

Lorsque vous changez de cadre, le cerveau est bloqué pendant un certain temps : il maîtrise une nouvelle image, mettant en évidence les détails les plus significatifs. Cela signifie que si vous avez besoin d'une réponse rapide de l'utilisateur, vous ne devez pas modifier les images brusquement.

La mémoire à court terme est le goulot d'étranglement dans le système de traitement de l'information d'une personne. Sa capacité est de 7 ± 2 objets non connectés. Les informations non réclamées y sont stockées pendant 30 secondes maximum. Afin de n'oublier aucune information importante pour nous, nous nous la répétons généralement, en mettant à jour les informations dans la mémoire à court terme. Ainsi, lors de la conception des interfaces, il convient de garder à l'esprit que l'écrasante majorité a du mal, par exemple, à se souvenir et à saisir des nombres contenant plus de cinq chiffres sur un autre écran.

Bien que la capacité et la durée de stockage de la mémoire à long terme soient illimitées, l'accès à l'information n'est pas aisé. Le mécanisme d'extraction d'informations de la mémoire à long terme est de nature associative. Pour améliorer la mémorisation des informations, elle est liée aux données que la mémoire stocke déjà et facilite son obtention. L'accès à la mémoire à long terme étant difficile, il convient de s'attendre à ce que l'utilisateur ne se souvienne pas de l'information, mais sur le fait qu'il la reconnaîtra.

III.03.4. b Critères de base pour l'évaluation des interfaces

De nombreuses enquêtes et enquêtes menées par les principales sociétés de développement de logiciels ont montré que les utilisateurs apprécient dans une interface :

1) facilité de maîtrise et de mémorisation - estimer précisément le temps de maîtrise et la durée de conservation des informations et de la mémoire ;

2) la vitesse d'obtention des résultats lors de l'utilisation du système, qui est déterminée par le nombre de commandes et de paramètres entrés ou sélectionnés par la souris ;

3) satisfaction subjective du fonctionnement du système (facilité d'utilisation, fatigue, etc.).

De plus, pour les utilisateurs professionnels qui travaillent constamment avec le même package, les deuxième et troisième critères viennent rapidement en premier, et pour les utilisateurs non professionnels qui travaillent périodiquement avec des logiciels et effectuent des tâches relativement simples - le premier et le troisième.

De ce point de vue, les meilleures caractéristiques aujourd'hui pour les utilisateurs professionnels sont les interfaces à navigation libre, et pour les utilisateurs non professionnels, les interfaces à manipulation directe. Il a longtemps été remarqué que lors de l'exécution d'une opération de copie de fichiers, toutes choses étant égales par ailleurs, la plupart des professionnels utilisent des shells comme Far, tandis que les non-professionnels utilisent le "glisser-déposer" de Windows.

III.03.4. c Types d'interfaces utilisateur

On distingue les types d'interfaces utilisateur suivants :

Primitif

Navigation libre

Manipulation directe.

L'interface est primitive

Primitif est appelée l'interface qui organise l'interaction avec l'utilisateur et est utilisée en mode console. Le seul écart par rapport au processus séquentiel fourni par les données est de parcourir plusieurs ensembles de données.

Interface de menus.

Contrairement à l'interface primitive, elle permet à l'utilisateur de sélectionner une opération dans une liste spéciale affichée par le programme. Ces interfaces supposent la mise en œuvre de nombreux scénarios de travail, dont la séquence d'actions est déterminée par les utilisateurs. L'organisation arborescente du menu suggère qu'il est difficile de trouver un élément sur plus de deux niveaux de menus.

Principes de création d'un système de traitement de l'information à l'échelle de l'entreprise

L'histoire du développement de la technologie informatique (et, par conséquent, des logiciels) a commencé avec des systèmes distincts et autonomes. Les scientifiques et les ingénieurs étaient préoccupés par la création des premiers ordinateurs et se demandaient surtout comment faire fonctionner ces essaims de tubes à vide. Cependant, cet état de fait n'a pas duré longtemps - l'idée de combiner la puissance de calcul était assez évidente et était dans l'air, saturée du bourdonnement des armoires métalliques des premiers ENIAK et Marks. Après tout, l'idée de combiner les efforts de deux ou plusieurs ordinateurs pour résoudre séparément des tâches complexes et insupportables pour chacun d'eux est en surface.

Riz. 1. Schéma de calcul distribué

Cependant, la mise en œuvre pratique de l'idée de connecter les ordinateurs en clusters et en réseaux a été entravée par le manque de solutions techniques et, tout d'abord, par la nécessité de créer des normes et des protocoles de communication. Comme vous le savez, les premiers ordinateurs sont apparus à la fin des années quarante du XXe siècle, et le premier réseau informatique ARPANet, qui connectait plusieurs ordinateurs aux États-Unis, n'est apparu qu'en 1966, près de vingt ans plus tard. Bien sûr, une telle combinaison de capacités de calcul de l'architecture distribuée moderne ressemblait très vaguement, mais c'était néanmoins le premier pas dans la bonne direction.

L'émergence des réseaux locaux au fil du temps a conduit au développement d'un nouveau domaine de développement de logiciels - la création d'applications distribuées. Nous avons dû le faire à partir de zéro, comme on dit, mais, heureusement, les grandes entreprises, dont la structure commerciale nécessitait de telles solutions, ont immédiatement manifesté leur intérêt pour de telles applications. C'est au stade de la création d'applications distribuées d'entreprise que les exigences de base ont été formées et les principales architectures de ces systèmes ont été développées, qui sont encore utilisées aujourd'hui.

Progressivement, les mainframes et les terminaux ont évolué vers une architecture client-serveur, qui était essentiellement la première version d'une architecture distribuée, c'est-à-dire un système distribué à deux niveaux. En effet, c'est dans les applications client-serveur qu'une partie des opérations de calcul et de la logique métier était transférée côté client, ce qui, en fait, est devenu le point culminant, la marque de fabrique de cette approche.

C'est durant cette période qu'il est devenu évident que les principaux avantages des applications distribuées sont :

· Bonne évolutivité - si nécessaire, la puissance de calcul d'une application distribuée peut être facilement augmentée sans changer sa structure ;

· La capacité de gérer la charge - les niveaux intermédiaires d'une application distribuée permettent de gérer les flux de requêtes des utilisateurs et de les rediriger vers des serveurs moins chargés pour traitement ;

· Globalité - une structure distribuée vous permet de suivre la distribution spatiale des processus métier et de créer des postes de travail clients aux points les plus pratiques.

Au fil du temps, de petits îlots de réseaux universitaires, gouvernementaux et corporatifs se sont étendus et ont fusionné dans des systèmes régionaux et nationaux. Et puis l'acteur principal est apparu sur la scène - Internet.

Les éloges élogieux sur le World Wide Web ont longtemps été un lieu commun pour les publications sur des sujets informatiques. En effet, Internet a joué un rôle central dans le développement de l'informatique distribuée et a fait de ce domaine assez spécifique du développement logiciel le centre d'intérêt d'une armée de programmeurs professionnels. Aujourd'hui, il étend considérablement l'utilisation des applications distribuées, permettant aux utilisateurs distants de se connecter et de rendre les fonctions des applications disponibles partout.

C'est l'historique du problème. Voyons maintenant ce que sont les applications distribuées.

Paradigme de l'informatique distribuée

Imaginez une installation de fabrication, une société commerciale ou un fournisseur de services assez grand. Toutes leurs divisions disposent déjà de leurs propres bases de données et de logiciels spécifiques. Le bureau central collecte en quelque sorte des informations sur les activités actuelles de ces départements et fournit aux gestionnaires des informations sur la base desquelles ils prennent des décisions de gestion.

Allons plus loin et supposons que l'organisation que nous considérons se développe avec succès, ouvre des succursales, développe de nouveaux types de produits ou de services. De plus, lors de la dernière réunion, des cadres avant-gardistes ont décidé d'organiser un réseau de postes de travail distants à partir desquels les clients pourraient recevoir des informations sur l'exécution de leurs commandes.

Dans la situation décrite, il ne reste plus qu'à plaindre le chef du service informatique s'il ne s'est pas occupé à l'avance de construire un système général de gestion des flux d'affaires, car sans lui, il sera très difficile d'assurer le développement efficace de l'organisation. De plus, on ne peut se passer d'un système de traitement de l'information à l'échelle de l'entreprise, conçu en tenant compte de la charge croissante et, de plus, correspondant aux principaux flux d'affaires, puisque tous les services doivent non seulement exécuter leurs tâches, mais aussi, si nécessaire, traiter les demandes d'autres services et même (un cauchemar pour un chef de projet !) des clients.

Ainsi, nous sommes prêts à formuler les exigences de base pour les applications modernes à l'échelle de l'entreprise dictées par l'organisation même du processus de production.

Séparation spatiale. Les divisions de l'organisation sont dispersées dans l'espace et disposent souvent de logiciels mal unifiés.

Conformité structurelle. Le logiciel doit refléter de manière adéquate la structure de l'information de l'entreprise - il doit correspondre aux principaux flux de données.

Orientation vers l'information externe. Les entreprises modernes sont obligées d'accorder une attention accrue au travail avec les clients. Par conséquent, les logiciels d'entreprise doivent être capables de fonctionner avec un nouveau type d'utilisateur et leurs besoins. Ces utilisateurs ont sciemment des droits limités et ont accès à un type de données strictement défini.

Toutes les exigences ci-dessus pour les logiciels à l'échelle de l'entreprise sont satisfaites par les systèmes distribués - le schéma de distribution des calculs est illustré à la Fig. un.

Bien entendu, les applications distribuées ne sont pas exemptes de défauts. D'une part, leur exploitation est coûteuse, et d'autre part, la création de telles applications est un processus laborieux et complexe, et le coût d'une erreur au stade de la conception est très élevé. Néanmoins, le développement d'applications distribuées avance bien - le jeu en vaut la chandelle, car de tels logiciels contribuent à améliorer l'efficacité de l'organisation.

Ainsi, le paradigme de l'informatique distribuée implique la présence de plusieurs centres (serveurs) de stockage et de traitement de l'information, mettant en œuvre des fonctions diverses et espacés. Ces centres, en plus des demandes des clients du système, doivent également répondre aux demandes des uns des autres, car dans certains cas, la solution de la première tâche peut nécessiter les efforts conjoints de plusieurs serveurs. Pour gérer les demandes complexes et le fonctionnement du système dans son ensemble, un logiciel de contrôle spécialisé est nécessaire. Et enfin, l'ensemble du système doit être « immergé » dans une sorte d'environnement de transport qui assure l'interaction de ses parties.

Les systèmes informatiques distribués ont des propriétés communes telles que :

· Gérabilité - implique la capacité du système à contrôler efficacement ses composants. Ceci est réalisé grâce à l'utilisation d'un logiciel de contrôle ;

· Performance - fournie en raison de la possibilité de redistribuer la charge sur les serveurs du système à l'aide du logiciel de contrôle ;

Évolutivité - s'il est nécessaire d'augmenter physiquement la productivité, un système distribué peut facilement intégrer de nouvelles ressources informatiques dans son environnement de transport ;

· Extensibilité - de nouveaux composants (logiciel serveur) avec de nouvelles fonctions peuvent être ajoutés aux applications distribuées.

L'accès aux données dans les applications distribuées est possible à partir du logiciel client et d'autres systèmes distribués peuvent être organisés à différents niveaux - du logiciel client et des protocoles de transport à la protection des serveurs de bases de données.

Riz. 2. Les principaux niveaux de l'architecture d'une application distribuée

Les propriétés listées des systèmes distribués sont une raison suffisante pour supporter la complexité de leur développement et le coût élevé de leur maintenance.

Architecture d'applications distribuées

Considérez l'architecture d'une application distribuée qui lui permet d'effectuer des fonctions complexes et variées. Différentes sources offrent différentes options pour créer des applications distribuées. Et elles ont toutes le droit d'exister, car de telles applications résolvent le plus large éventail de problèmes dans de nombreux domaines, et le développement irrépressible d'outils et de technologies de développement pousse à une amélioration continue.

Néanmoins, il existe l'architecture la plus générale d'une application distribuée, selon laquelle elle est divisée en plusieurs couches logiques, les couches informatiques. Les applications, comme vous le savez, sont conçues pour traiter des informations, et nous pouvons en distinguer trois fonctions principales :

· Présentation des données (niveau utilisateur). Ici, les utilisateurs de l'application peuvent visualiser les données nécessaires, envoyer une demande d'exécution, saisir de nouvelles données dans le système ou les modifier ;

· Informatique (niveau intermédiaire, middleware). A ce niveau, la logique métier de l'application est concentrée, les flux de données sont contrôlés et l'interaction des parties de l'application est organisée. C'est la concentration de toutes les fonctions de traitement et de contrôle des données à un seul niveau qui est considérée comme le principal avantage des applications distribuées ;

· Stockage de données (couche de données). Il s'agit du niveau du serveur de base de données. Les serveurs eux-mêmes, les bases de données, les outils d'accès aux données et divers outils auxiliaires se trouvent ici.

Cette architecture est souvent appelée architecture à trois niveaux ou à trois niveaux. Et très souvent sur la base de ces "trois baleines", la structure de l'application développée est créée. Il est toujours noté que chaque niveau peut être subdivisé en plusieurs sous-niveaux. Par exemple, le niveau utilisateur peut être décomposé en l'interface utilisateur réelle et les règles de validation et de traitement des données d'entrée.

Bien entendu, si l'on prend en compte la possibilité de découpage en sous-niveaux, alors n'importe quelle application distribuée peut être incluse dans l'architecture à trois niveaux. Mais ici, on ne peut ignorer une autre caractéristique inhérente aux applications distribuées - c'est la gestion des données. L'importance de cette fonctionnalité est évidente car il est très difficile de créer une application distribuée du monde réel (avec tous les postes clients, middleware, serveurs de bases de données, etc.) qui ne gère pas ses requêtes et ses réponses. Par conséquent, une application distribuée doit avoir une autre couche logique - la couche de gestion des données.

Riz. 3. Répartition de la logique métier à travers les niveaux d'une application distribuée

Par conséquent, il est conseillé de diviser le niveau intermédiaire en deux niveaux indépendants : le niveau de traitement des données (puisqu'il est nécessaire de prendre en compte l'avantage important qu'il donne - la concentration des règles métier pour le traitement des données) et le niveau de gestion des données. Ce dernier permet de contrôler l'exécution des demandes, maintient le travail avec les flux de données et organise l'interaction des parties du système.

Ainsi, il existe quatre couches principales d'une architecture distribuée (voir Fig. 2) :

· Présentation des données (niveau utilisateur);

· Règles de logique métier (couche informatique) ;

· Gestion des données (couche de gestion des données);

· Stockage de données (couche de stockage de données).

Trois des quatre niveaux, à l'exception du premier, sont directement impliqués dans le traitement des données, et la couche de présentation des données permet de les visualiser et de les éditer. À l'aide de cette couche, les utilisateurs reçoivent des données de la couche de traitement des données, qui, à son tour, récupère les informations des référentiels et effectue toutes les transformations de données nécessaires. Après avoir saisi de nouvelles informations ou modifié des données existantes, les flux de données sont redirigés vers l'arrière : de l'interface utilisateur à la couche de règles métier jusqu'au référentiel.

Une autre couche - la gestion des données - se tient à l'écart du backbone de données, mais elle assure le bon fonctionnement de l'ensemble du système, en gérant les demandes et les réponses et l'interaction de parties de l'application.

Séparément, il est nécessaire d'envisager la possibilité d'afficher les données en mode "lecture seule". Dans ce cas, la couche de traitement des données n'est pas utilisée dans le schéma général de transfert de données, car aucune modification n'est nécessaire. Et le flux d'informations lui-même est unidirectionnel - du stockage au niveau de présentation des données.

Structure physique des applications distribuées

Passons maintenant aux couches physiques des applications distribuées. La topologie d'un système distribué implique une division en plusieurs serveurs de bases de données, serveurs de traitement de données et un ensemble de clients locaux et distants. Tous peuvent être situés n'importe où : dans le même bâtiment ou sur un autre continent. Dans tous les cas, les parties d'un système distribué doivent être connectées par des lignes de communication fiables et sécurisées. Quant au débit de transfert de données, il dépend en grande partie de l'importance de la connexion entre les deux parties du système en termes de traitement et de transmission des données, et dans une moindre mesure de leur éloignement.

Répartition de la logique métier entre les niveaux d'application distribués

Il est maintenant temps de passer à une description détaillée des niveaux d'un système distribué, mais disons d'abord quelques mots sur la distribution des fonctionnalités de l'application à travers les niveaux. La logique métier peut être mise en œuvre à n'importe quel niveau de l'architecture à trois niveaux.

Les serveurs de base de données peuvent non seulement stocker des données dans des bases de données, mais également contenir une partie de la logique métier de l'application dans des procédures stockées, des déclencheurs, etc.

Les applications clientes peuvent également implémenter des règles de traitement des données. Si l'ensemble des règles est minimal et se résume principalement à des procédures de contrôle de l'exactitude de la saisie des données, nous avons affaire à un client « léger ». En revanche, un client lourd contient une grande partie des fonctionnalités de l'application.

Le niveau de traitement des données est en fait destiné à mettre en œuvre la logique métier de l'application, et toutes les règles de base du traitement des données sont concentrées ici.

Ainsi, dans le cas général, la fonctionnalité de l'application est « étalée » dans toute l'application. Toute la variété de distribution de la logique métier à travers les niveaux d'application peut être représentée sous la forme d'une courbe lisse montrant la proportion de règles de traitement de données concentrées à un endroit spécifique. Les courbes de la fig. 3 sont de nature qualitative, mais permettent néanmoins de voir comment des changements dans la structure de l'application peuvent affecter la répartition des règles.

Et la pratique confirme cette conclusion. Après tout, il y a toujours quelques règles qui doivent être implémentées dans les procédures stockées du serveur de base de données, et il est très souvent pratique de transférer certaines opérations initiales avec des données côté client - au moins pour empêcher le traitement de requêtes incorrectes .

Couche de présentation

La couche de présentation des données est la seule disponible pour l'utilisateur final. Cette couche simule les postes clients d'une application distribuée et les logiciels correspondants. Les capacités du poste de travail client sont principalement déterminées par les capacités du système d'exploitation. Selon le type d'interface utilisateur, le logiciel client est divisé en deux groupes : les clients qui utilisent les fonctionnalités de l'interface graphique (par exemple, Windows) et les clients Web. Mais dans tous les cas, l'application cliente doit fournir les fonctions suivantes :

· Réception de données;

· Présentation des données pour visualisation par l'utilisateur ;

· Édition de données;

· Vérification de l'exactitude des données saisies ;

· Enregistrer les modifications apportées;

· Gestion des exceptions et affichage des informations sur les erreurs pour l'utilisateur.

Il est souhaitable de concentrer toutes les règles métier au niveau du traitement des données, mais en pratique cela n'est pas toujours possible. Ensuite, ils parlent de deux types de logiciels clients. Le client léger contient un ensemble minimal de règles métier, tandis que le client lourd implémente une partie importante de la logique de l'application. Dans le premier cas, l'application distribuée est beaucoup plus facile à déboguer, moderniser et étendre, dans le second, vous pouvez minimiser les coûts de création et de maintenance de la couche de gestion des données, car certaines opérations peuvent être effectuées côté client, et seul le transfert de données tombe sur le middleware.

Couche de traitement des données

La couche de traitement des données combine les parties qui implémentent la logique métier de l'application, et est un intermédiaire entre la couche de présentation et la couche de stockage. Toutes les données le traversent et y subissent des modifications, en raison du problème en cours de résolution (voir Fig. 2). Les fonctions de ce niveau sont les suivantes :

· Traitement des flux de données conformément aux règles de l'entreprise ;

· Interagir avec la couche de présentation des données pour recevoir les demandes et renvoyer les réponses ;

· Interaction avec la couche de stockage de données pour envoyer des demandes et recevoir des réponses.

Le plus souvent, la couche de traitement des données est assimilée au middleware d'une application distribuée. Cette situation est pleinement vraie pour un système « idéal » et seulement partiellement pour des applications réelles (voir Fig. 3). Quant à ces derniers, le middleware pour eux contient une grande partie des règles de traitement des données, mais certaines d'entre elles sont implémentées dans des serveurs SQL sous forme de procédures stockées ou de déclencheurs, et certaines sont incluses dans le logiciel client.

Un tel "flou" de la logique métier est justifié, car il permet de simplifier certaines des procédures de traitement des données. Prenons un exemple classique d'instruction de commande. Il peut inclure uniquement les noms des produits en stock. Par conséquent, lors de l'ajout d'un certain article à la commande et de la détermination de sa quantité, le nombre correspondant doit être soustrait du reste de cet article dans l'entrepôt. De toute évidence, le meilleur moyen d'implémenter cette logique consiste à utiliser le serveur de base de données, soit une procédure stockée, soit un déclencheur.

Couche de gestion des données

La couche de gestion des données est nécessaire pour garantir que l'application reste cohérente, résiliente et fiable, qu'elle a la capacité de se moderniser et d'évoluer. Il garantit l'exécution des tâches du système, sans lui, des parties de l'application (serveurs de base de données, serveurs d'applications, middleware, clients) ne pourront pas interagir entre elles et les connexions interrompues lors d'une augmentation de la charge ne pourront pas être restaurées.

De plus, divers services système de l'application peuvent être mis en œuvre au niveau de la gestion des données. Après tout, il y a toujours des fonctions communes à l'ensemble de l'application qui sont nécessaires au fonctionnement de tous les niveaux de l'application, par conséquent, elles ne peuvent être situées sur aucun des autres niveaux.

Par exemple, un service d'horodatage fournit à toutes les parties d'une application des horodatages système qui les synchronisent. Imaginez qu'une application distribuée dispose d'un serveur qui envoie des tâches aux clients avec une échéance précise. Si la date limite est manquée, la tâche doit être enregistrée avec le calcul du temps de retard. Si les postes clients sont situés dans le même bâtiment que le serveur, ou dans une rue adjacente, pas de problème, l'algorithme comptable est simple. Mais que se passe-t-il si les clients sont situés dans des fuseaux horaires différents - dans d'autres pays ou même à l'étranger ? Dans ce cas, le serveur doit être capable de calculer la différence en tenant compte des fuseaux horaires lors de l'envoi des tâches et de la réception des réponses, et les clients devront ajouter des informations de service sur l'heure locale et le fuseau horaire aux rapports. Si un service unique est inclus dans une application distribuée, ce problème n'existe tout simplement pas.

En plus du service unique, le niveau de gestion des données peut contenir des services pour stocker des informations générales (informations sur l'application dans son ensemble), générer des rapports généraux, etc.

Ainsi, les fonctions de la couche de gestion des données incluent :

· Gérer des parties d'une application distribuée;

· Gestion des connexions et des canaux de communication entre les parties de l'application ;

· Contrôle des flux de données entre les clients et les serveurs et entre les serveurs ;

· Contrôle de charge;

· Mise en place des services système de l'application.

Il convient de noter que la couche de gestion des données est souvent créée sur la base de solutions prêtes à l'emploi fournies sur le marché des logiciels par divers fabricants. Si les développeurs ont choisi l'architecture CORBA pour leur application, alors celle-ci intègre un Object Request Broker (ORB), si la plateforme est Windows, ils disposent de divers outils à leur service : technologie COM+ (développement de la technologie Microsoft Transaction Server, MTS), technologie de traitement des files d'attente de messages MSMQ, technologie Microsoft BizTalk, etc.

Couche de stockage de données

Le niveau de stockage regroupe les serveurs SQL et les bases de données utilisées par l'application. Il apporte une solution aux tâches suivantes :

· Stocker les données dans une base de données et les maintenir en état de fonctionnement;

· Traitement des demandes du niveau de traitement des données et restitution des résultats ;

· Implémentation d'une partie de la logique métier d'une application distribuée ;

· Gestion de bases de données distribuées à l'aide d'outils d'administration de serveurs de bases de données.

En plus des fonctions évidentes - stockage des données et traitement des requêtes, une couche peut contenir une partie de la logique métier de l'application en procédures stockées, triggers, contraintes, etc. Et la structure même de la base de données applicative (tables et leurs champs, index, clés étrangères, etc.) ) il existe une implémentation de la structure de données avec laquelle fonctionne l'application distribuée, et la mise en œuvre de certaines règles de logique métier. Par exemple, l'utilisation d'une clé étrangère dans une table de base de données nécessite la création d'une restriction correspondante sur les manipulations de données, puisque les enregistrements de la table principale ne peuvent pas être supprimés s'il existe des enregistrements correspondants liés par la clé étrangère de la table.

La plupart des serveurs de base de données prennent en charge diverses procédures d'administration, notamment la gestion de base de données distribuée. Il s'agit notamment de la réplication des données, de l'archivage à distance, des outils d'accès aux bases de données distantes, etc. La possibilité d'utiliser ces outils doit être prise en compte lors du développement de la structure de votre propre application distribuée.

La connexion aux bases de données SQL Server se fait principalement avec le logiciel client du serveur. En outre, diverses technologies d'accès aux données peuvent également être utilisées, par exemple ADO (ActiveX Data Objects) ou ADO.NET. Mais lors de la conception d'un système, il est nécessaire de prendre en compte que les technologies d'accès aux données fonctionnellement intermédiaires n'appartiennent pas au niveau de stockage des données.

Extensions de niveau de base

Les niveaux ci-dessus d'architecture d'application distribuée sont basiques. Ils forment la structure de l'application créée dans son ensemble, mais en même temps, bien sûr, ils ne peuvent pas fournir la mise en œuvre d'une application - les domaines et les tâches sont trop vastes et diversifiés. Dans de tels cas, l'architecture d'une application distribuée peut être étendue avec des couches supplémentaires conçues pour refléter les fonctionnalités de l'application en cours de création.

Entre autres, il existe deux des extensions de niveau de base les plus couramment utilisées.

La couche d'interface métier est située entre la couche d'interface utilisateur et la couche de traitement des données. Il masque aux applications clientes les détails de la structure et de la mise en œuvre des règles métier de la couche de traitement des données, fournissant une abstraction du code de l'application cliente des fonctionnalités de mise en œuvre de la logique de l'application.

En conséquence, les développeurs d'applications clientes utilisent un certain ensemble de fonctions nécessaires - un analogue d'une interface de programmation d'application (API). Cela rend le logiciel client indépendant de la mise en œuvre de la couche informatique.

Bien sûr, lors de modifications importantes du système, vous ne pouvez pas vous passer de modifications globales, mais le niveau de l'interface métier vous permet de ne le faire que si cela est absolument nécessaire.

La couche d'accès aux données est située entre la couche de stockage de données et la couche de traitement des données. Il permet de rendre la structure de l'application indépendante d'une technologie de stockage de données spécifique. Dans de tels cas, les objets logiciels de la couche de traitement des données envoient des requêtes et reçoivent des réponses en utilisant les moyens de la technologie d'accès aux données choisie.

Lors de la mise en œuvre d'applications sur la plate-forme Windows, la technologie d'accès aux données ADO est le plus souvent utilisée car elle fournit un moyen universel d'accéder à une grande variété de sources de données - des serveurs SQL aux feuilles de calcul. Pour les applications sur la plate-forme .NET, la technologie ADO.NET est utilisée.