L'abréviation IPC signifie communication interprocessus, c'est-à-dire l'interaction des processus. Habituellement, cela fait référence au transfert de messages de divers types entre les processus d'un système d'exploitation. Dans ce cas, diverses formes de synchronisation peuvent être utilisées, requises par les types modernes d'interaction, effectuées, par exemple, via la mémoire partagée.

Au fur et à mesure que les systèmes d'exploitation Unix ont évolué au cours des 30 dernières années, les méthodes de transmission de messages ont évolué comme suit:

■ Les tuyaux (chapitre 4) étaient la première forme largement utilisée de communication de processus disponible pour les programmes et l'utilisateur (à partir de l'interpréteur de commandes). Le principal inconvénient des tubes est qu'ils ne peuvent pas être utilisés entre des processus qui n'ont pas de parent commun (ancêtre), mais cette lacune a été éliminée avec l'introduction de tubes nommés, ou tubes FIFO (chapitre 4).

■ Les files d'attente de messages System V (chapitre 4) ont été ajoutées aux noyaux System V au début des années 1980. Ils peuvent être utilisés pour transmettre des messages entre les processus sur le même nœud, que les processus soient liés ou non. Malgré le préfixe «System V» conservé, la plupart des versions modernes d'Unix, y compris celles qui ne sont pas dérivées de System V, prennent en charge ces files d'attente.

REMARQUE

Pour les processus Unix, le terme affinité signifie que les processus ont un ancêtre commun. On suppose que les processus frères ont été créés par ce processus ancêtre en utilisant une ou plusieurs fourches. L'exemple le plus simple serait de bifurquer un processus deux fois, ce qui créerait deux processus enfants. Ensuite, nous pouvons parler de la relation de ces processus entre eux. Naturellement, chaque processus engendré est un parent du reproducteur. Le parent peut prendre en charge la capacité de communiquer avec le processus enfant (en créant un tube ou une file d'attente de messages) avant d'appeler fork, et cet objet IPC sera hérité par le processus enfant. Pour plus d'informations sur l'héritage des objets IPC, consultez le tableau. 1.4. Il convient également de noter que tous les processus Unix sont théoriquement des descendants du processus init, qui démarre tout ce qui est nécessaire pendant le processus de démarrage. D'un point de vue pratique, il est préférable de compter l'affinité des processus à partir du shell de connexion et de tous les processus créés par celui-ci. Le chapitre 9 traite des sessions et des relations de processus plus en détail.

REMARQUE

Des notes comme celle-ci seront utilisées par nous pour clarifier les détails de la mise en œuvre, pour fournir un contexte historique et des conseils utiles.

■ Les files d'attente de messages Posix (chapitre 5) ont été ajoutées à la norme Posix (1003.1b-1993, qui est abordée plus en détail dans la section 1.7). Ils peuvent être utilisés pour interagir avec des processus liés et non liés sur n'importe quel nœud.

■ Les appels de procédure à distance (RPC, partie 5) ont été introduits dans les années 1980 comme moyen d'appeler des fonctions sur un système (serveur) par un programme s'exécutant sur un autre système (client). Cet outil a été développé comme une alternative pour simplifier la programmation réseau. Étant donné que les informations sont généralement transmises entre le client et le serveur (les arguments des valeurs d'appel et de retour de fonction sont transmis) et que RPC peut être utilisé entre le client et le serveur sur le même nœud, RPC peut également être considéré comme une forme de messagerie.

Il est également intéressant de regarder l'évolution des différentes formes de synchronisation au fur et à mesure qu'Unix évoluait:

■ Les tout premiers programmes nécessitant une synchronisation (le plus souvent pour empêcher plusieurs processus de modifier le contenu d'un fichier en même temps) ont utilisé le système de fichiers, dont certains sont décrits à la section 9.8,

■ Le verrouillage des enregistrements (chapitre 9) a été ajouté aux noyaux Unix au début des années 1980 et a été normalisé avec Posix.1 en 1988.

■ Les sémaphores System V (chapitre 11) ont été ajoutés avec la mémoire partagée System V (chapitre 14) et les files d'attente de messages System V (début des années 1980). Ces IPC sont pris en charge par la plupart des versions Unix modernes.

■ Les sémaphores Posix (sémaphores Posix - Chapitre 10) et la mémoire partagée Posix (Chapitre 13) ont également été ajoutés au standard Posix (1003.1b-1993, précédemment mentionné à propos des files d'attente de messages Posix).

■ Les exclusions mutuelles et les variables conditionnelles (chapitre 7) sont deux formes de synchronisation définies par le standard des threads Posix (Pthreads - 1003.1c-1995). Bien qu'ils soient généralement utilisés pour la synchronisation entre les threads, ils peuvent également être utilisés lors de l'organisation des interactions entre processus.

S Les verrous en lecture-écriture (chapitre 8) sont une forme supplémentaire de synchronisation. Il n'est pas encore inclus dans le standard Posix, mais le sera probablement bientôt.

1.2. Processus, fils et partage d'informations

Dans le modèle de programmation Unix traditionnel, plusieurs processus peuvent s'exécuter simultanément sur un système, chacun se voyant attribuer son propre espace d'adressage. Ceci est illustré dans la fig. 1.1.

Figure: 1.1. Partage d'informations entre les processus

1. Les deux processus sur le côté gauche partagent des informations stockées dans l'un des objets du système de fichiers. Pour accéder à ces données, chaque processus doit accéder au noyau (en utilisant les fonctions read, write, lseek, write, lseek et similaires). Une certaine forme de synchronisation est requise lors de la modification d'un fichier, pour éviter les interférences lorsque plusieurs processus écrivent dans le fichier en même temps et pour protéger les processus lisant à partir du fichier de ceux qui y écrivent.

2. Les deux processus au milieu de la figure partagent des informations stockées dans le noyau. Des exemples dans ce cas sont un tube, une file d'attente de messages ou un sémaphore System V. Dans ce cas, les appels système seront utilisés pour accéder aux informations partagées.

3. Les deux processus sur le côté droit partagent une zone de mémoire commune à laquelle chacun des processus peut accéder. Une fois cette zone de mémoire accédée, les processus peuvent accéder aux données sans avoir besoin du noyau du tout. Dans ce cas, comme dans le premier, les processus utilisant la mémoire partagée doivent également être synchronisés.

Veuillez noter que dans aucun de ces cas, le nombre de processus de communication n'est limité à deux. Chacune des méthodes décrites fonctionne pour un nombre arbitraire de processus de communication. Dans la figure, nous n'en représentons que deux par souci de simplicité.

Ruisseaux

Bien que le concept de processus dans les systèmes Unix existe depuis très longtemps, la possibilité d'utiliser plusieurs threads dans un même processus est relativement nouvelle. La norme de filetage Posix.1 appelée Pthreads a été adoptée en 1995. Du point de vue de l'interaction des processus, tous les threads d'un processus ont des variables globales communes (c'est-à-dire que le modèle de threading utilise la mémoire partagée). Cependant, les threads nécessitent un accès synchronisé aux données globales. En général, la synchronisation, bien que n'étant pas une forme d'IPC en soi, est souvent utilisée en conjonction avec diverses formes d'IPC pour contrôler l'accès aux données.

Ce livre décrit la communication entre les processus et entre les threads. Nous supposons qu'il existe un environnement dans lequel la programmation multithread est prise en charge, et nous utiliserons des expressions comme "si le tube est vide, le thread appelant se bloquera jusqu'à ce qu'un autre thread écrit sur le tube." Si le système ne prend pas en charge les threads, vous pouvez remplacer «threads» par «processus» dans cette phrase et vous obtenez la définition Unix classique d'un verrou qui se produit lors de la lecture d'un tube vide avec la commande read. Toutefois, sur un système qui prend en charge les threads, seul le thread qui a demandé des données à partir du canal vide est bloqué et tous les autres threads du processus continueront à s'exécuter. Un autre thread du même processus ou un thread d'un autre processus peut écrire des données dans le tube.

L'annexe B résume certaines des principales caractéristiques des threads et décrit les cinq principales fonctions de Pthread utilisées dans les programmes de ce livre.

1.3. Persistance des objets IPC

Vous pouvez définir la persistance de tout objet IPC comme la durée de son existence. En figue. 1.2 montre trois groupes possibles auxquels les objets peuvent être attribués en termes de capacité de survie.

Figure: 1.2. Persistance des objets IPC

1. Un objet IPC, dont la persistance est déterminée par un processus (processus persistant), existe jusqu'à ce qu'il soit fermé par le dernier processus dans lequel il est encore ouvert. Un exemple est des tubes non nommés et nommés (FIFO).

2. L'objet IPC, dont la persistance est déterminée par le noyau (noyau persistant), existe jusqu'à ce que le noyau soit redémarré ou jusqu'à ce que l'objet soit explicitement supprimé. Les exemples sont les files d'attente de messages System V, les sémaphores et la mémoire partagée. La persistance des files d'attente de messages Posix, des sémaphores et de la mémoire partagée doit être au moins déterminée par le noyau, mais peut également être déterminée par le système de fichiers, en fonction de l'implémentation.

3. L'objet IPC, dont la persistance est déterminée par le système de fichiers (système de fichiers persistant), existe jusqu'à ce qu'il soit explicitement supprimé. Sa valeur est conservée même lorsque le noyau est redémarré. Les files d'attente de messages Posix, les sémaphores et la mémoire partagée ont cette propriété lorsqu'ils sont implémentés via des fichiers mappés (ce n'est pas toujours le cas).

Soyez prudent lorsque vous déterminez la persistance d'un objet IPC, car ce n'est pas toujours évident. Par exemple, les données d'un tube sont traitées par le noyau, mais la durabilité des tubes est déterminée par les processus, pas par le noyau, car après que le dernier processus qui a ouvert le tube pour la lecture la ferme, le noyau rejette toutes les données et supprime le tube. De même, bien que les tubes FIFO soient nommés dans le système de fichiers, leur persistance est également déterminée par les processus, puisque toutes les données d'un tel tube sont vidées après que le dernier processus dans lequel il a été ouvert l'a fermé.

Table 1.1 résume les informations sur la capacité de survie des objets IPC précédemment répertoriés.

Tableau 1.1. Persistance de divers types d'objets IPC

Type IPC	La vitalité détermine
Tuyau	Processus
Tube nommé (FIFO)	Processus
Exclusion mutuelle Posix (mutex)	Processus
Variable de condition Posix	Processus
Verrouillage lecture-écriture Posix (verrouillage)	Processus
Verrou d'écriture Fcntl	Processus
File d'attente de messages Posix	Coeur
Sémaphore nommé	Coeur
Sémaphore Posix en mémoire (sémaphore basé sur la mémoire)	Processus
Mémoire partagée Posix	Coeur
File d'attente de messages System V	Coeur
Sémaphore du système V	Coeur
	Coeur
Prise TCP	Processus
Prise UDP	Processus
Socket de domaine Unix	Processus

Notez qu'aucun des types IPC de ce tableau n'a de capacité de survie du système de fichiers. Nous avons déjà mentionné que les trois types d'objets IPC dans le standard Posix maiont ce type de survie en fonction de la mise en œuvre. L'écriture de données dans un fichier fournit évidemment la persistance définie par le système de fichiers, mais les IPC ne sont généralement pas implémentés de cette manière. La plupart des objets IPC ne sont pas conçus pour survivre après un redémarrage car les processus ne survivent pas. Exiger la survie du système de fichiers est susceptible de dégrader les performances de ce type IPC, et généralement l'une des tâches du développeur est de fournir haute performance.

1.4. Espaces de noms

Si deux processus non liés utilisent une sorte d'IPC pour échanger des informations, l'objet IPC doit avoir un nom ou un identifiant afin que l'un des processus (généralement appelé le serveur) puisse créer cet objet, et l'autre processus (généralement un ou plusieurs clients - client) pourrait faire référence à cet objet particulier.

Les canaux n'ont pas de noms (et ne peuvent donc pas être utilisés pour la communication entre des processus non liés), mais les FIFO sont mappés aux noms du système de fichiers qui sont leurs identifiants (par conséquent, les canaux FIFO peuvent être utilisés pour la communication entre des processus non liés). Pour les autres types de CIB abordés dans les chapitres suivants, des conventions de dénomination supplémentaires sont utilisées. L'ensemble des noms possibles pour un type particulier d'IPC est appelé son espace de nom. L'espace de noms est un terme important car pour tous les types d'IPC, à l'exception des canaux simples, le nom définit la manière dont le client et le serveur communiquent pour la messagerie.

Table 1.2 résume les conventions de dénomination pour divers types d'IPC

Tableau 1.2. Espaces de noms pour différents types IPC

Type IPC	Espace de noms à créer ou ouvrir	ID après ouverture	Posix.1 1996	Unix 98
Canal	(Sans nom)	Descripteur
FIFO	Nom de fichier (chemin d'accès)	Descripteur
Exclusion mutuelle Posix	(Sans nom)	Pointeur de type pthread_mutex_t
Variable conditionnelle Posix	(Sans nom)	Pointeur de type pthread_cond_t
	(Sans nom)	Pointeur de type pthread_rwlock_t
Verrouillage d'enregistrement Fcntl	Nom de fichier	Descripteur
Mémoire partagée Posix	Nom IPC Posix	Descripteur
File d'attente de messages System V	Clé Key_t	ID du système V IPC
Sémaphore du système V	Clé Key_t	ID du système V IPC
Mémoire partagée System V	Clé Key_t	ID du système V IPC
Des portes	Nom de fichier	Descripteur
Appel de procédure à distance Sun (RPC)	Programme / version	Poignée RPC
Prise TCP	Adresse IP et port TCP	Descripteur	.1g
Prise UDP	Adresse IP et port TCP	Descripteur	.1g
Socket de domaine Unix	Nom complet du fichier	Descripteur	.1g

Il indique également quelles formes d'IPC sont contenues dans la norme Posix.1 de 1996 et lesquelles ont été incluses dans la norme Unix 98. Ces deux normes sont examinées plus en détail dans la section 1.7. À titre de comparaison, nous avons inclus trois types de socket dans ce tableau, qui sont détaillés dans. Veuillez noter que l'interface Sockets (API) est normalisée par le groupe de travail Posix.1g et devrait faire partie de la norme Posix.1 à l'avenir.

Bien que la norme Posix. 1 et permet l'utilisation de sémaphores, leur support est optionnel pour les fabricants. Table 1.3 résume les fonctions décrites dans les normes Posix.1 et Unix 98. Chaque fonction peut être obligatoire, non définie ou facultative. Pour les fonctions optionnelles, nous spécifions le nom de la constante (par exemple, _POSIX_THREADS) qui sera définie (généralement dans le fichier d'en-tête ) si pris en charge. Notez que Unix 98 contient Posix.1 en tant que sous-ensemble.

Tableau 1.3. Divers formulaires IPC disponibles

Type IPC	Posix.1 1996	Unix 98
Chaîne de programme	Obligatoire	Obligatoire
FIFO	Obligatoire	Obligatoire
Exclusion mutuelle Posix	_POSIX_THREADS	Obligatoire
Variable conditionnelle Posix	_POSIX_THREADS	Obligatoire
Exclusions mutuelles et variables conditionnelles entre processus	_POSIX_THREADS_PROCESS_SHARED	Obligatoire
Verrou en lecture-écriture Posix	(Non défini)	Obligatoire
Verrouillage d'enregistrement Fcntl	Obligatoire	Obligatoire
File d'attente de messages Posix	_POSIX_MESSAGE_PASSING	_XOPEN_REALTIME
Sémaphores Posix	_POSIX_SEMAPHORES_	_XOPEN_REALTIME
Mémoire partagée Posix	_POSIX_SHARED_MEMORY_OBJECTS	_XOPEN_REALTIME
File d'attente de messages System V	(Non défini)	Obligatoire
Sémaphore du système V	(Non défini)	Obligatoire
Mémoire partagée System V	(Non défini)	Obligatoire
Des portes	(Non défini)	(Non déterminé)
Appel de procédure à distance Sun	(Non défini)	(Non déterminé)
Cartographie de la mémoire mmap	_POSIX_MAPPED_FILES ou POSIX_SHARED_MEMORY_OBJECTS	Obligatoire
Signaux en temps réel	_POSIX_REALTIME_SIGNALS	_XOPEN_REALTIME

1.5. Fork, exécuter et quitter sur des objets IPC

Nous devons acquérir une compréhension des effets de fork, exec et _exit sur les différentes formes d'IPC dont nous discutons (la dernière fonction listée est appelée par la fonction exit). Les informations sur ce problème sont résumées dans le tableau. 1.4.

La plupart des fonctions sont décrites plus loin dans le texte du livre, mais il y a quelques points à souligner ici. Premièrement, l'appel de fork à partir d'un processus multithread crée un désordre de variables de synchronisation sans nom (exclusions mutuelles, variables conditionnelles, verrous et sémaphores stockés en mémoire). La section 6.1 du livre contient les détails nécessaires. On note juste en plus du tableau que si ces variables sont stockées en mémoire partagée et créées avec l'attribut accès général pour les processus, ils seront disponibles pour tout processus pouvant accéder à cette zone mémoire. Deuxièmement, les trois formulaires IPC System V ne peuvent pas être ouverts ou fermés. Comme vous pouvez le voir dans l'extrait 6.6 et les exercices 11.1 et 14.1, tout ce que vous devez savoir pour accéder à ces trois formes d'IPC est un identifiant. Par conséquent, ils sont disponibles pour tous les processus qui connaissent cet identifiant, bien qu'une certaine manipulation spéciale soit requise pour les sémaphores et la mémoire partagée.

Tableau 1.4. Action Fork, exec et _exit sur IPC

Type IPC	fourchette	exec	_sortie
Pipes anonymes et nommées	Le processus engendré obtient des copies de tous les descripteurs du processus parent	Tous les descripteurs ouverts restent ouverts sauf si le bit FD_CLOEXEC est défini pour eux	Toutes les poignées ouvertes sont fermées, les données du tube et du FIFO sont supprimées après la dernière fermeture
Files d'attente de messages Posix	Le processus engendré obtient des copies de tous les processus parents ouverts		Tous les descripteurs de file d'attente de messages ouverts sont fermés
Files d'attente de messages System V	Ça ne marche pas	Ça ne marche pas	Ça ne marche pas
Exceptions mutuelles et variables conditionnelles Posix	Partagé si vous utilisez la mémoire partagée avec l'attribut de partage inter-processus		Disparaît si ce n'est pas dans la mémoire partagée qui reste ouverte et a un attribut partagé
Verrous en lecture-écriture Posix		Disparaît s'il n'est pas stocké dans la mémoire partagée qui reste ouverte et a un attribut partagé	Disparaît s'il n'est pas stocké dans la mémoire partagée qui reste ouverte et a un attribut partagé
Sémaphores Posix stockés en mémoire	Partagé si vous utilisez la mémoire partagée et l'attribut partagé entre les processus	Disparaît s'il n'est pas stocké dans la mémoire partagée qui reste ouverte et a un attribut partagé	Disparaît s'il n'est pas stocké dans la mémoire partagée qui reste ouverte et a un attribut partagé
Sémaphores nommés Posix	Tout ce qui est ouvert dans le processus parent reste ouvert dans l'enfant	Tous les ouverts se ferment	Tous les ouverts se ferment
Sémaphores System V	Toutes les valeurs semadj dans le processus engendré sont définies sur 0	Toutes les valeurs semadj sont transmises au nouveau programme	Toutes les valeurs semadj sont ajoutées à la valeur de sémaphore correspondante
Verrouillage d'enregistrement Fcntl	Les verrous dans le processus parent ne sont pas hérités par le processus enfant	Les verrous ne sont pas modifiés tant que la poignée n'est pas fermée	Tous les verrous non libérés définis par le processus sont libérés
Cartographie de la mémoire		Les mappages de mémoire ne sont pas mappés
Mémoire partagée Posix	Les mappages de mémoire du processus parent sont enregistrés dans le fichier généré	Les mappages de mémoire sont réinitialisés	Les mappages de mémoire sont réinitialisés
Mémoire partagée System V	Les segments de mémoire partagée attachés restent attachés dans le processus engendré		Les segments de mémoire partagée attachés sont détachés
Des portes	Le processus enfant obtient des copies de toutes les poignées ouvertes du processus parent, mais seul le processus parent est le serveur lors de l'activation des portes via des poignées	Tous les descripteurs de porte doivent être fermés car ils sont créés avec le bit FD_CLOEXEC défini	Toutes les poignées ouvertes sont fermées

1.6. Gestion des erreurs: fonctions du wrapper

Dans tout programme réel, tout appel nécessite de vérifier la valeur de retour pour une erreur. Étant donné que les programmes se terminent généralement lorsque des erreurs se produisent, nous pouvons réduire la quantité de texte en définissant des fonctions wrapper qui appellent réellement la fonction, vérifier la valeur de retour et quitter lorsque des erreurs se produisent. Par convention, les noms des fonctions wrapper sont les mêmes que les noms des fonctions elles-mêmes, à l'exception de la première lettre, qui est en majuscule, par exemple

Un exemple de fonction wrapper est présenté dans l'extrait 1.1.

Liste 1.1. Fonction wrapper pour la fonction sem_post

390 si (sem_post (sem) \u003d\u003d –1)

391 err_sys ("erreur sem_post");

Si vous rencontrez un nom de fonction qui commence par une majuscule dans le texte, sachez qu'il s'agit de notre propre fonction wrapper. Il appelle une fonction avec le même nom commençant par une lettre minuscule. La fonction wrapper entraîne la fin du processus avec un message d'erreur, le cas échéant.

Lors de la description du code source inclus dans le livre, nous parlons toujours de la fonction de plus bas niveau appelée (par exemple, sem_post), et non de la fonction wrapper (par exemple, Sem_post). De même, l'index alphabétique contient les noms des fonctions elles-mêmes, et non les wrappers.

REMARQUE

Le format de code source ci-dessus est utilisé dans tout le texte. Toutes les lignes non vides sont numérotées. Le texte décrivant les sections du code commence par les numéros de la première et de la dernière ligne dans le champ vide à gauche. Parfois, avant un paragraphe de texte, il y a un court en-tête en gras qui présente le contenu principal du code décrit.

Le code commence par le nom du fichier source. Dans cet exemple, il s'agit du fichier wrapunix.c dans le répertoire lib. Puisque le code source de tous les exemples de ce livre est disponible gratuitement (voir la préface), vous pouvez facilement trouver le fichier que vous voulez. Compiler, exécuter et surtout modifier ces programmes lors de la lecture d'un livre est le meilleur moyen d'apprendre les concepts de la communication de processus.

Bien que cela puisse sembler un inconvénient d'utiliser de telles fonctions wrapper, vous vous débarrasserez de cette idée fausse au chapitre 7, où nous découvrons que les fonctions de thread ne définissent pas la variable Unix standard errno lorsqu'une erreur se produit; à la place, le code d'erreur est simplement renvoyé par la fonction. Cela signifie que chaque fois que nous appelons pthread, nous devons allouer de la mémoire pour une variable, y stocker la valeur de retour, puis définir errno sur cette variable avant d'appeler err_sys (Listing B.4). Pour éviter d'encombrer le texte avec des accolades, nous utilisons la virgule de l'opérateur du langage C et combinons l'attribution d'une valeur à errno et l'appel de err_sys dans une instruction, comme dans l'exemple suivant:

if ((n \u003d pthread_mutex_lock (& \u200b\u200bndone_mutex))! \u003d 0) errno \u003d n, err_sys ("erreur pthread_mutex_lock");

L'alternative consiste à définir une nouvelle fonction de gestion des erreurs qui prend un code d'erreur comme argument. Cependant, nous pouvons rendre ce morceau de code beaucoup plus lisible en écrivant

Pthread_mutex_lock (& \u200b\u200bndone_mutex);

où nous utilisons notre propre fonction wrapper illustrée dans l'extrait 1.2.

Liste 1.2. Implémentation d'un wrapper pour la fonction pthread_mutex_lock

126 Pthread_mutex_lock (pthread_mutex_t * mptr)

129 si ((n \u003d pthread_mutex_lock (mptr)) \u003d\u003d 0)

132 err_sys ("erreur pthread_mutex_lock");

REMARQUE

En utilisant soigneusement les capacités du langage C, nous pourrions utiliser des macros au lieu de fonctions, ce qui augmenterait la vitesse d'exécution du programme, mais ces fonctions wrapper sont rarement (voire jamais) goulot.

Notre convention de mettre en majuscule la première lettre d'un nom de fonction est un compromis. De nombreuses autres formes de notation ont été envisagées: utiliser le préfixe e (), le suffixe _e, etc. Notre version semble être la moins gênante et en même temps donner une indication visuelle qu'une autre fonction est appelée.

Cette méthode a un avantage secondaire: elle vérifie les erreurs renvoyées par les fonctions dont les codes de retour sont généralement ignorés, comme close et pthread_ mutex_lock.

Nous utiliserons ces fonctions wrapper dans le reste de ce livre, à moins que nous ayons besoin de vérifier explicitement une erreur et de la traiter d'une manière arbitraire autre que de terminer le processus. Nous ne fournissons pas le code source de tous les wrappers du livre, mais il est disponible gratuitement sur Internet (voir la préface).

Errno valeur

Lorsqu'une erreur se produit dans une fonction Unix, la variable globale errno prend une valeur positive indiquant le type d'erreur; la fonction renvoie généralement –1. Notre fonction err_sys affiche un message correspondant au code d'erreur (par exemple, Ressource temporairement indisponible - la ressource est temporairement indisponible - si la variable errno est EAGAIN).

La fonction affecte une valeur à la variable errno uniquement lorsqu'une erreur se produit. En cas d'arrêt ordonné, la valeur de cette variable n'est pas définie. Toutes les valeurs positives correspondent à des constantes avec des noms en majuscules commençant par E, généralement définies dans le fichier d'en-tête ... La valeur 0 correspond à l'absence d'erreurs.

Lorsque vous travaillez avec plusieurs threads, chaque thread doit avoir sa propre variable errno. L'allocation d'une variable à chaque thread est automatique, mais cela nécessite généralement une instruction au compilateur pour pouvoir rentrer dans le programme. Ceci est défini à l'aide des clés –D_REENTRANT ou –D_POSIX_C_SOURCE \u003d 199506L ou similaire. Souvent dans le titre La variable errno est définie comme une macro qui se développe en un appel de fonction si la constante _REENTRANT est définie. La fonction permet d'accéder à une copie de errno associée à un flux donné.

Plus loin dans le texte, nous utilisons des expressions telles que "mq_send function returns EMSGSIZE", ce qui signifie que la fonction renvoie une erreur (généralement la valeur de retour est –1) et affecte la valeur de la constante spécifiée à la variable errno.

1.7. Normes Unix

Les standards Unix sont actuellement définis par Posix et The Open Group.

Posix

Le nom Posix est dérivé de "Portable Operating System Interface", qui signifie en gros "Portable Operating System Interface". Ce n'est pas une norme, mais toute une famille développée par l'Institute for Electrical and Electronics Engineers (IEEE). Les normes Posix ont également été adoptées en tant que normes internationales ISO (Organisation internationale de normalisation) et CEI (Commission électrotechnique internationale), ou ISO / CEI. Les normes Posix sont passées par plusieurs étapes de développement.

■ IEEE 1003.1-1988 (317 pages) a été le premier standard Posix. Il a défini l'interface entre le langage C et le noyau Unix dans les domaines suivants: primitives d'implémentation des processus (fork, appels exec, signaux et temporisateurs), environnement de processus (ID utilisateurs, groupes de processus), fichiers et répertoires (toutes les fonctions d'E / S) , fonctionne avec le terminal, les bases de données système (mot de passe et fichiers de groupe), les formats d'archive tar et cpio.

REMARQUE

Le premier standard Posix est sorti dans une version fonctionnelle appelée IEEEIX en 1986. Le nom Posix a été suggéré par Richard Stallman.

■ Puis vint la norme IEEE 1003.1-1990 (356 pages). C'était également une norme internationale ISO / CEI 9945-1: 1990. Par rapport à la version 1988, les changements dans la version 1990 étaient minimes. "Partie 1: Interface de programme d'application système (API)" a été ajouté au titre, ce qui signifie que la norme décrit l'interface de programmation C (API) ...

■ IEEE 1003.2-1992 a été publié en deux volumes, totalisant environ 1 300 pages, et son titre contenait la ligne «Partie 2: Shell et utilitaires» (Partie 2: «Interprète et utilitaires»). Cette partie a défini un interpréteur (basé sur le shell Bourne dans Unix System V) et une centaine d'utilitaires (programmes communément appelés depuis l'interpréteur - de awk et basename à vi et yass). Dans ce livre, nous ferons référence à cette norme sous le nom de Posix. 2.

■ IEEE 1003.1b-1993 (590 pages) était à l'origine connue sous le nom d'IEEE P1003.4. Cette norme était un ajout à la norme 1003.1-1990 et incluait des extensions temps réel développées par le groupe de travail P1003.4: synchronisation de fichiers, E / S asynchrones, sémaphores, gestion de la mémoire, planification, horloges, minuteries et files d'attente de messages.

■ IEEE 1003.1 1996 Edition (743 pages), inclut 1003.1-1990 (API de base), 1003.1b-1993 (extensions en temps réel), 1003.1-1995 (Pthreads - flux de programmes Posix) et 1003.1i-1995 (modifications techniques à 1003.1b). Cette norme est également appelée ISO / CEI 9945-1: 1996. Trois chapitres sur les threads et des sections supplémentaires sur la synchronisation des threads (exclusions mutuelles et variables conditionnelles), la planification d'exécution des threads et la planification de la synchronisation ont été ajoutés. Dans ce livre, nous appelons cette norme Posix.1.

REMARQUE

Plus du quart des 743 pages de la norme se trouvaient dans une annexe intitulée «Justification et notes». Cette justification contient des informations historiques et une explication des raisons pour lesquelles certaines caractéristiques ont été ou n'ont pas été incluses dans la norme. La justification est souvent aussi utile que la norme elle-même.

Malheureusement, les normes IEEE ne sont pas disponibles gratuitement sur Internet. Les informations sur le lieu de commande du livre sont données dans la bibliographie sous le lien. Notez que les sémaphores ont été définis dans la norme d'extension en temps réel, séparés des exclusions mutuelles et des variables conditionnelles (qui ont été définies dans la norme Pthreads), ce qui explique certaines des différences dans les API de ces outils.

Enfin, notez que les verrous de lecture / écriture ne font pas partie des standards Posix. Ceci est discuté plus en détail au chapitre 8.

Dans le futur, une nouvelle version d'IEEE 1003.1 est prévue, incluant la norme P1003.1g, les interfaces réseau (sockets et XTI), qui sont décrites dans le premier volume de ce livre.

La préface Posix.1 de 1996 indique que l'ISO / CEI 9945 se compose des parties suivantes:

1. Interface de programmation système (API) (langage C).

2. Interprète et utilitaires.

3. Administration du système (en cours de développement).

Les parties 1 et 2 représentent ce que nous appelons Posix.1 et Posix.2.

Les travaux sur les normes Posix sont en cours et les auteurs de livres qui leur sont associés doivent s'occuper de tirer sur une cible en mouvement. Pour connaître l'état actuel des normes, voir http://www.pasc.org/standing/sd11.html.

Le groupe ouvert

L'Open Group a été formé en 1996 par la fusion de X / Open Company (fondée en 1984) et de l'Open Software Foundation (OSF, fondée en 1988). Ce groupe est un consortium international de fabricants et de consommateurs de l'industrie, du gouvernement et des établissements d'enseignement. Leurs standards sont également sortis en plusieurs versions:

■ Un quatrième numéro a été publié en 1992 (numéro 4) et en 1994 une deuxième version (numéro 4, version 2). Ce dernier est également connu sous le nom de Spec 1170, où le nombre magique 1170 est la somme du nombre d'interfaces système (926), d'en-têtes (70) et de commandes (174). Il existe également deux autres noms: X / Open Single Unix Specification et Unix 95.

■ En mars 1997, la deuxième version de la spécification unique Unix a été annoncée. Cette norme logicielle est également appelée Unix 98, et c'est ainsi que nous nous référons à cette spécification plus loin dans ce livre. Le nombre d'interfaces sous Unix 98 est passé de 1170 à 1434, bien que ce nombre atteigne 3030 pour un poste de travail, puisque ce nombre inclut le CDE (Common Desktop Environment), qui à son tour nécessite le système X Window et interface utilisateur Motif. Ceci est décrit en détail dans le livre. Des informations utiles peuvent également être trouvées sur http://www.UNIX-systems.org/version2.

REMARQUE

Depuis ce site, vous pouvez télécharger gratuitement la spécification Unix unifiée presque entièrement.

Versions d'Unix et portabilité

Pratiquement toutes les versions d'Unix que vous rencontrez aujourd'hui sont conformes à une variante du standard Posix.1 ou Posix.2. Nous disons «tout» parce qu'après avoir apporté des modifications à Posix (par exemple, en ajoutant des extensions en temps réel en 1993 et \u200b\u200bdes flux en 1996), il faut généralement un an ou deux aux fabricants pour adapter leurs logiciels à ces normes.

Historiquement, la plupart des systèmes Unix sont des descendants de BSD ou de System V, mais la distinction entre eux s'estompe progressivement à mesure que les fournisseurs évoluent vers les normes Posix. Les principales différences résident dans la zone l'administration du systèmecar aucune norme Posix ne couvre actuellement ce domaine.

Pour la plupart des exemples de ce livre, nous avons utilisé les systèmes d'exploitation Solaris 2.6 et Digital Unix 4.0B. Le fait est qu'au moment de la rédaction de cet article (fin 1997 - début 1998), seuls ces deux systèmes d'exploitation supportaient les threads de programme System V IPC, Posix IPC et Posix (Pthreads).

1.8. Commentaire sur les exemples IPC

Trois modèles (modèles) d'interaction sont le plus souvent utilisés dans le livre pour illustrer diverses fonctions:

1. Serveur de fichiers: une application client-serveur, où le client envoie une requête au serveur avec un nom de fichier, et le serveur renvoie son contenu au client.

2. Producteur-consommateur: un ou plusieurs threads ou processus (producteurs) placent des données dans un tampon public, et d'autres threads ou processus (consommateurs) effectuent diverses opérations avec ces données.

3. Augmentez le nombre séquentiel: un ou plusieurs threads ou processus augmentent l'index commun à tous. Ce numéro peut être stocké dans un fichier partagé ou dans une zone de mémoire partagée.

Le premier exemple illustre diverses formes de transmission de messages et les deux autres illustrent divers types de synchronisation et d'utilisation de la mémoire partagée.

Les tableaux 1.5, 1.6 et 1.7 sont une sorte de guide des programmes que nous développons sur divers sujets décrits dans le livre. Ces tableaux décrivent brièvement les programmes eux-mêmes et indiquent les numéros de liste correspondants.

1.9. Résumé

La communication de processus a toujours été l'un des problèmes sous Unix. Au fur et à mesure du développement du système, diverses solutions ont été proposées, et aucune n'était parfaite. Nous classons l'IPC en quatre types principaux.

1. Transfert de messages (canaux, FIFO, files d'attente de messages).

2. Synchronisation (exclusions mutuelles, variables conditionnelles, verrous en lecture-écriture, sémaphores).

3. Mémoire partagée (sans nom et nommée).

4. Procédures d'appel (portes sous Solaris, RPC Sun).

Nous considérons l'interaction des deux threads séparés d'un processus et de plusieurs processus indépendants.

La persistance de chaque type d'IPC est déterminée par le processus, le noyau ou le système de fichiers, en fonction de la durée de son existence. Lors du choix d'un type IPC pour une application spécifique, sa capacité de survie doit être prise en compte.

Une autre propriété de chaque type IPC est l'espace de noms, qui définit l'identification des objets IPC par les processus et les threads qui l'utilisent. Certains objets ne sont pas nommés (tubes, exclusions mutuelles, variables conditionnelles, verrous de lecture / écriture), d'autres sont nommés dans le système de fichiers (FIFO), certains sont caractérisés par ce que le chapitre 2 appelle des "noms IPC Posix", et certains le sont - Un autre type de nom décrit au chapitre 3 (Clés ou identificateurs IPC standard System V). En règle générale, le serveur crée un objet IPC avec un nom et les clients utilisent ce nom pour accéder à l'objet.

Le code source utilisé dans ce livre utilise les fonctions wrapper décrites dans la section 1.6 pour réduire la quantité de code tout en garantissant que toute fonction appelable renvoie une erreur. Toutes les fonctions de wrapper commencent par une majuscule.

Normes IEEE Posix - Posix.1, qui définit les bases de l'interface Unix C, et Posix.2, qui définit les commandes de base, sont les standards vers lesquels la plupart des vendeurs se dirigent. Cependant, les standards Posix sont rapidement absorbés (inclus dans) et étendus par les standards commerciaux, en particulier The Open Group (Unix 98).

Tableau 1.5. Versions du modèle client-serveur

Référencement	La description
4.1	Deux canaux entre les processus parents et enfants
4.5	Utilise popen et chat
4.6	Utilise deux canaux FIFO entre les processus parents et enfants
4.7	Deux FIFO entre un serveur indépendant et un client indépendant
4.10	Canaux FIFO entre un serveur série indépendant et plusieurs clients
4.12	Piping ou FIFO: formation d'entrées dans un flux d'octets
6.7	Deux files d'attente de messages System V
6.12	Une file d'attente de messages System V avec plusieurs clients
6.16	Une file d'attente de messages System V pour chaque client; plusieurs clients
15.15	Passer une poignée à travers une porte

Tableau 1.6. Versions producteur-consommateur

Référencement	La description
7.1	Exclusion mutuelle, plusieurs producteurs, un seul consommateur
7.5	Exclusion mutuelle et variable conditionnelle, plusieurs producteurs, un seul consommateur
10.8	Posix a nommé des sémaphores, un producteur, un consommateur
10.11	Sémaphores Posix en mémoire, un producteur, un consommateur
10.12	Sémaphores Posix en mémoire, plusieurs fabricants, un consommateur
10.15	Sémaphores Posix en mémoire, plusieurs producteurs, plusieurs consommateurs
10.18	Sémaphores Posix en mémoire, un producteur, un consommateur: plusieurs tampons

Tableau 1.7. Versions de programme avec numéro séquentiel croissant

Référencement	La description
9.1	Index dans le fichier, pas de blocage
9.3	Index dans le fichier, verrouillage fcntl
9.9	Index dans le fichier, verrouillage à l'aide de la fonction d'ouverture
10.10	Index dans le fichier, verrouillage avec un sémaphore nommé Posix
12.2	Index dans mmap de mémoire partagée, verrouillage avec un sémaphore nommé Posix
12.3	Index dans mmap de mémoire partagée, verrouillage avec le sémaphore Posix en mémoire
12.4	Indexer dans la mémoire partagée sans nom 4.4BSD, verrouillage avec un sémaphore Posix nommé
12.5	Index en mémoire partagée SVR4 / dev / zero, verrouillage avec un sémaphore nommé Posix
13.6	Index dans la mémoire partagée Posix, verrouiller avec le sémaphore Posix en mémoire
A.19	Mesure des performances: verrouillage d'exclusion mutuelle entre les threads
A.22	Mesure des performances: verrous de lecture / écriture croisés
A.23	Mesure des performances: verrouillage de threads croisés avec les sémaphores en mémoire Posix
A.25	Mesure des performances: verrouillage de filetage croisé avec des sémaphores nommés Posix
A.28	Mesure des performances: verrouillage de filetage croisé avec les sémaphores du système V
A.29	Mesure des performances: blocage entre les threads avec fcntl
A.33	Mesure des performances: verrouillage entre les processus à l'aide d'exclusions mutuelles

Des exercices

1. La figure 1.1 montre deux processus accédant au même fichier. Si les deux processus ajoutent uniquement des données à la fin du fichier (éventuellement long), quel type de synchronisation sera nécessaire?

2. Examinez le fichier d'en-tête sur votre système et découvrez comment errno est défini.

3. Tableau complet. 1.3 fonctions que vous utilisez, prises en charge par les systèmes Unix.

CHAPITRE 2

2.1. introduction

Parmi les types IPC disponibles, les trois suivants peuvent être classés comme Posix IPC, qui est une méthode de communication de processus conforme Posix:

■ Files d'attente de messages Posix (chapitre 5);

■ Sémaphores Posix (chapitre 10);

■ Mémoire partagée Posix (chapitre 13).

Ces trois types d'IPC ont des propriétés communes et des fonctions similaires sont utilisées pour les utiliser. Dans ce chapitre, nous aborderons les exigences générales pour les noms de fichiers complets en tant qu'identificateurs, les indicateurs lors de l'ouverture ou la création d'objets IPC et les autorisations pour y accéder.

Une liste complète des fonctions utilisées pour travailler avec ces types d'IPC est donnée dans le tableau. 2.1.

Tableau 2.1. Fonctionnalités Posix IPC

	Files d'attente de messages	Sémaphores	Mémoire commune
En tête de fichier
Fonctions de création, d'ouverture et de suppression	mq_open mq_close mq_unlink	sem_open sem_close sem_unlink sem_init sem_destroy	shm_open shm_unlink
Opérations de contrôle	mq_getattr mq_setattr		ftruncate fstat
Opérations IPC	mq_send mq_receive mq_notify	sem_wait sem_trywait sem_post sem_getvalue	mmap munmap

2.2. Noms IPC

Table 1.2, nous avons noté que les trois types IPC Posix ont des identifiants (noms) conformes à cette norme. Le nom IPC est passé comme premier argument à l'une des trois fonctions suivantes: mq_open, sem_open et shm_open, et il ne doit pas nécessairement correspondre à un fichier réel sur le système de fichiers. La norme Posix.1 impose les restrictions suivantes sur les noms IPC:

■ Le nom doit être conforme aux exigences existantes pour les noms de fichiers (ne dépassez pas la longueur des octets PATHMAX, y compris le caractère de fin avec le code 0).

■ Si le nom commence par une barre oblique (/), l'appel de l'une de ces fonctions fera référence à la même file d'attente. Sinon, le résultat dépend de l'implémentation.

■ L'interprétation des barres obliques supplémentaires dans un nom dépend de l'implémentation.

Ainsi, pour une meilleure portabilité, les noms doivent commencer par une barre oblique (/) et ne pas contenir de barres obliques supplémentaires. Malheureusement, ces règles entraînent à leur tour des problèmes de portabilité.

Sous Solaris 2.6, une barre oblique principale est requise et aucune barre oblique supplémentaire n'est autorisée. Pour une file d'attente de messages, par exemple, cela crée trois fichiers dans le répertoire / tmp, avec les noms de fichiers commençant par .MQ. Par exemple, si l'argument de la fonction mq_open est /queue.1234, les fichiers générés seront nommés /tmp/.MQDqueue.1234, /tmp/.MQLqueue.1234 et /tmp/.MQPqueue.1234. En même temps, dans Digital Unix 4.0B, un fichier est simplement créé avec le nom spécifié lors de l'appel de la fonction.

Un problème de portabilité survient lors de la spécification d'un nom avec une seule barre oblique au début: dans ce cas, nous devons avoir l'autorisation d'écriture sur le répertoire racine. Par exemple, une file d'attente nommée /tmp.1234 est Posix valide et ne causera pas de problèmes sous Solaris, mais Digital Unix échouera à créer un fichier s'il n'y a pas d'autorisation d'écriture à la racine du programme. Si nous spécifions le nom /tmp/test.1234, des problèmes sur Digital Unix et des systèmes similaires créant un fichier avec nom spécifié, disparaîtra (en supposant que / tmp existe et que le programme dispose des droits d'écriture, ce qui est courant sur la plupart des systèmes Unix), mais ce nom ne sera pas possible sous Solaris.

Pour résoudre ces problèmes de portabilité, vous devez définir le nom dans l'en-tête à l'aide de la directive #define pour faciliter le changement lors du portage de votre programme sur un autre système.

REMARQUE

Les développeurs ont cherché à permettre l'utilisation de files d'attente de messages, de sémaphores et de mémoire partagée pour les noyaux Unix existants et dans les systèmes indépendants sans disque. C'est le cas lorsque la norme devient trop générale et entraîne par conséquent des problèmes de portabilité. Avec Posix, cela s'appelle «comment la norme devient non standard».

Le standard Posix.1 définit trois macros:

qui prennent un seul argument, un pointeur vers une structure de type stat, dont le contenu est défini par les fonctions fstat, lstat et stat. Ces trois macros renvoient une valeur différente de zéro si l'objet IPC spécifié (file d'attente de messages, sémaphore ou segment de mémoire partagée) est implémenté en tant que type spécial de fichier et que la structure statistique fait référence à ce type. Sinon, la macro renvoie 0.

REMARQUE

Malheureusement, ces macros sont peu utiles car il n'y a aucune garantie que ces types IPC soient implémentés en tant que types de fichiers séparés. Par exemple, sous Solaris 2.6, les trois macros renvoient toujours 0.

Toutes les autres macros utilisées pour vérifier le type de fichier ont des noms commençant par S_IS et prennent toujours un seul argument: le champ st_mode de la structure stat. Étant donné que les macros utilisées pour vérifier le type IPC acceptent des arguments d'un type différent, leurs noms commencent par S_TYPEIS.

Fonction Px_ipc_name

Il existe une autre solution au problème de portabilité ci-dessus. Nous pouvons définir notre propre fonction px_ipc_name qui préfixe le répertoire requis au nom IPC Posix.

char * px_ipc_name (const char * Nom);

/ * Renvoie un pointeur en cas de succès, NULL en cas d'erreur * /

REMARQUE

Voici à quoi ressemblent les listes de nos propres fonctions, c'est-à-dire des fonctions qui ne sont pas des fonctions système standard. Habituellement, le fichier d'en-tête unpipc.h est inclus (Listing B.1).

Argument crâne(nom) ne doit pas contenir de barres obliques. Ensuite, par exemple, appeler px_ipc_name ("test1") renverra un pointeur vers / test1 sous Solaris 2.6 ou vers / tmp / test1 sous Digital Unix 4.0B. La mémoire de la chaîne renvoyée est allouée dynamiquement et libérée en appelant free. Vous pouvez définir la variable d'environnement PX_IPC_NAME sur une valeur arbitraire pour définir un répertoire par défaut différent.

Le listing 2.1 montre notre implémentation de cette fonction.

REMARQUE

Cette liste peut être la première fois que vous rencontrez la fonction snprintf. La plupart des programmes existants utilisent sprintf à la place, mais ce dernier ne vérifie pas les débordements de tampon de réception. En revanche, snprintf prend la taille du tampon de réception comme deuxième argument et l'empêche par la suite de déborder. Le débordement de tampon intentionnel d'un programme qui utilise sprintf a été utilisé par les pirates pour compromettre les systèmes pendant des années.

Snprintf ne fait pas encore partie de la norme ANSI C, mais il est prévu d'être inclus dans une norme mise à jour appelée C9X. Cependant, de nombreux fournisseurs l'incluent dans la bibliothèque standard C. Dans tout le texte, nous utilisons snprintf dans notre propre version, qui appelle sprintf si la bibliothèque système n'a pas snprinft.

Liste 2.1. La fonction px_ipc_name dans notre implémentation.

3 px_ipc_name (const char * name)

6 si ((dst \u003d malloc (PATH_MAX)) \u003d\u003d NULL)

8 / * il est possible de définir un nom de répertoire différent en utilisant une variable d'environnement * /

9 if ((dir \u003d getenv ("PX IPC_NAME")) \u003d\u003d NULL) (

11 dir \u003d POSIX_IPC_PREFIX; / * de "config.h" * /

13 dir \u003d "/ tmp /"; /* défaut */

16 / * le nom du répertoire doit se terminer par "/" * /

17 barre oblique \u003d (dir \u003d\u003d "/")? "": "/";

18 snprintf (dst, PATH_MAX, "% s% s% s", répertoire, barre oblique, nom);

19 retour (dst); / * vous pouvez appeler free () pour libérer ce pointeur * /

2.3. Créer et ouvrir des canaux IPC

Les trois fonctions utilisées pour créer ou ouvrir des objets IPC, mq_open, sem_open et shm_open, prennent un indicateur spécial oflag comme deuxième argument. Il définit les paramètres d'ouverture de l'objet demandé de la même manière que le deuxième argument de la fonction open standard. Toutes les constantes à partir desquelles cet argument peut être formé sont affichées dans le tableau. 2.2.

Tableau 2.2. Constantes utilisées lors de la création et de l'ouverture d'objets IPC

La description	mq_open	sem_open	shm_open
Seulement lecture	О_RDONLY		О_RDONLY
Enregistrer seulement	О_WRONLY
Lire et écrire	O_RDWR		O_RDWR
Créer si n'existe pas	О_CREAT	О_CREAT	О_CREAT
Création exclusive	О_EXCL	О_EXCL	О_EXCL
Pas de blocage	О_NONBLOCK
Tronquer un existant			O_TRUNC

Les trois premières lignes décrivent le type d'accès à l'objet créé: lecture seule, écriture seule, lecture et écriture. La file d'attente de messages peut être ouverte dans l'un des trois modes d'accès, tandis que le sémaphore ne nécessite pas ces constantes (un accès en lecture / écriture est requis pour toute opération de sémaphore). Enfin, un objet de mémoire partagée ne peut pas être ouvert uniquement pour l'écriture.

Indication des autres drapeaux du tableau. 2.2 est facultatif.

O_CREAT - Crée une file d'attente de messages, un sémaphore ou un segment de mémoire partagée, s'il n'en existe pas déjà (voir aussi l'indicateur O_EXCL, qui affecte le résultat).

Lors de la création d'une nouvelle file d'attente de messages, d'un sémaphore ou d'un segment de mémoire partagée, au moins un argument supplémentaire spécifiant le mode est requis. Cet argument spécifie les bits d'autorisation d'accès au fichier et est formé par l'addition logique au niveau du bit des constantes de la table. 2.3.

Tableau 2.3. Constantes de mode d'accès lors de la création d'un nouvel objet IPC

Ces constantes sont définies dans l'en-tête ... Les bits d'autorisation spécifiés sont modifiés en appliquant le masque de mode de création de fichier pour ce processus (p. 83-85) ou en utilisant la commande d'interpréteur umask.

Comme pour un fichier nouvellement créé, lorsqu'une file d'attente de messages, un sémaphore ou un segment de mémoire partagée est créé, un ID utilisateur correspondant à l'ID utilisateur effectif du processus lui est attribué. Le groupe de sémaphores ou l'identificateur de segment de mémoire partagée est défini sur l'identificateur de groupe de processus effectif ou l'identificateur de groupe par défaut pour l'ensemble du système. L'ID de groupe de file d'attente de messages est toujours défini sur l'ID de groupe de processus réel (voir pages 77-78 pour plus d'informations sur les ID de groupe et d'utilisateur).

REMARQUE

Il semble étrange qu'il y ait une différence dans le réglage de l'ID de groupe pour différentes vues IPC Posix. L'ID de groupe du nouveau fichier créé par la fonction d'ouverture est défini sur l'ID de groupe de processus réel ou sur l'ID de groupe du répertoire dans lequel le fichier est créé, mais les fonctions IPC ne peuvent pas supposer à l'avance qu'un fichier réel est créé pour l'objet IPC sur le système de fichiers.

O_EXCL - si cet indicateur est spécifié simultanément avec O_CREAT, la fonction crée une nouvelle file d'attente de messages, un sémaphore ou un objet de mémoire partagée uniquement s'il n'en existe pas. Si l'objet existe déjà et que O_CREAT | O_EXCL, EEXIST est renvoyé.

La vérification de l'existence d'une file d'attente de messages, d'un sémaphore ou d'un segment de mémoire partagée et sa création (sinon) ne doivent être effectuées que par un seul processus. Il existe deux indicateurs similaires dans System V IPC, ils sont décrits dans la section 3.4.

O_NONBLOCK - Cet indicateur crée une file d'attente de messages sans blocage. Un verrou est généralement défini pour lire à partir d'une file d'attente vide ou écrire dans une file d'attente pleine. Ceci est discuté plus en détail dans les sous-sections sur les fonctions mq_send et mq_receive de la section 5.4.

O_TRUNC - si un segment de mémoire partagée existant est ouvert pour la lecture et l'écriture, cet indicateur indique la nécessité de réduire sa taille à 0.

En figue. 2.1 montre la séquence réelle des opérations logiques lors de l'ouverture d'un objet IPC. Vous apprendrez exactement ce que signifie la vérification des autorisations d'accès dans la section 2.4. Une autre approche de celle illustrée à la Fig. 2.1 est présenté dans le tableau. 2.4.

Figure: 2.1. Logique d'ouverture d'objet IPC

Notez que dans la rangée du milieu du tableau. 2.4, où seul l'indicateur O_CREAT est défini, nous ne recevons aucune information indiquant si un nouvel objet a été créé ou si un objet existant a été ouvert.

Tableau 2.4. Logique d'ouverture d'objet IPC

L'argument oflag	L'objet n'existe pas	L'objet existe déjà
Pas de drapeaux spéciaux	Erreur, errno \u003d ENOENT
O_CREAT	OK, un nouvel objet est créé	OK, un objet existant est ouvert
O_CREAT | O_EXCL	OK, un nouvel objet est créé	Erreur, errno \u003d EEXIST

2.4. Autorisations IPC

Une nouvelle file d'attente de messages, nommée sémaphore ou segment de mémoire partagée est créée par les fonctions mq_open, sem_open et shm_open, à condition que l'argument oflag contient la constante O_CREAT. Selon le tableau. 2.3, chacun de ces types IPC se voit attribuer certaines autorisations, similaires aux autorisations de fichiers sous Unix.

Lors de l'ouverture d'une file de messages, d'un sémaphore ou d'un segment de mémoire partagée existant avec les mêmes fonctions (dans le cas où l'indicateur O_CREAT n'est pas spécifié ou O_CREAT est spécifié sans O_EXCL et que l'objet existe déjà), le contrôle des autorisations est effectué:

1. Les bits d'autorisation affectés à l'objet IPC lors de la création sont vérifiés.

2. Le type d'accès demandé est vérifié (O_RDONLY, O_WRONLY, O_RDWR).

3. L'ID utilisateur valide du processus appelant, l'ID de processus de groupe valide et les ID de groupe de processus supplémentaires (ces derniers peuvent ne pas être pris en charge) sont vérifiés.

La plupart des systèmes Unix effectuent les vérifications spécifiques suivantes:

1. Si l'ID utilisateur valide pour le processus est 0 (utilisateur root), l'accès sera autorisé.

2. Si l'ID utilisateur valide du processus correspond à l'ID propriétaire de l'objet IPC: si le bit d'autorisation correspondant pour l'utilisateur est défini, l'accès est autorisé, sinon l'accès est refusé.

Par le bit d'autorisation approprié, nous entendons, par exemple, le bit d'autorisation de lecture si le processus ouvre l'objet en lecture seule. Si un processus ouvre un objet pour l'écriture, le bit d'autorisation d'écriture du propriétaire (écriture utilisateur) doit être défini en conséquence.

3. Si l'ID de groupe de processus effectif ou l'un des ID de groupe de processus supplémentaires correspond à l'ID de groupe de l'objet IPC: si le bit d'autorisation correspondant pour le groupe est défini, l'accès sera autorisé, sinon l'accès est refusé.

4. Si le bit d'autorisation correspondant pour les autres utilisateurs est défini, l'accès sera autorisé, sinon l'accès sera refusé.

Ces quatre contrôles sont effectués dans l'ordre indiqué. Par conséquent, si le processus possède l'objet IPC (étape 2), l'accès est autorisé ou refusé en fonction des autorisations de l'utilisateur (propriétaire) uniquement. Les autorisations de groupe ne sont pas vérifiées. De même, si le processus n'est pas le propriétaire de l'objet IPC, mais appartient au groupe approprié, l'accès est autorisé ou refusé en fonction des autorisations du groupe - les autorisations des autres utilisateurs ne sont pas vérifiées.

REMARQUE

Selon le tableau. 2.2, la fonction sem_open n'utilise pas les indicateurs O_RDONLY, O_WRONLY, O_RDWR. La section 10.2, cependant, vous dira que certaines implémentations Unix impliquent l'indicateur O_RDWR, car tout appel à un sémaphore implique la lecture et l'écriture de sa valeur.

2.5. Résumé

Les trois types IPC Posix - files d'attente de messages, sémaphores et mémoire partagée - sont identifiés par leurs noms complets. Il peut s'agir ou non des vrais noms de fichiers dans le système de fichiers, ce qui pose des problèmes de portabilité. La solution au problème consiste à utiliser votre propre fonction px_ipc_name. Lors de la création ou de l'ouverture d'un objet IPC, vous devez spécifier un ensemble d'indicateurs similaires à ceux spécifiés lors de l'utilisation de la fonction open. Lors de la création d'un nouvel objet IPC, vous devez spécifier les autorisations pour celui-ci en utilisant les mêmes constantes S_xxx que pour la fonction open (Tableau 2.3). Lors de l'ouverture d'un objet IPC existant, une vérification des autorisations de processus est effectuée, similaire à la vérification lors de l'ouverture d'un fichier.

Des exercices

1. Comment les bits set-user-ID (SUID) et set-group-ID (section 4.4) d'un programme utilisant le Posix IPC affectent-ils la vérification des permissions décrite dans la section 2.4?

2. Lorsqu'un programme ouvre un objet IPC, comment peut-il savoir si un nouvel objet IPC a été créé ou s'il accède à un objet existant?

CHAPITRE 3

3.1. introduction

Parmi les types d'IPC disponibles, les trois suivants peuvent être classés comme IPC System V, c'est-à-dire des méthodes d'interaction entre processus conformes à la norme System V:

■ Files d'attente de messages System V (chapitre 6).

■ Sémaphores System V (chapitre 11);

■ Mémoire partagée System V (chapitre 14).

Le terme «System V IPC» fait référence à l'origine de ces outils: ils sont apparus pour la première fois dans Unix System V. Ils ont beaucoup en commun: ils ont des fonctions similaires par lesquelles l'accès aux objets est organisé; les formes de stockage des informations dans le noyau sont également similaires. Ce chapitre décrit les fonctionnalités communes aux trois types d'IPC.

Les informations sur les fonctions sont résumées dans le tableau. 3.1.

Tableau 3.1. Fonctions IPC du système V

REMARQUE

Les informations sur l'historique et le développement des fonctionnalités IPC de System V ne sont pas facilement disponibles. fournit les informations suivantes: les files de messages, les sémaphores et la mémoire partagée de ce type ont été développés à la fin des années 70 dans une succursale de Bell Laboratories à Columbus, Ohio, pour une version d'Unix destinée à un usage interne. Cette version s'appelait Columbus Unix ou CB Unix. Il était utilisé dans les systèmes dits de soutien aux opérations - les systèmes de traitement des transactions - pour automatiser la gestion et la tenue des registres de la compagnie de téléphone. Les IPC System V ont été ajoutés à la version commerciale d'Unix System V. vers 1983.

3.2. Clés de type key_t et fonction ftok

Table 1.2, il a été noté que les noms des trois types d'IPC System V utilisaient des valeurs key_t. En tête de fichier définit le type de key_t comme étant un entier (au moins 32 bits). Les variables de ce type sont généralement affectées à la fonction ftok.

La fonction ftok convertit le nom complet et l'identifiant entier existants en une valeur de type key_t (appelée clé IPC):

key_t ftok (caractère const * chemin, int id);

// Renvoie la clé IPC ou -1 en cas d'erreur

En fait, la fonction utilise le nom de fichier complet et les 8 bits inférieurs de l'identificateur pour former une clé IPC entière.

Cette fonctionnalité suppose que pour une application particulière utilisant IPC, le client et le serveur utilisent le même nom d'objet IPC complet qui a une certaine signification dans le contexte de l'application. Cela peut être le nom du démon du serveur, ou le nom du fichier de données utilisé par le serveur, ou le nom d'un autre objet du système de fichiers. Si le client et le serveur n'ont besoin que d'un seul canal IPC pour communiquer, l'identifiant peut être attribué, par exemple, la valeur 1. Si plusieurs canaux IPC sont nécessaires (par exemple, un de serveur à client et un dans le sens opposé), les identificateurs doivent avoir des valeurs différentes: par exemple, 1 et 2. Une fois que le client et le serveur se sont mis d'accord sur un nom et un identifiant pleinement qualifiés, ils appellent tous deux ftok pour obtenir la même clé IPC.

La plupart des implémentations de ftok appellent stat puis concaténent:

■ informations sur le système de fichiers auquel appartient le nom complet chemin (champ st_dev de la structure statistique);

■ numéro de nœud (i-node) dans le système de fichiers (champ st_ino de la structure stat);

■ les 8 bits les moins significatifs de l'identifiant (qui ne doivent pas être zéro).

La combinaison de ces trois valeurs se traduit généralement par une clé de 32 bits. Il n'y a aucune garantie que deux chemins différents avec le même identifiant donneront des clés différentes, car le nombre de bits d'information dans les trois éléments répertoriés (ID du système de fichiers, numéro de nœud, ID IPC) peut dépasser le nombre total de bits (voir Exercice 3.5. ).

REMARQUE

Le numéro de nœud est toujours différent de zéro, donc la plupart des implémentations définissent la constante IPC_PRIVATE (section 3.4) comme étant zéro.

Si le nom complet spécifié n'existe pas ou n'est pas disponible pour le processus appelant, ftok renvoie –1. Rappelez-vous que le fichier dont le nom est utilisé pour calculer la clé ne doit pas être l'un de ceux qui sont créés et supprimés par le serveur dans le processus, car à chaque fois qu'ils sont recréés, ces fichiers reçoivent, en général, un numéro de nœud différent, ce qui peut changer la clé renvoyé par ftok lors du prochain appel.

Exemple

Le programme du Listing 3-1 prend le nom complet comme argument de ligne de commande, appelle stat et ftok, puis imprime les champs st_dev et st_ino de stat et la clé IPC résultante. Ces trois valeurs sont affichées en hexadécimal, il est donc facile de voir exactement comment la clé IPC est formée à partir de ces deux valeurs et de l'ID 0x57.

Liste 3.1. Récupération et affichage des informations sur un fichier et la clé IPC générée

7 err_quit ("utilisation: ftok ");

9 printf ("st_dev: & lx, st_ino:% Ix, clé:% x \\ n",

10 (u_long) stat.st_dev, (u_long) stat.st_ino,

L'exécution de ce programme sur un système Solaris 2.6 produira les résultats suivants:

solaris% ftok / etc / système

st_dev: 800018, st_ino: 4a1b, clé: 57018a1b

solaris% ftok / usr / tmp

st_dev: 800015, st_ino: 10b78, clé: 57015b78

solaris% ftok /home/rstevens/Mail.out

st_dev: 80001f, st_ino: 3b03, clé: 5702fb03

Evidemment, l'identifiant définit les 8 bits supérieurs de la clé; les 12 bits les moins significatifs de st_dev définissent les 12 bits suivants de la clé, et enfin les 12 bits les moins significatifs de st_ino définissent les 12 bits les moins significatifs de la clé.

Le but de cet exemple n'est pas de s'appuyer ultérieurement sur cette méthode de génération d'une clé à partir des informations répertoriées, mais d'illustrer l'algorithme de combinaison du nom complet et de l'identifiant avec une implémentation spécifique. Dans d'autres implémentations, l'algorithme peut être différent.

REMARQUE

FreeBSD utilise les 8 bits inférieurs de l'identifiant, les 8 bits inférieurs de st_dev et les 16 bits inférieurs de st_ino.

Notez que le mappage produit par ftok est unidirectionnel car certains des bits st_dev et st_ino ne sont pas utilisés. Par cette clé le nom de fichier complet donné pour le calcul ne peut pas être déterminé.

3.3. Structure Ipc_perm

Pour chaque objet IPC, comme pour un fichier normal, le noyau stocke un ensemble d'informations combinées dans une structure.

uid_t uid; / * ID utilisateur propriétaire * /

gid_t gid; / * identifiant du groupe du propriétaire * /

uid_t cuid; / * ID utilisateur du créateur * /

gid_t cgid; / * identifiant du groupe de créateurs * /

mode_t mode; / * autorisations de lecture-écriture * /

ulong_t seq; / * numéro de canal séquentiel * /

clé key_t; / * Clé IPC * /

Cette structure, ainsi que d'autres constantes renommées pour les fonctions IPC System V, est définie dans le fichier ... Dans ce chapitre, nous aborderons plus en détail les champs de la structure ipc_perm.

3.4. Créer et ouvrir des canaux IPC

Les trois fonctions getXXX utilisées pour créer ou ouvrir des objets IPC (Tableau 3.1) prennent une clé IPC (de type key_t) comme l'un des arguments et renvoient un identifiant entier. Cet identifiant est différent de celui passé à ftok, comme nous le verrons bientôt. L'application dispose de deux options pour définir la clé (le premier argument des fonctions getXXX):

1. Appelez ftok, transmettez-lui un nom et un identifiant complets.

2. Spécifiez la constante IPCPRIVATE comme clé, ce qui garantit la création d'un nouvel objet IPC unique.

La séquence d'actions est illustrée à la Fig. 3.1.

Figure: 3.1. Calcul des ID IPC par clés

Les trois fonctions getXXX (tableau 3.1) prennent un ensemble d'indicateurs comme deuxième argument oflag, qui définit les bits des autorisations de lecture-écriture (le champ mode de la structure ipc_perm) pour l'objet IPC et détermine si un nouvel objet IPC est créé ou si un objet existant est accédé. Il existe les règles suivantes pour cela.

S La clé IPC_PRIVATE garantit la création d'un objet IPC unique. Aucune combinaison de nom complet et d'identifiant ne peut amener ftok à renvoyer IPC_PRIVATE comme clé.

■ Définition du bit IPC_CREAT de l'argument oflag entraîne une nouvelle entrée pour la clé spécifiée, si elle n'existe pas déjà. Si une entrée existante est trouvée, son identifiant est renvoyé.

Définition simultanée des bits d'argument IPC_CREAT et IPC_EXCL oflagentraîne une nouvelle entrée pour la clé spécifiée uniquement si une telle entrée n'existe pas déjà. Si une entrée existante est trouvée, la fonction renvoie une erreur EEXIST (l'objet IPC existe déjà).

La combinaison de IPC_CREAT et IPC_EXCL pour les objets IPC agit comme la combinaison de O_CREAT et O_EXCL pour la fonction ouverte.

La définition du bit IPC_EXCL uniquement sans IPC_CREAT n'a aucun effet.

Le diagramme de séquence logique pour ouvrir un objet IPC est illustré à la Fig. 3.2. Table 3.2 montre une autre vue de ce processus.

Figure: 3.2. Diagramme d'ouverture d'objet IPC

Notez que dans la rangée du milieu du tableau. 3.2 pour l'indicateur IPC_CREAT sans IPC_EXCL, nous n'obtenons aucune information sur la création d'un nouvel objet ou l'accès à un objet existant. Pour la plupart des applications, il est courant que le serveur crée un objet IPC avec l'indication IPC_CREAT (si cela n'a pas d'importance si l'objet existe déjà) ou IPC_CREAT | IPC_EXCL (si un contrôle d'existence d'objet est requis). Le client ne spécifie pas du tout les indicateurs, en supposant que le serveur a déjà créé l'objet.

REMARQUE

Les fonctions IPC System V, contrairement aux fonctions IPC Posix, définissent leurs propres constantes IPC_xxx au lieu d'utiliser O_CREAT et OEXCL comme fonction standard ouvert (Tableau 2.2).

Notez également que les fonctions IPC System V combinent les constantes IPC_xxx avec les bits d'autorisation (décrits dans la section suivante) dans un seul argument oflag, tandis que la fonction open et Posix IPC ont deux arguments: oflag, qui spécifie des indicateurs de la forme O_xxx et mode, qui spécifie les bits d'autorisation d'accès.

Tableau 3.2. Logique de création et d'ouverture d'objets IPC

L'argument oflag	La clé n'existe pas	La clé existe
Aucun jeu de drapeaux spéciaux	Erreur, errno \u003d ENOENT	OK, ouverture d'un objet existant
IPC_CREAT	OK, une nouvelle entrée est en cours de création	OK, ouvrir un existant
IPC CREAT | IPC_EXCL	OK, une nouvelle entrée est en cours de création	Erreur, errno \u003d EEXIST

3.5. Autorisations IPC

Lors de la création d'un nouvel objet IPC à l'aide de l'une des fonctions getXXX appelées avec l'indicateur IPC_CREAT, les informations suivantes sont entrées dans la structure ipc_perm (section 3.3):

1. Une partie des bits de l'argument oflag définissez la valeur du champ mode de la structure ipc_perm. Table 3.3 montre les bits de permission pour les trois types d'IPC (écrire \u003e\u003e 3 signifie décaler vers la droite de trois bits).

2. Les champs cuid et cgid sont définis sur l'ID d'utilisateur et de groupe valide du processus appelant. Ces deux champs sont appelés ID de créateur.

3. Les champs uid et gid de la structure ipc_perm sont également définis égaux aux identificateurs valides du processus appelant. Ces deux champs sont appelés ID de propriétaire.

Tableau 3.3. Valeurs de mode pour les autorisations de lecture-écriture IPC

Nombre (octal)	File d'attente des messages	Sémaphore	La memoire partagée	La description
0400	MSG_R	SEM_R	SHM_R	Utilisateur - Lire
0200	MSG_W	SEM_A	SHM_W	Utilisateur - enregistrement
0040	MSG R \u003e\u003e 3	SEM_R \u003e\u003e 3	SHM_R \u003e\u003e 3	Groupe - lecture
0020	MSG_W \u003e\u003e 3	SEM_A \u003e\u003e 3	SHM_W \u003e\u003e 3	Groupe - enregistrement
0004	MSG_R \u003e\u003e 6	SEM_R \u003e\u003e 6	SHM_R \u003e\u003e 6	Autres - lecture
0002	MSG_W \u003e\u003e 6	SEM_A \u003e\u003e 6	SHM_W \u003e\u003e 6	Autres - enregistrement

L'ID de créateur ne peut pas être modifié, tandis que l'ID de propriétaire peut être modifié par un processus en appelant la fonction ctlXXX sur un mécanisme IPC donné avec la commande IPC_SET. Les trois fonctions ctlXXX permettent à un processus de modifier les bits d'autorisation d'accès (champ mode) de l'objet IPC.

REMARQUE

La plupart des implémentations définissent six constantes: MSG_R, MSG_W, SEM_R, SEM_A, SHM_R et SHM_W, illustrées dans le tableau 1. 3.3. Ces constantes sont définies dans les fichiers d'en-tête , et ... Cependant, le standard Unix 98 ne les requiert pas. Le suffixe A dans SEM_A signifie "alter" (changement).

Les trois fonctions getXXX n'utilisent pas le masque de création de fichier Unix standard. Les autorisations de la file d'attente de messages, du sémaphore et de la mémoire partagée sont exactement égales à l'argument de la fonction.

Posix IPC ne donne pas au créateur IPC la possibilité de changer le propriétaire d'un objet. Le Posix n'a pas d'équivalent à la commande IPC_SET. Cependant, dans Posix IPC, le nom d'un objet appartient au système de fichiers et, par conséquent, le propriétaire peut être modifié par un utilisateur root à l'aide de la commande chown.

À chaque fois qu'un processus tente d'accéder à un objet IPC, une vérification en deux étapes est effectuée: la première fois que le fichier est ouvert (fonction getXXX) puis à chaque fois que l'on accède à l'objet IPC:

1. Lors de la définition de l'accès à un objet IPC existant à l'aide de l'une des fonctions getXXX, l'argument initial est vérifié oflag, le processus appelant la fonction. L'argument ne doit pas indiquer de bits d'accès non définis dans le champ mode de la structure ipc_perm (carré du bas sur la figure 3.2). Par exemple, un processus serveur peut définir le membre de mode sur sa file d'attente entrante en effaçant les bits de lecture pour le groupe et les autres utilisateurs. Tout processus tentant de spécifier ces bits dans un argument oflag function msgget obtiendra une erreur. Il est à noter que ce contrôle effectué par les fonctions getXXX est peu utile. Cela implique que le processus appelant dispose d'informations sur le groupe d'utilisateurs auquel il appartient: il peut être le propriétaire du fichier, il peut appartenir au même groupe ou à d'autres utilisateurs. Si le processus de création efface certains des bits d'autorisation et que le processus appelant tente de les définir, getXXX renverra une erreur. Tout processus peut ignorer complètement cette vérification en spécifiant l'argument oflag, égal à 0 si l'existence de l'objet IPC est connue à l'avance.

2. Toute opération avec des objets IPC vérifie les autorisations pour le processus demandeur. Par exemple, chaque fois qu'un processus tente de mettre un message en file d'attente à l'aide de la commande msgsnd, les vérifications suivantes sont effectuées (les étapes suivantes sont ignorées lors de l'accès).

□ L'utilisateur privilégié a toujours accès.

□ Si l'ID utilisateur valide correspond à l'uid ou au cuid de l'objet IPC et que le bit d'autorisation d'accès correspondant est défini dans le champ mode de l'objet IPC, l'accès sera accordé. Un bit d'autorisation d'accès approprié signifie un bit qui autorise la lecture si le processus appelant demande une opération de lecture sur cet objet IPC (par exemple, recevoir un message d'une file d'attente), ou un bit qui permet l'écriture si le processus veut l'exécuter.

□ Si l'ID de groupe valide correspond au gid ou au cgid de l'IPC et que le bit d'autorisation d'accès correspondant est défini dans le champ de mode de l'IPC, l'accès sera accordé.

□ Si l'accès n'a pas été autorisé lors des étapes précédentes, les bits d'accès correspondants sont vérifiés pour les autres utilisateurs.

3.6. Réutiliser les identifiants

La structure ipc_perm (section 3.3) contient la variable seq, qui stocke le numéro de séquence du canal. Cette variable est un compteur de noyau pour chaque objet IPC sur le système. Lorsque l'objet IPC est supprimé, le numéro de canal est augmenté et en cas de dépassement, il est remis à zéro.

REMARQUE

Dans cette section, nous décrivons une implémentation spécifique de SVR4. Le standard Unix 98 n'empêche pas l'utilisation d'autres options.

Un compteur est nécessaire pour deux raisons. Tout d'abord, souvenez-vous des descripteurs de fichiers stockés dans le noyau pour chacun des fichiers ouverts. Ce sont généralement de petits entiers qui n'ont de sens que dans un seul processus - chaque processus a ses propres descripteurs. Vous ne pouvez lire à partir d'un fichier avec le descripteur 4 que dans le processus qui a un fichier ouvert avec un tel descripteur. La question de savoir s'il existe des fichiers ouverts avec le même descripteur dans d'autres processus n'a aucune importance. Contrairement aux descripteurs de fichiers, les identificateurs IPC System V sont définis à l'échelle du système et non au niveau du processus.

L'identifiant IPC est renvoyé par l'une des fonctions getXXX: msgget, semget, shmget. Comme les descripteurs de fichiers, les identificateurs sont des entiers, qui, contrairement aux descripteurs, ont la même signification pour tous les processus. Si deux processus indépendants (client et serveur) utilisent la même file d'attente de messages, l'identificateur renvoyé par msgget doit avoir la même valeur entière dans les deux processus pour qu'ils puissent accéder à la même file d'attente. Cette fonctionnalité permet à un processus créé par un attaquant d'essayer de lire un message à partir d'une file d'attente créée par une autre application, en effectuant une itération séquentielle sur divers identificateurs (s'il s'agissait de petits entiers) et en espérant l'existence d'une file d'attente actuellement ouverte disponible pour la lecture à tous ... Si les ID étaient de petits entiers (comme les descripteurs de fichier), la probabilité de trouver l'ID correct serait d'environ 1/50 (en supposant une limite de 50 descripteurs par processus).

Pour éliminer cette possibilité, les développeurs des outils IPC ont décidé d'élargir la gamme possible de valeurs d'identifiant pour inclure tous les entiers en général, et pas seulement les petits. L'extension de plage est obtenue en augmentant la valeur de l'identifiant renvoyé au processus appelant par le nombre d'entrées dans la table système IPC chaque fois que l'une d'elles est réutilisée. Par exemple, si le système est configuré pour n'utiliser pas plus de 50 files d'attente de messages, la première fois que la première entrée est utilisée, le processus renverra l'ID 0. Après avoir supprimé cette file d'attente de messages, lorsque vous essayez de réutiliser le premier enregistrement de la table, le processus renverra l'ID 50. Ensuite, il prendra les valeurs 100, 150, et ainsi de suite. Comme seq est généralement défini comme un entier long non signé (ulong - voir la structure ipc_perm à la section 3.3), il revient aux identifiants déjà utilisés lorsque l'entrée de table est utilisée 85899346 fois (2³² / 50 en supposant que entier est de 32 bits).

La deuxième raison de saisir le numéro séquentiel du canal est d'éviter de réutiliser les identifiants IPC System V après un court laps de temps. Cela permet de garantir qu'un serveur arrêté prématurément puis redémarré n'utilise pas le même identifiant.

Pour illustrer cela, le programme du Listing 3.2 imprime les dix premières valeurs d'identifiant renvoyées par msgget.

Liste 3.2. Afficher l'ID de la file d'attente de messages dix fois de suite

7 msqid \u003d Msgget (IPC_PRIVATE, SVMSG_MODE | IPC_CREAT);

8 printf ("msqid \u003d% d \\ n", msqid);

9 Msgctl (msqid, IPC_RMID, NULL);

Sur la boucle suivante, msgget crée la file d'attente de messages et msgctl avec la commande IPC_RMID comme argument la supprime. La constante SVMSG_MODE est définie dans notre fichier d'en-tête unpipc.h (Listing B.1) et définit les autorisations par défaut pour la file d'attente de messages System V. La sortie ressemblera à ceci:

Lorsque le programme est redémarré, nous verrons une illustration claire du fait que le numéro séquentiel du canal est une variable stockée dans le noyau et continue d'exister même après la fin du processus.

3.7. Ipcs et ipcrm

Étant donné que les objets IPC System V ne sont pas mappés aux noms du système de fichiers, nous ne pouvons pas les lister ni les supprimer à l'aide de programmes standard ls et rm. Au lieu de cela, les systèmes qui prennent en charge ces types IPC fournissent deux programmes spéciaux: ipcs, qui affiche diverses informations sur les propriétés IPC System V, et ipcrm, qui supprime la file d'attente de messages System V, le sémaphore ou le segment de mémoire partagée. La première de ces fonctions prend en charge une douzaine de paramètres de ligne de commande qui contrôlent l'affichage des informations sur différents types d'IPC. Le second (ipcrm) peut définir jusqu'à six paramètres. Des informations détaillées à leur sujet peuvent être obtenues dans le système d'aide.

REMARQUE

Le System V IPC n'étant pas normalisé par Posix, ces commandes ne font pas partie de Posix.2. Ils sont décrits dans la norme Unix 98.

3.8. Limitations du noyau

La plupart des implémentations IPC de System V ont des contraintes de noyau internes. Il s'agit, par exemple, du nombre maximum de files d'attente de messages ou de la limite du nombre maximum de sémaphores dans un ensemble. Les valeurs typiques de ces restrictions sont données dans le tableau. 6.2, 11.1 et 14.1. La plupart des restrictions sont héritées de l'implémentation System V d'origine.

REMARQUE

La section 11.2 du livre et le chapitre 8 décrivent l'implémentation des files de messages, des sémaphores et de la mémoire partagée dans System V. Certaines de ces restrictions y sont déjà décrites.

Malheureusement, certaines des contraintes imposées sont assez strictes, car elles sont héritées de l'implémentation d'origine basée sur un système avec un petit espace d'adressage (PDP-11 16 bits). Heureusement, la plupart des systèmes permettent à un administrateur de modifier certaines des limites par défaut, mais les étapes requises sont spécifiques à chaque version d'Unix. Dans la plupart des cas, un redémarrage du noyau est nécessaire après avoir effectué des modifications. Malheureusement, certaines implémentations utilisent encore des entiers 16 bits pour stocker certains paramètres, ce qui définit déjà les limites matérielles.

Sur Solaris 2.6, par exemple, il existe 20. Leurs valeurs actuelles peuvent être affichées à l'aide de la commande sysdef. Notez que les zéros seront imprimés à la place des valeurs réelles si le module du noyau correspondant n'est pas chargé (c'est-à-dire que l'outil n'a pas été utilisé précédemment). Cela peut être éliminé en ajoutant l'une des instructions suivantes au fichier / etc / system. Le fichier / etc / system est lu lors du redémarrage du système:

set msgsys: msginfo_msgseg \u003d valeur

set msgsys: msginfo_msgssz \u003d valeur

set msgsys: msginfo_msgtql \u003d valeur

set msgsys: msginfo_msgmap \u003d valeur

set msgsys: msginfo_msgmax \u003d valeur

set msgsys: msginfo_msgmnb \u003d valeur

set msgsys: msginfo_msgmni \u003d valeur

set semsys: séminfo_semopm \u003d valeur

set semsys: séminfo_semume \u003d valeur

set semsys: séminfo_semaem \u003d valeur

set semsys: séminfo_semmap \u003d valeur

set semsys: séminfo_semvmx \u003d valeur

set semsys: séminfo_semmsl \u003d valeur

set semsys: séminfo_semmni \u003d valeur

set semsys: séminfo_semmns \u003d valeur

set semsys: séminfo_semmnu \u003d valeur

définir shmsys: shminfo_shmmin \u003d valeur

définir shmsys: shminfo_shmseg \u003d valeur

définir shmsys: shminfo_shmmax \u003d valeur

définir shmsys: shminfo_shmmni \u003d valeur

Les six derniers caractères du nom à gauche du signe égal représentent les variables répertoriées dans le tableau 1. 6.2, 11.1 et 14.1.

Dans Digital Unix 4.0B, le programme sysconfig vous permet de vérifier ou de modifier de nombreux paramètres et restrictions du noyau. Voici la sortie de cette commande exécutée avec l'option –q. La commande affiche les limites actuelles du sous-système ipc. Certaines lignes de la sortie non liées aux fonctionnalités IPC System V ont été omises:

alpha% / sbin / sysconfig –q ipc

Vous pouvez spécifier différentes valeurs par défaut pour ces paramètres en modifiant le fichier / etc / sysconfigtab. Cela devrait être fait en utilisant le programme sysconfigdb. Ce fichier est également lu lors du démarrage du système.

3.9. Résumé

Le premier argument de msgget, semget et shmget est la clé IPC System V. Ces clés sont calculées à partir du nom de fichier complet à l'aide de la fonction système ftok. Vous pouvez également spécifier IPCPRIVATE comme clé. Ces trois fonctions créent un nouvel objet IPC ou en ouvrent un existant et renvoient un identificateur IPC System V, un entier qui est ensuite utilisé pour reconnaître l'objet dans d'autres fonctions IPC. Ces identifiants ont un sens non seulement dans un seul processus (comme les descripteurs de fichiers), mais également dans l'ensemble du système. Ils peuvent être réutilisés par le noyau, mais seulement après un certain temps.

Chaque objet IPC System V a une structure ipc_perm associée qui contient des informations à son sujet, telles que l'ID utilisateur du propriétaire, l'ID de groupe, les autorisations de lecture / écriture, etc. L'une des différences entre System V et Posix IPC est que pour un objet System V IPC, cela les informations sont toujours disponibles (elles sont accessibles à l'aide de l'une des fonctions XXXctl avec l'argument IPC_STAT), et dans Posix IPC, leur accès dépend de l'implémentation. Si l'objet Posix IPC est stocké sur le système de fichiers et que nous y connaissons son nom, nous pouvons accéder à ces informations à l'aide des outils du système de fichiers standard.

Lors de la création d'un nouvel objet ou de l'ouverture d'un objet IPC System V existant, la fonction getXXX reçoit deux indicateurs (IPC_CREAT et IPC_EXCL) et 9 bits d'autorisations.

Sans aucun doute, le plus gros problème dans l'utilisation de System V IPC est les limitations artificielles de la plupart des implémentations. Des contraintes sont imposées sur la taille des objets, et elles proviennent des toutes premières implémentations. Cela signifie qu'une utilisation intensive de System V IPC par les applications nécessite des modifications des limites du noyau, et ces modifications sont apportées différemment sur chaque système.

Des exercices

1. Lisez à propos de la fonction msgctl dans la section 6.5 et modifiez le programme du Listing 3.2 pour afficher non seulement l'identifiant, mais aussi le champ seq de la structure ipc_perm.

2. Immédiatement après avoir exécuté le programme du Listing 3.2, nous exécutons le programme qui crée deux files d'attente de messages. En supposant qu'aucune autre application n'a utilisé de files d'attente de messages depuis le démarrage du système, déterminez les valeurs renvoyées par msgget en tant qu'identificateurs de file d'attente de messages.

3. Il a été noté dans la section 3.5 que les fonctions getXXX de System V IPC n'utilisent pas le masque de création de fichier. Écrivez un programme de test qui crée un tube FIFO (en utilisant la fonction mkfifo décrite dans la section 4.6) et une file d'attente de messages System V, en spécifiant à la fois une résolution de 666 (octal). Comparez les autorisations pour les objets générés (FIFO et files d'attente de messages). Assurez-vous que le umask est différent de zéro avant d'exécuter le programme.

4. Le serveur doit créer une file d'attente de messages unique pour ses clients. Est-il préférable d'utiliser un nom de fichier constant (par exemple, le nom du serveur) comme argument de la fonction ftok, ou d'utiliser la clé IPC_PRIVATE?

5. Modifiez le Listing 3.1 pour afficher uniquement la clé IPC et le chemin d'accès au fichier. Exécutez find pour répertorier tous les fichiers de votre système de fichiers et dirigez la sortie vers votre programme nouvellement créé. À combien de noms de fichiers la même clé correspond-elle?

6. Si votre système dispose du programme sar (System Activity Reporter), exécutez la commande

L'écran affichera le nombre d'opérations par seconde avec des files d'attente de messages et des sémaphores mesurés toutes les 5 secondes 6 fois.

Remarques:

L'IPC est un concept connexe, mais il est logique de comprendre de quoi il s'agit plus en détail.

Contenu:

Page théorique

Tout le monde a une petite idée du fonctionnement d'un système d'exploitation normal.

Imaginez maintenant que le travail habituel de notre système d'exploitation est devenu son double maléfique, qui non seulement ne ressemble pas à son original, mais remplit également toutes ses fonctions.

Ce développement aurait très bien pu se produire s'il n'avait pas été intégré à notre système IPC.

Si vous étudiez bien la question de la dépendance des programmes les uns par rapport aux autres, vous comprendrez qu'il existe de nombreuses applications qui ne dépendent pas les unes des autres.

C'est assez logique, car pour un rendement élevé de tout système, il est simplement nécessaire entre les composants.

Par exemple, lorsqu'une personne au travail a une question qui dépend de son travail, elle prend les informations dont elle a besoin à une source, que ce soit une personne ou toute autre source.

Bien que le «cœur» de notre ordinateur soit de rechercher des informations dans une source spécifique, le principe des robots est essentiellement le même.

Principe d'opération

Pour le bon fonctionnement du système, les applications ont nécessairement besoin d'une communication continue entre elles, ou elles sont elles-mêmes obligées de fournir les informations nécessaires à la demande des processus.

C'est en raison de ce besoin d'un échange constant d'informations avec les applications qu'un grand nombre de mécanismes sont intégrés au système d'exploitation, chargés de maintenir un flux d'informations constant et sans erreur.

Ces mécanismes ou programmes sont appelés "communication interprocesseur" - de la traduction d'Inter-process Communication (IPC).

Important: IPC est un mécanisme ou un programme qui fournit un échange mutuel stable de données entre les flux d'informations de processus / processeur.

Travaux ce programme directement dans le système d'exploitation lui-même, et constitue la base du transfert de toute information.

Exemples de travaux IPC

Avant même le développement des technologies de réseau, la question de la nécessité de transférer des informations du processeur au processeur fonctionnant sur un ordinateur est devenue pertinente.

Il y a juste un grand nombre d'exemples où ce programme a été utilisé dans des mécanismes plutôt primitifs, à l'heure actuelle.

Jetons un coup d'œil à l'un des exemples clés qui illustrera clairement l'importance de la CIB, même dans des systèmes très simples et précoces, sans parler de son besoin aujourd'hui.

Les anciennes versions de l'IPC moderne étaient présentes dans MS-DOS.

Dans le processus de développement technologique, alors que les technologies et les systèmes de réseau ne faisaient que commencer leur long chemin de développement, un besoin a commencé à apparaître pour des mécanismes qui créent une interconnexion de processeurs mis en œuvre, consistant en un seul réseau.

À cette époque, la solution à ce problème était très problématique.

Le fait est qu'une telle connexion pourrait échanger des données si seules leurs plates-formes ou systèmes d'exploitation étaient du même modèle.

Dans le réseau moderne, ces problèmes n'ont inquiété personne depuis longtemps. Voici un court exemple visuel de travail dans de tels réseaux.

Ces processus sont effectués sur deux ordinateurs différents, à deux endroits différents:

• un navigateur sur votre système;
• serveur - dans n'importe quel autre système ou absolument n'importe où.

Et vous ne vous demandez pas du tout quel est le système d'exploitation des serveurs.

En ce qui concerne le principe général de fonctionnement de formulaires tels que l'IPC, et pas seulement de ceux-ci, le concept de "client-serveur" est principalement utilisé.

Il est clair que le «client» est une application qui demande des informations, et la demande d’informations va au «serveur» - une application qui fournit les informations nécessaires.

Position générale

Après avoir examiné toutes les possibilités et les exemples d'utilisation de la communication interprocesseur, vous pouvez constater par vous-même que ce logiciel est simplement nécessaire au fonctionnement du système d'exploitation auquel nous sommes si habitués.

Les domaines d'interaction IPC, à la fois dans un système unique et dans un réseau multi-utilisateurs, seront énumérés ci-dessous.

Aujourd'hui, les exigences des systèmes d'exploitation augmentent proportionnellement au niveau de la technologie.

Cette croissance est due au fait que chaque jour, de plus en plus d'add-ons sont publiés sur nos systèmes d'exploitation, qui à leur tour améliorent les caractéristiques de notre ordinateur.

Mais peu de gens savent que les systèmes d'exploitation modernes qui prennent en charge doivent avoir de tels programmes ou mécanismes qui assurent la synchronisation des processeurs sans exclusion mutuelle et avec un minimum de retards.

Ces critères sont très importants dans le robot de notre ordinateur.

Si nous parlons d'un système multitâche idéal, tous les processus qui y sont exécutés doivent être indépendants les uns des autres, c'est-à-dire asynchrones.

En réalité, un tel système «idéal» est impossible, car tôt ou tard, des situations surviennent lorsque les processus ont besoin d'accéder à certaines ressources communes.

Pour obtenir cette opportunité, au niveau du système d'exploitation, il existe des ressources spéciales qui leur offrent cette opportunité.

Mais ici, bien sûr, non sans exceptions. Des problèmes peuvent survenir lors de l'exécution de processus parallèles.

Par exemple: Lorsqu'ils travaillent ensemble, chaque processus accédant aux données partagées rend impossible l'accès simultané de tous les autres processus à ces données - ce phénomène est appelé exclusion mutuelle.

Trois principaux types d'IPC

• Local

Ce type d'IPC est complètement lié à votre ordinateur, le travail n'est effectué que dans un seul système (ordinateur).

Elle est fondamentale et obligatoire pour le fonctionnement des processus qui assurent le transfert de données à travers le système, à savoir pour les canaux, les files d'attente de messages et la mémoire partagée.

En raison de leur espace de communication limité, les données IPC ne peuvent fonctionner qu'en interne.

Mais en raison de cette limitation, des interfaces plus rapides et plus simples peuvent être utilisées pour eux.

• Éloigné

Pour assurer l'interopérabilité au sein d'un système avec un seul processeur, ou entre des programmes sur différents processeurs connectés via le même réseau, des mécanismes spéciaux sont utilisés qui fournissent un IPC distant.

• Haut niveau

Le dernier et peut-être l'un des plus difficiles à utiliser IPC est de haut niveau.

Cette vue est un progiciel.

Ce paquet de données crée ce que l'on appelle une «couche intermédiaire» qui permet la communication entre la plate-forme système et l'application.

Assurer le bon fonctionnement de l'échange de données

Avec sa fonction principale de fournir des interactions entre les processeurs, les outils ICP sont connectés à la résolution des problèmes qui surviennent lors de l'organisation du calcul parallèle.

Voici des exemples de leurs domaines d'expertise:

1 Àcompétitife situations entre processus.Nous pouvons imaginer un système idéal dans lequel une seule action a lieu, il s'agit de lire les données d'un fichier. Ce système est complètement calme jusqu'à ce que l'un des processus ait besoin de modifier ce fichier. Dans ce cas, une «situation concurrentielle» survient entre les processus. Il peut être comparé à un caillou dans une sorte de mécanisme.

2 File d'attente d'enregistrement séquentiel des informations. Pour fournir aux utilisateurs la possibilité d'écrire des données rapidement et de manière fiable, des files d'attente spéciales sont créées. Je pense que vous savez ce qu'est une file d'attente. Mais en fait, pas une, mais deux files d'attente sont créées. Les données de la file d'attente ne diffèrent des données réelles que par le fait que l'une d'elles n'est utilisée que pour la lecture, et l'autre nous permet déjà d'écrire les informations nécessaires. Cette file d'attente est créée afin d'éviter les blocages, dont nous parlerons ci-dessous.

Qu'en est-il des processus qui nécessitent la rapidité inhérente à leur décision?

Auparavant, lors de la création des files d'attente susmentionnées, un problème se posait dans lequel certains processus pouvaient attendre leur tour pendant longtemps, à un moment où ce processus n'était pas retardé.

Après un certain temps, l'idée a été inventée de créer des files d'attente qui exécutaient un tel ordre de processus qui n'interférait pas avec les processus principaux ou les plus importants.

En outre, il existe un terme qui, à la fois en théorie et en pratique, est justifié par son nom - c'est une impasse.

Sa particularité est que bien que les processus aient déjà été publiés, ils ne peuvent pas passer à l'étape suivante pour terminer le processus.

Si c'est plus facile à expliquer, alors en pratique, il se passe ce qui suit: nous avons un processus X, lorsqu'il accède au fichier X, il commence à attendre que le fichier Y soit libéré pour compléter son robot. Mais avec eux, le processus Y, ayant accès au fichier Y, attend que le fichier X soit libéré.

Ces processus sont fermés entre eux pour le moment et attendent la libération mutuelle du fichier, sans libérer leur fichier.

Cette "fermeture" peut être évitée si l'utilisateur s'assure que les ressources sont numérotées.

Ils doivent également être construits strictement dans l'ordre numérique croissant.

Exemples modernes de travail ICP

Afin de représenter visuellement l'interaction des programmes sur un ordinateur, il existe une ressource familière - le presse-papiers.

Ne soyez pas surpris, notre bon vieux presse-papiers fait également partie des mécanismes IPC.

Et le principe de son travail est le suivant: le texte sélectionné dans l'éditeur de texte après sélection est placé dans ou dans le même programme pour la mise en page.

Vous pouvez voir par vous-même que des traces de mécanismes de communication interprocesseur peuvent être trouvées même dans les petits détails.

Il y a eu de nombreuses tentatives pour créer des programmes ou des mécanismes qui permettraient un transfert rapide et efficace d'informations entre les processeurs.

Bien que bon nombre de ces outils aient été créés, nombre d'entre eux sont encore préservés ou ont servi de base à de futurs modèles.

Il est à noter que beaucoup d'entre eux ont été implémentés sous Windows 9x, et encore plus sous Windows NT / 2000.

Je voudrais attirer votre attention sur le fait que l’existence d’une méthode universelle d’échange de données qui serait utile dans toutes les situations est tout simplement impossible.

Quel que soit l'environnement dans lequel se trouve l'utilisateur, exactement l'une des méthodes sera préférable, bien qu'il n'y ait pas de grande différence entre elles dans des conditions normales.

Mais nous pouvons vous assurer qu'après cet article, vous n'aurez plus de difficultés à naviguer dans les ressources associées à IPC ou au choix d'une méthode ou d'un autre robots, pesant tous les avantages et inconvénients.

Pour ceux qui pensent que le développement de cette technologie n'est pas annoncé, il y a un fait qui changera votre opinion.

Les programmes et mécanismes associés à IPC sont directement liés au système d'exploitation. Autrement dit, l'efficacité et la fiabilité de ces ressources augmenteront à mesure que les robots s'amélioreront.

De nombreux utilisateurs de LAN ignorent souvent que leurs lecteurs sont des ressources réseau auxquelles ils peuvent se connecter, appelées ressources administratives et partagées cachées C $, ADMIN $, FAX $, IPC $, PRINT $. Vous devez les désactiver si vous n'en avez pas besoin!

Types de partages réseau dans Windows XP / 200

Par défaut, les partages administratifs masqués suivants peuvent être créés dans Windows XP / 2000:

1. partitions ou volumes racine C $ ( D $, E $, F $, etc.);
2. répertoire racine du système d'exploitation ADMIN $;
3. partager FAX $;
4. partager IPC $;
5. partager PRINT $.

Pour les partitions et volumes racine Le nom de partage est le nom du lecteur suivi de " $ ". Par exemple, pour accéder aux disques C et ré des ressources partagées seront créées C $ et D $.

Racine du système d'exploitation ( % SYSTEMROOT%) Est le répertoire dans lequel le système d'exploitation Windows est installé. Ressource partagée ADMIN $ donne aux administrateurs l'accès à ce dossier sur le réseau.

Partage FAX $ utilisé par les utilisateurs pour envoyer des fax. Les fichiers et les pages de titre situés sur le serveur de fichiers sont mis en cache dans ce dossier.

Partage IPC $ utilisé pour établir des connexions temporaires créées par des applications pour échanger des données à l'aide de canaux nommés. En règle générale, il est utilisé pour l'administration à distance de serveurs sur un réseau.

Partager PRINT $ utilisé pour l'administration à distance des imprimantes.

Si vous supprimez des ressources administratives masquées créées par le système d'exploitation ( par exemple ADMIN $ ou C $), puis après avoir redémarré l'ordinateur ou redémarré le service "Serveur", ils seront recréés. Si vous supprimez les ressources administratives masquées créées par les utilisateurs, elles ne seront pas recréées après le redémarrage de l'ordinateur. Microsoft Windows XP Home Edition ne crée pas de partages administratifs masqués.

Connexion aux partages réseau sous Windows XP / 2000

Pour vous connecter à des ressources réseau administratives et partagées masquées, vous pouvez utiliser la commande Windows XP / 2000 standard utilisation nette:

Commande Net use est utilisé pour se connecter et se déconnecter des ressources réseau et pour afficher des informations sur les connexions actuelles à ces ressources. Si la ressource réseau est le lecteur actuel ou est utilisée par une application en cours d'exécution, vous ne pouvez pas vous déconnecter de cette ressource.

Voici un exemple d'utilisation de la commande net use pour se connecter à un partage standard C $, ordinateur sous gestion Windows 2000, avec le nom complet Pro2000, situé à réseau local:

Commande Net use réussi avec le nom d'utilisateur Administrateur et un mot de passe vide! Dans la plupart des cas, après l'installation de Windows, le mot de passe du compte nommé Administrateur, créé par défaut, est oublié ou ne veut tout simplement pas être défini, et il se trouve que lors de l'installation, un autre compte administratif a été créé, et le compte nommé Administrateur créé par défaut , a été laissé sans surveillance!

C: \\\u003e cd / d q: Q: \\\u003e dir Le volume sur le périphérique Q n'a pas d'étiquette. Numéro de série du volume: 407D-A72A Contenu du dossier Q: \\ 13.03.2012 08:46 0 AUTOEXEC.BAK 13.03.2012 08:57 Documents and Settings 17.06.2012 08:34 Intel 01.04.2012 04:02 MySoft 17.06.2012 11: 35 NC 18.06.2012 10:10 OpenSSL-Win32 18.06.2012 10:08 Program Files 25.06.2012 15:48 PUBLIC 18.05.2012 10:53 rms 29.04.2012 10:48 Temp 11.06.2012 22:28 WINDOWS 1 fichiers 0 octet 10 dossiers 1919221760 octets libres Q: \\\u003e

Après avoir connecté la ressource C $ et son association avec une lettre de lecteur, ressource C $ sera disponible dans votre explorateur et il sera possible de travailler avec lui comme avec un disque local ordinaire, eh bien, tout dépendra de vos capacités et de votre imagination ...

ATTENTION!!! Les ressources partagées ne seront disponibles que lorsque le service "Serveur" est activé / démarré, et si vous n'allez pas partager vos ressources, il est préférable non seulement de l'arrêter, mais de le désactiver complètement. Service de serveur: prend en charge le partage de fichiers, d'imprimantes et de canaux nommés pour cet ordinateur via une connexion réseau. Si le service est arrêté, ces fonctions échoueront. Si le service donné n'est pas résolu, les services explicitement dépendants ne pourront pas démarrer.

L'exemple ci-dessus démontre clairement la vulnérabilité des ressources réseau nues et le compte Administrateur créé par défaut avec un mot de passe vierge! Pour éviter la formation de telles lacunes et à la suite d'une réinstallation régulière de Windows, suivie d'un anathème à Bill Gates, il vous suffit de couvrir initialement, pour ainsi dire, toutes les lacunes et les trous !!!

Désactiver / supprimer les partages réseau

Le moyen le plus simple est de désactiver le service "Serveur", mais certains services et programmes ont besoin de son support, auquel cas la désactivation du service "Serveur" ne nous convient pas.

Pour désactiver les partages administratifs et réseau ( C $, ADMIN $, FAX $, IPC $, IMPRIMER $) sous Windows XP / 2000, vous avez besoin de:

REMARQUE! Vous n'avez pas besoin d'ajouter le paramètre AutoShareWks dans Windows 2000.

Après le redémarrage du PC, tous les partages réseau seront supprimés, à l'exception d'un IPC $, il ne peut pas être supprimé:

Part spéciale IPC $

C'est une ressource pour partager des canaux nommés qui assurent la communication entre les programmes. Utilisé pour l'administration à distance de l'ordinateur et pour afficher les ressources partagées de l'ordinateur. Cette ressource ne peut pas être supprimée.

Le partage spécial IPC $ est requis pour le fonctionnement du service Serveur et ne peut pas être supprimé. Vous pouvez afficher une liste des partages réseau actuels avec la commande net share

Nous répétons que pour éviter la formation de lacunes dans les ressources réseau partagées et à la suite d'une réinstallation régulière de Windows suivie d'un anathème à Bill Gates, il vous suffit de couvrir dans un premier temps, pour ainsi dire, toutes les lacunes et les trous !!!

Qu'est-ce que l'IPC $? J'ai entendu dire que le piratage à distance est possible grâce à lui? Dois-je désactiver cette ressource, si oui, comment le faire?

IPC $, ou Inter-Process Communication, est une ressource administrative spéciale pour la création de canaux nommés. Au moyen de ce dernier, les ordinateurs échangent diverses informations de service sur le Web. IPC $ est également utilisé pour la gestion de serveur à distance (Figure 10.1).

Figure: 10.1.Activation du service de mise en réseau IPC $

Pour décider de désactiver ou non une ressource donnée, tenez compte des éléments suivants:

¦ s'il s'agit d'un poste de travail qui doit être contrôlé à distance, il vaut mieux ne pas l'éteindre;

¦ si le poste de travail ne nécessite pas d'administration à distance, vous pouvez le désactiver;

¦ s'il s'agit d'un serveur, cela ne vaut pas du tout la peine de se déconnecter, car il sera impossible de l'atteindre via le réseau.

IPC $ désactivé via CMD avec la commande net share ipc $ / delete (après le redémarrage, cette ressource est toujours activée par elle-même, vous pouvez donc écrire le fichier BAT correspondant et le mettre au démarrage).

Mon ordinateur se trouve sur un réseau local. Vous devez vous assurer que la machine expose les ressources publiques, et en même temps que les partages cachés C $, D $, etc. ne sont pas disponibles. Comment faire?

Tout ce que vous avez à faire est de créer un DWORD AutoshareWks nullable dans la section suivante:.

Qu'est-ce que l'usurpation d'identité et comment pouvez-vous vous en protéger?

En fait, l'usurpation d'identité est une substitution. Dans ce cas, nous entendons l'usurpation IP, c'est-à-dire l'usurpation IP. Usurpation d'identité, dans laquelle un utilisateur malveillant, utilisant l'adresse IP de quelqu'un d'autre située dans la zone d'adresse IP de confiance, ou une adresse externe autorisée, usurpe l'identité d'un objet qui peut être approuvé. Le plus souvent, pour se protéger contre l'usurpation IP, la méthode de liaison de l'adresse IP à l'adresse de la carte réseau (adresse MAC) est utilisée, mais cette méthode est également imparfaite: à l'heure actuelle, on connaît des utilitaires qui remplacent le MAC actuel.

Qu'est-ce que le reniflement et existe-t-il des mesures de protection spécifiques contre celui-ci?

Dans le cas le plus simple, renifler signifie intercepter des paquets sur le réseau. Plus précisément: le sniffer met la carte réseau (où elle est installée) dans le soi-disant "mode promiscuous", grâce auquel la machine de l'attaquant capture tous les paquets réseau, même ceux qui ne lui sont pas destinés. Un exemple de renifleur est Caïn & Abel. Comme protection lors de la construction d'un réseau local, nous pouvons recommander l'utilisation de commutateurs (switch) plutôt que de hubs (hub), ainsi que l'utilisation de protocoles qui ne transmettent pas de données en clair (SSH, SSL, Kerberos). Mais même dans ce cas, il est possible d'intercepter des paquets en utilisant des techniques avancées (par exemple, ARP Poizoning).

Qu'est-ce que le phishing et pouvez-vous vous en protéger?

Le phishing est une technique pour tromper les visiteurs du site Web. La ligne du bas: un visiteur entre dans un site très similaire à l'original, remplit les colonnes qui nécessitent une entrée information confidentielle (numéro de carte de crédit, mot de passe, etc.). Ensuite, toutes ces informations sont envoyées à l'attaquant qui a créé ce faux site. Les outils anti-hameçonnage se trouvent dans les dernières versions des navigateurs Internet, ainsi que dans les packages antivirus et les pare-feu. Cependant, il faut admettre qu'à ce jour, il n'existe aucun moyen efficace de se protéger contre le phishing. Le principal outil de protection dans ce cas est la vigilance de l'utilisateur.

On sait que de nombreux virus remplacent les fichiers système par les leurs. Comment définir cette substitution?

Pour toujours être au courant de ces «astuces», vous devez activer la fonction de notification de protection des fichiers. Cela se fait en entrant le paramètre DWORD ShowPopups égal à 1 dans le registre à HKEY_ LOCAL_MACHINE \\ Software \\ Microsoft \\ Windows \\ CurrentVersion \\ Sys-temFileProtection.

Comment effacer les mots de passe mémorisés dans IE?

Une chose plutôt pratique est intégrée à Internet Explorer - la saisie semi-automatique et la mémorisation du mot de passe. Pour effacer les mots de passe mémorisés, procédez comme suit: dans IE, accédez à Outils\u003e Options Internet\u003e Contenu\u003e Informations personnelles\u003e Saisie semi-automatique.puis appuyez sur le bouton Effacer les mots de passe.

Comment puis-je masquer les URL des sites visités, qui sont automatiquement mises en surbrillance dans la barre d'adresse lorsque je saisis une nouvelle adresse?

Ces traces peuvent être supprimées en supprimant les entrées de registre correspondantes sur. Remarque: d'autres traces sont également enregistrées ici, comme l'historique d'accès aux lecteurs distants C $, D $ pour LAN, l'historique de ce que vous avez tapé dans les formulaires de recherche, etc.

Après vérification, Kaspersky a découvert que l'enregistrement de démarrage principal avait été modifié dans le système. Ce que cela peut être et comment récupérer état d'origine enregistrement de démarrage (Figure 10.2)?

Figure: 10.2.Vérifier les enregistrements de démarrage?

Très probablement, le chargeur de démarrage modifié est une conséquence d'un virus de démarrage, bien qu'il soit possible que le chargeur de démarrage ait changé et non à cause d'une infection virale. Vous pouvez restaurer le chargeur de démarrage à partir de la console de récupération: pour ce faire, vous devez démarrer dans la console de récupération et écrire les commandes fix mbr et fix boot. Vous pouvez démarrer dans la console de récupération via le disque XP bootable en sélectionnant Réparer l'instaLLation Windows XP ®et ConsoLe de récupération ©.Cependant, récupérer de cette manière n'est pas la meilleure. Dans la plupart des cas, le chargeur de démarrage n'est toujours pas restauré. Seuls des logiciels spécialisés peuvent résoudre de tels problèmes, comme un exemple frappant dont ADINF32 peut être cité.

Dites-moi où les mises à jour sont enregistrées dans Kaspersky Anti-Virus 7.0. Sinon, lorsque vous réinstallez le système, vous devrez à nouveau télécharger toutes les mises à jour.

Mises à jour - le dossier contenant les bases de données se trouve dans et Paramètres \\ All Users \\ Application Data \\ Kaspersky Lab \\ AVP7 \\ Bases.

Compte tenu des résultats de nombreux tests, on peut dire qu'aucun des navigateurs existants n'est sécurisé à 100%. Pendant ce temps, certains des produits peuvent encore être considérés comme suffisamment sûrs. Opera est l'un de ces produits.

La situation est la suivante: mon ordinateur est sur un réseau local et j'ai accès à Internet via une carte. La limite de l'ancienne carte a été épuisée, mais il n'est pas possible de saisir un nouveau nom d'utilisateur et un nouveau mot de passe, car lorsque vous essayez d'entrer sur un site, la fenêtre d'authentification avec le serveur n'apparaît pas (tous les paramètres du serveur proxy sont corrects). Comment retourner la fenêtre de saisie du login et du mot de passe?

Pour réapparaître la fenêtre d'authentification, vous devez supprimer l'ancien nom d'utilisateur et le mot de passe via le snap comptes utilisateur(fig.10.3) - pour cela aller dans le menu Début? Courir,entrez le contrôle de commande userpasswords2, dans la fenêtre qui apparaît, cliquez sur Aditionellement? Gestion des mots de passe? Supprimer.

Au démarrage du système, Kaspersky Anti-Virus, qui fonctionnait auparavant sans échec, a cessé pour une raison quelconque de démarrer; lorsque vous essayez de forcer le démarrage, il s'éteint également. Que peut-il être et comment y faire face?

Très probablement, votre système est infecté par un virus qui désactive Kaspersky Anti-Virus. Cette «infection» est très probablement configurée pour désactiver également d'autres produits antivirus populaires. Quitter - démarrer à partir d'un environnement propre, tel qu'un disque de démarrage (Windows LiveCD). Ensuite, en option, dans cet environnement, vérifiez le système avec un antivirus qui ne nécessite pas d'installation (un tel antivirus peut être lancé à partir d'un lecteur flash, par exemple, le produit populaire Dr.Web CureIt Scanner (Fig.10.4), qui peut être téléchargé sur le site officiel de Dr.Web) ...

Figure: 10.3.Gestion des mots de passe

Figure: 10.4.Le scanner CureIt en action

Vérifié mon disque dur Les distributions Kaspersky et Panda Titanium ont trouvé un vrai virus! Comment être?

Très probablement, le fichier n'est pas infecté par quoi que ce soit et vous ne devez pas déclencher l'alarme. La plupart des programmes antivirus fonctionnent de temps en temps lors de l'analyse de fichiers à partir d'autres antivirus.

Je suis un administrateur système novice et j'aimerais connaître votre opinion sur lequel des systèmes d'exploitation serveur peut être considéré comme le plus fiable et le plus productif?

ma pare-feu signale constamment les paquets arrivant de quelque part avec l'indicateur "syn". Qu'est-ce que ça veut dire?

Il est fort probable que quelqu'un ou quelque chose (un ver de réseau, par exemple) scanne votre machine. La numérisation est généralement une préparation à une attaque. Par conséquent, vous avez quelque chose à penser.