L'acronimo IPC significa comunicazione tra processi,  cioè, l'interazione dei processi. Di solito ciò si riferisce al trasferimento di messaggi di vario tipo tra processi in qualsiasi sistema operativo. In questo caso, è possibile utilizzare varie forme di sincronizzazione, richieste dai moderni tipi di interazione, eseguite, ad esempio, attraverso la memoria condivisa.

Nel processo di sviluppo della famiglia di sistemi operativi Unix negli ultimi 30 anni, i metodi di messaggistica si sono evoluti come segue:

■ I canali (pipe - capitolo 4) sono stati la prima forma ampiamente utilizzata di interazione di processo disponibile per i programmi e l'utente (dall'interprete dei comandi). Lo svantaggio principale dei canali è l'incapacità di utilizzarli tra processi che non hanno un genitore comune (antenato), ma questo svantaggio è stato eliminato con l'avvento di named pipe (named pipe) o canali FIFO (capitolo 4).

■ Le code dei messaggi di System V (capitolo 4) sono state aggiunte ai core di System V nei primi anni '80. Possono essere utilizzati per trasferire messaggi tra processi sullo stesso nodo, indipendentemente dal fatto che questi processi siano correlati. Nonostante il prefisso "System V", la maggior parte delle versioni moderne di Unix, comprese quelle non derivate da System V, supportano queste code.

NOTA

Per i processi Unix, il termine "parentela" significa che i processi condividono un antenato comune. Resta inteso che i processi che sono parenti sono stati creati da questo processo antenato utilizzando una o più forcelle. L'esempio più semplice sarebbe chiamare fork su un processo due volte, il che porterebbe alla creazione di due processi generati. Quindi possiamo parlare della relazione di questi processi tra loro. Naturalmente, ogni processo generato è un parente di quello che lo ha generato. Il genitore può occuparsi della possibilità di interagire con il processo generato (creando una coda di pipe o di messaggi) prima di chiamare fork, e questo oggetto IPC verrà ereditato dal processo generato. Per ulteriori informazioni sull'ereditarietà degli oggetti IPC, vedere la tabella. 1.4. Va anche notato che tutti i processi Unix sono teoricamente discendenti del processo init, che esegue tutto il necessario durante il processo di avvio (bootstrap). Da un punto di vista pratico, è meglio contare la relazione dei processi dalla shell di login e tutti i processi da essa creati. Il capitolo 9 descrive le sessioni e le relative relazioni dei processi in modo più dettagliato.

NOTA

Note come questa verranno utilizzate da noi al fine di chiarire le funzionalità di implementazione, fornire un background storico e suggerimenti utili.

■ Le code dei messaggi Posix (code dei messaggi Posix - Capitolo 5) sono state aggiunte allo standard Posix (1003.1b-1993, che è discusso in maggior dettaglio nella Sezione 1.7). Possono essere utilizzati per l'interazione di processi correlati e non correlati su qualsiasi nodo.

■ Le chiamate di procedura remota (RPC, parte 5) sono apparse negli anni '80 come mezzo per chiamare funzioni su un sistema (server) da un programma in esecuzione su un altro sistema (client). Questo strumento è stato sviluppato come alternativa per semplificare la programmazione della rete. Poiché le informazioni vengono generalmente trasferite tra il client e il server (gli argomenti vengono passati per chiamare la funzione e restituire i valori) e poiché una chiamata di procedura remota può essere utilizzata tra il client e il server sullo stesso nodo, RPC può anche essere considerato una forma di trasferimento di messaggi.

È anche interessante osservare l'evoluzione di varie forme di sincronizzazione durante lo sviluppo di Unix:

■ I primissimi programmi che necessitavano di sincronizzazione (il più delle volte per impedire a diversi processi di modificare contemporaneamente il contenuto del file) utilizzavano le funzionalità del file system, alcune delle quali sono descritte nella sezione 9.8

■ Il blocco dei record (capitolo 9) è stato aggiunto ai kernel Unix nei primi anni '80 e standardizzato in Posix.1 nel 1988.

■ I semafori di System V (semafori di System V - capitolo 11) sono stati aggiunti insieme alla possibilità di condividere la memoria (memoria condivisa di System V - capitolo 14) e contemporaneamente alle code di messaggi di System V (primi anni '80). Questi IPC sono supportati dalla maggior parte delle versioni moderne di Unix.

■ Anche i semafori Posix (Posix semafori - capitolo 10) e Posix memoria condivisa (Posix memoria condivisa - capitolo 13) sono stati aggiunti allo standard Posix (1003.1b-1993, precedentemente menzionato in relazione alle code dei messaggi Posix).

■ Le eccezioni reciproche e le variabili condizionali (mutex, variabile condizionale - capitolo 7) sono due forme di sincronizzazione definite dallo standard del thread software Posix (thread Posix, Pthreads - 1003.1s-1995). Sebbene vengano generalmente utilizzati per la sincronizzazione tra thread, possono anche essere utilizzati per organizzare l'interazione dei processi.

■ I blocchi di lettura / scrittura (capitolo 8) sono un'ulteriore forma di sincronizzazione. Non è ancora incluso nello standard Posix, ma probabilmente lo sarà presto.

1.2. Processi, thread e condivisione delle informazioni

Nel tradizionale modello di programmazione Unix, è possibile eseguire contemporaneamente più processi in un sistema, a ciascuno dei quali è assegnato un proprio spazio di indirizzi. Questo è illustrato in fig. 1.1.

Fig. 1.1. Condivisione delle informazioni tra processi

1. I due processi sul lato sinistro condividono le informazioni memorizzate in uno degli oggetti del filesystem. Per accedere a questi dati, ogni processo deve passare al kernel (usando le funzioni read, write, lseek, write, lseek e simili). È necessaria una qualche forma di sincronizzazione quando si modifica un file, per eliminare le interferenze quando più processi scrivono nel file contemporaneamente e per proteggere i processi di lettura dal file da quelli che vi scrivono.

2. Due processi nel mezzo dell'immagine condividono le informazioni memorizzate nel kernel. Esempi in questo caso sono un canale, una coda di messaggi o un semaforo di Sistema V. In questo caso, le chiamate di sistema verranno utilizzate per accedere alle informazioni condivise.

3. I due processi sul lato destro utilizzano un'area di memoria comune a cui ciascuno dei processi può accedere. Dopo aver ottenuto l'accesso a quest'area di memoria, i processi saranno in grado di accedere ai dati senza l'aiuto del kernel. In questo caso, come nel primo, anche i processi che utilizzano la memoria condivisa richiedono la sincronizzazione.

Si noti che in nessuno di questi casi il numero di processi interagenti è limitato a due. Uno qualsiasi dei metodi descritti funziona per un numero arbitrario di processi interagenti. Nella figura, ne descriviamo solo due per semplicità.

flussi

Sebbene il concetto di processi su sistemi Unix sia in circolazione da molto tempo, la capacità di utilizzare più thread all'interno dello stesso processo è relativamente recente. Lo standard di thread Posix.1, chiamato Pthreads, è stato adottato nel 1995. Dal punto di vista dell'interazione dei processi, tutti i thread di un processo hanno variabili globali comuni (ovvero l'uso della memoria condivisa è tipico di un modello di flusso). Tuttavia, i thread richiedono la sincronizzazione dell'accesso ai dati globali. In generale, la sincronizzazione, sebbene non sia una forma di IPC stessa, viene spesso utilizzata insieme a varie forme di IPC per controllare l'accesso ai dati.

Questo libro descrive l'interazione tra processi e tra thread. Partiamo dal presupposto che esiste un ambiente in cui è supportata la programmazione multi-thread e utilizzeremo le espressioni del modulo "se il canale è vuoto, il flusso chiamante viene bloccato fino a quando un altro flusso non scrive sul canale". Se il sistema non supporta i flussi, è possibile sostituire "flussi" con "processi" in questa frase e si ottiene la classica definizione di blocco in Unix che si verifica durante la lettura da un canale vuoto con il comando read. Tuttavia, in un sistema che supporta thread, viene bloccato solo il thread che richiede i dati dal canale vuoto e tutti gli altri thread del processo continueranno a essere eseguiti. Un altro thread dello stesso processo o un thread di un altro processo può scrivere dati sul canale.

L'Appendice B riassume alcune delle caratteristiche di base dei thread e descrive le cinque funzioni principali di Pthread utilizzate nei programmi di questo libro.

1.3. Sopravvivenza dell'oggetto IPC

È possibile definire la persistenza di qualsiasi IPC come durata della sua esistenza. In fig. 1.2 mostra tre possibili gruppi ai quali è possibile assegnare oggetti di sopravvivenza.

Fig. 1.2. Sopravvivenza dell'oggetto IPC

1. Un oggetto IPC la cui sopravvivenza è determinata da un processo (processo persistente) esiste fino a quando non viene chiuso dall'ultimo processo in cui è ancora aperto. Un esempio è senza nome e denominato pipe (pipe, FIFO).

2. Un oggetto IPC, la cui sopravvivenza è determinata dal kernel (persistente al kernel), esiste fino al riavvio del kernel o fino a quando l'oggetto non viene esplicitamente eliminato. Esempi sono code di messaggi System V, semafori e memoria condivisa. La sopravvivenza delle code dei messaggi Posix, dei semafori e della memoria condivisa dovrebbe essere determinata almeno dal kernel, ma può anche essere determinata dal file system in base all'implementazione.

3. Un oggetto IPC la cui sopravvivenza è determinata dal file system (file system persistente) esiste fino a quando non viene eliminato esplicitamente. Il suo valore viene preservato anche al riavvio del kernel. Le code dei messaggi Posix, i semafori e la memoria condivisa hanno questa proprietà se sono implementate attraverso i file visualizzati (non è sempre così).

Bisogna fare attenzione quando si determina la sopravvivenza di un oggetto IPC, poiché non è sempre ovvio. Ad esempio, i dati nella pipe vengono elaborati dal kernel, ma la sopravvivenza dei canali è determinata dai processi, non dal core, perché dopo l'ultimo processo in cui il canale è stato aperto per la lettura lo chiude, il kernel ripristinerà tutti i dati ed eliminerà il canale. Allo stesso modo, sebbene i canali FIFO abbiano nomi nel file system, la loro vitalità è anche determinata dai processi, poiché tutti i dati in tale canale vengono resettati dopo che l'ultimo processo in cui è stato aperto lo chiude.

Nella tabella. 1.1 riassume le informazioni sulla sopravvivenza degli oggetti IPC precedentemente elencati.

Tabella 1.1 Sopravvivenza di vari tipi di oggetti IPC

Tipo IPC	La vitalità determina
Canale programma (pipe)	Il processo
Pipeline denominata (FIFO)	Il processo
Posix mutua eccezione (mutex)	Il processo
Variabile condizionale Posix	Il processo
Posix Blocco lettura / scrittura (blocco)	Il processo
Blocco di scrittura Fcntl	Il processo
Coda messaggi Posix	Il nucleo
Posix chiamato semaforo (chiamato semaforo)	Il nucleo
Posix semaphore in memory (semaforo basato sulla memoria)	Il processo
Posix Shared Memory (memoria condivisa)	Il nucleo
Sistema V Accodamento messaggi	Il nucleo
Sistema semaforo V	Il nucleo
	Il nucleo
Socket TCP	Il processo
Socket UDP	Il processo
Presa di dominio Unix (presa di dominio Unix)	Il processo

Si noti che nessun tipo di IPC in questa tabella ha la sopravvivenza definita dal file system. Abbiamo già detto che i tre tipi di oggetti IPC nello standard Posix lattinaavere questo tipo di sopravvivenza a seconda dell'implementazione. Ovviamente, la scrittura di dati in un file fornisce la sopravvivenza determinata dal file system, ma gli IPC di solito non vengono implementati in questo modo. La maggior parte degli oggetti IPC non è progettata per esistere dopo un riavvio, poiché i processi non sopravvivono. Il requisito di sopravvivenza definito dal file system è probabile che riduca le prestazioni di questo tipo di IPC, e di solito una delle attività dello sviluppatore è quella di garantire prestazioni elevate.

1.4. spazi dei nomi

Se due processi non correlati utilizzano un qualche tipo di IPC per scambiare informazioni, l'oggetto IPC deve avere un nome o un identificatore in modo che uno dei processi (di solito chiamato server) possa creare questo oggetto e l'altro processo (di solito uno o più client è il client) potrebbe riferirsi a questo particolare oggetto.

I canali software (pipe) non hanno nomi (e quindi non possono essere utilizzati per l'interazione tra processi non correlati), ma i canali FIFO sono associati ai nomi nel file system, che sono i loro identificatori (pertanto, i canali FIFO possono essere utilizzati per l'interazione tra processi non correlati). Per altri tipi di IPC, discussi nei capitoli successivi, vengono utilizzate convenzioni di denominazione aggiuntive. L'insieme di nomi possibili per un particolare tipo di IPC è chiamato il suo spazio dei nomi. Lo spazio dei nomi è un termine importante perché per tutti i tipi di IPC, ad eccezione dei canali semplici, il nome determina il modo in cui client e server comunicano tra loro per la messaggistica.

Nella tabella. 1.2 sono riassunte le convenzioni di denominazione per vari tipi di IPC.

Tabella 1.2 Spazi dei nomi per vari tipi di IPC

Tipo IPC	Spazio dei nomi da creare o aprire	ID dopo l'apertura	Posix.1 1996	Unix 98
canale	(Senza nome)	descrittore
FIFO	Nome file (nome percorso)	descrittore
Posix mutua eccezione	(Senza nome)	Puntatore di tipo pthread_mutex_t
Variabile condizionale Posix	(Senza nome)	Puntatore di tipo pthread_cond_t
	(Senza nome)	Puntatore di tipo pthread_rwlock_t
Blocco record fcntl	Nome del file	descrittore
Posix Shared Memory	Nome IPC Posix	descrittore
Sistema V Accodamento messaggi	Key key_t	ID sistema V IP
Sistema semaforo V	Key key_t	ID sistema V IP
Memoria condivisa di sistema V.	Key key_t	ID sistema V IP
Le porte (porte)	Nome del file	descrittore
Sun Remote Procedure Call (RPC)	Programma / Versione	Gestire RPC
Socket TCP	Indirizzo IP e porta TCP	descrittore	.1g
Socket UDP	Indirizzo IP e porta TCP	descrittore	.1g
Presa di dominio Unix (presa di dominio)	Nome file completo	descrittore	.1g

Indica inoltre quali moduli IPC sono contenuti nello standard Posix.1 del 1996 e quali sono stati inclusi nello standard Unix 98. Entrambi questi standard sono descritti più dettagliatamente nella Sezione 1.7. Per fare un confronto, abbiamo incluso tre tipi di socket in questa tabella, che sono descritti in dettaglio in. Si noti che l'API (Application Program Interface) è standardizzata dal gruppo di lavoro Posix.1g e dovrebbe diventare parte dello standard Posix.1 in futuro.

Sebbene lo standard sia Posix. 1 e rende possibile l'uso dei semafori; il loro supporto non è obbligatorio per i produttori. Nella tabella. 1.3 sono riassunte le funzioni descritte negli standard Posix.1 e Unix 98. Ogni funzione può essere obbligatoria, non definita o facoltativa. Per le funzioni opzionali, specifichiamo il nome della costante (ad esempio, _POSIX_THREADS) che verrà definita (di solito nel file di intestazione ) se questa funzione è supportata. Si noti che Unix 98 contiene Posix.1 come sottoinsieme.

Tabella 1.3 Disponibilità di varie forme di IPC

Tipo IPC	Posix.1 1996	Unix 98
Canale del programma	obbligatorio	obbligatorio
FIFO	obbligatorio	obbligatorio
Posix mutua eccezione	_POSIX_THREADS	obbligatorio
Variabile condizionale Posix	_POSIX_THREADS	obbligatorio
Eccezioni reciproche e variabili condizionali tra processi	_POSIX_THREADS_PROCESS_SHARED	obbligatorio
Posix Blocco lettura / scrittura	(È definito)	obbligatorio
Blocco record fcntl	obbligatorio	obbligatorio
Accodamento messaggi Posix	_POSIX_MESSAGE_PASSING	_XOPEN_REALTIME
Semafori Posix	_POSIX_SEMAPHORES_	_XOPEN_REALTIME
Posix Shared Memory	_POSIX_SHARED_MEMORY_OBJECTS	_XOPEN_REALTIME
Sistema V Accodamento messaggi	(È definito)	obbligatorio
Sistema semaforo V	(È definito)	obbligatorio
Memoria condivisa di sistema V.	(È definito)	obbligatorio
Le porte (porte)	(È definito)	(Non definito)
Chiamata di procedura remota Sun	(È definito)	(Non definito)
Mappatura della memoria Mmap	_POSIX_MAPPED_FILES o POSIX_SHARED_MEMORY_OBJECTS	obbligatorio
Segnali in tempo reale	_POSIX_REALTIME_SIGNALS	_XOPEN_REALTIME

1.5. L'azione dei comandi fork, exec e exit su oggetti IPC

Dobbiamo capire l'effetto delle funzioni fork, exec e _exit sulle varie forme di IPC che discutiamo (l'ultima di queste funzioni è chiamata dalla funzione exit). Le informazioni su questo problema sono riepilogate nella tabella. 1.4.

La maggior parte delle funzioni sono descritte più avanti nel testo del libro, ma qui è necessario sottolineare alcuni punti. Innanzitutto, chiamare fork da un processo multithread porta a un pasticcio in variabili di sincronizzazione anonime (esclusioni reciproche, variabili condizionali, blocchi e semafori memorizzati nella memoria). La sezione 6.1 del libro contiene i dettagli necessari. Notiamo semplicemente, oltre alla tabella, che se queste variabili sono archiviate nella memoria condivisa e create con un attributo condiviso per i processi, saranno disponibili per qualsiasi processo che possa accedere a quest'area di memoria. In secondo luogo, le tre forme di IPC System V non possono essere aperte o chiuse. Il Listato 6.6 e gli esercizi 11.1 e 14.1 mostrano che tutto ciò che devi sapere per accedere a queste tre forme di IPC è un identificatore. Pertanto, sono disponibili per tutti i processi che conoscono questo identificatore, sebbene sia necessaria un'elaborazione speciale per i semafori e la memoria condivisa.

Tabella 1.4 Fork, exec e _exit action su IPC

Tipo IPC	forchetta	exec	_exit
Tubi senza nome e denominati	Il processo generato riceve copie di tutti i descrittori del processo principale	Tutti i descrittori aperti rimangono aperti a meno che il bit FD_CLOEXEC non sia impostato per essi.	Tutti i descrittori aperti vengono chiusi, i dati dal canale del programma e FIFO vengono eliminati dopo l'ultima chiusura
Accodamento messaggi Posix	Il processo generato riceve copie di tutti i processi parent aperti		Tutti i descrittori di coda messaggi aperti sono chiusi.
Code V Code	Non valido	Non valido	Non valido
Eccezioni reciproche e variabili condizionali Posix	Condiviso se la memoria condivisa viene utilizzata con un attributo di processo condiviso		Scompare se non nella memoria condivisa, che rimane aperta e ha un attributo diviso
Posix Blocco lettura / scrittura		Scompare se non memorizzato nella memoria condivisa, che rimane aperta e ha un attributo diviso	Scompare se non memorizzato nella memoria condivisa, che rimane aperta e ha un attributo diviso
Semafori Posix memorizzati	Condivisione se la memoria viene utilizzata con accesso condiviso e un attributo condiviso tra i processi	Scompare se non memorizzato nella memoria condivisa, che rimane aperta e ha un attributo diviso	Scompare se non memorizzato nella memoria condivisa, che rimane aperta e ha un attributo diviso
Posix di nome semafori	Tutto aperto nel processo padre rimane aperto nel bambino.	Tutti aperti vicino	Tutti aperti vicino
Semafori del sistema V.	Tutti i valori semadj nel processo generato sono impostati su 0	Tutti i valori semadj vengono passati al nuovo programma.	Tutti i valori semadj vengono aggiunti al valore semaforo corrispondente.
Blocco record fcntl	I blocchi nel processo padre non sono ereditati dal processo figlio	I blocchi non cambiano fino a quando la maniglia non viene chiusa	Tutti i blocchi non ripristinati impostati dal processo sono sbloccati.
Mappatura della memoria		I mapping di memoria sono ripristinati (unmap)
Posix Shared Memory	Le mappature della memoria del processo padre sono archiviate nel figlio	I mapping di memoria vengono ripristinati	I mapping di memoria vengono ripristinati
Memoria condivisa di sistema V.	I segmenti di memoria condivisa collegati rimangono collegati nel processo generato		Rimozione dei segmenti di memoria condivisa collegati
Le porte (porte)	Il processo generato riceve copie di tutti i descrittori aperti del processo genitore, ma solo il processo genitore è il server quando le porte sono attivate attraverso i descrittori	Tutti i descrittori di porte devono essere chiusi perché sono creati con il set di bit FD_CLOEXEC.	Tutti i descrittori aperti si chiudono

1.6. Gestione degli errori: funzioni wrapper

In qualsiasi programma reale, ogni chiamata richiede il controllo del valore restituito per un errore. Poiché di solito il lavoro dei programmi termina quando si verifica un errore, è possibile ridurre la quantità di testo definendo le funzioni wrapper che eseguono la chiamata di funzione effettiva, controllano il valore restituito ed escono quando si verificano errori. In conformità con le convenzioni, i nomi delle funzioni wrapper coincidono con i nomi delle funzioni stesse, ad eccezione della prima lettera maiuscola, ad esempio

Un esempio di una funzione wrapper è mostrato nel Listato 1.1.

Listato 1.1. Funzione wrapper per la funzione sem_post

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

391 err_sys ("errore sem_post");

Se nel testo vedi un nome di funzione che inizia con una lettera maiuscola, dovresti sapere: questa è la nostra funzione wrapper. Chiama una funzione con lo stesso nome che inizia con una lettera minuscola. La funzione wrapper termina il processo con un messaggio di errore, se presente.

Nel descrivere il codice sorgente incluso nel libro, parliamo sempre della funzione chiamata del livello più basso (ad esempio, sem_post) e non della funzione wrapper (ad esempio, Sem_post). Allo stesso modo, l'indice alfabetico elenca i nomi delle funzioni stesse, non i wrapper per esse.

NOTA

Il formato del codice sorgente sopra è usato dappertutto. Tutte le righe non vuote sono numerate. Il testo che descrive le sezioni del codice inizia con i numeri della prima e dell'ultima riga nel campo vuoto a sinistra. A volte davanti a un paragrafo di testo c'è una breve intestazione in grassetto, che delinea il contenuto principale del codice descritto.

All'inizio del codice, viene indicato il nome del file sorgente. In questo esempio, questo è il file wrapunix.c nella directory lib. Poiché il codice sorgente per tutti gli esempi in questo libro è gratuito (vedi la prefazione), puoi facilmente trovare il file che ti serve. Compilare, eseguire e soprattutto cambiare questi programmi durante la lettura di un libro è il modo migliore per apprendere i concetti di interazione dei processi.

Anche se può sembrare che l'utilizzo di tali funzioni wrapper non sia molto redditizio, nel capitolo 7 ci si sbarazzerà di questo malinteso, in cui scopriamo che le funzioni thread non assegnano un valore alla variabile errno Unix standard quando si verifica un errore; invece, il codice di errore viene semplicemente restituito dalla funzione. Ciò significa che quando chiamiamo la funzione pthread, dobbiamo allocare memoria per la variabile ogni volta, memorizzare il valore restituito dalla funzione in essa e quindi impostare la variabile errno su questa variabile prima di chiamare la funzione err_sys (Listato B.4). Per non ingombrare il testo con parentesi graffe, utilizziamo l'operatore del linguaggio C "virgola" e combiniamo l'assegnazione del valore di errno e la chiamata di err_sys in un'istruzione, come nell'esempio seguente:

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

Un'alternativa è definire una nuova funzione di gestione degli errori che accetta un codice di errore come argomento. Tuttavia, possiamo rendere questo pezzo di codice molto più leggibile scrivendo

Pthread_mutex_lock (& \u200b\u200bndone_mutex);

dove utilizziamo la nostra funzione wrapper, mostrata nel Listato 1.2.

Listato 1.2. Implementazione di un wrapper per la funzione pthread_mutex_lock

126 Pthread_mutex_lock (pthread_mutex_t * mptr)

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

132 err_sys ("errore pthread_mutex_lock");

NOTA

Usando attentamente le capacità del linguaggio C, potremmo usare le macro anziché le funzioni, il che aumenterebbe la velocità di esecuzione del programma, ma queste funzioni del wrapper raramente (se non del tutto) sono colli di bottiglia.

Il nostro accordo di sostituire la prima lettera del nome della funzione con una lettera maiuscola è un compromesso. Sono state prese in considerazione molte altre forme di notazione: l'uso del prefisso e (), del suffisso _e, ecc. La nostra opzione sembra essere la meno distruttiva e allo stesso tempo dare un'indicazione visiva che viene chiamata qualche altra funzione.

Questo metodo ha una proprietà utile laterale: verifica la presenza di errori restituiti da funzioni il cui codice di ritorno viene generalmente ignorato, come close e pthread_ mutex_lock.

Più avanti nel testo del libro, useremo queste funzioni di wrapper, a meno che non abbiamo bisogno di controllare esplicitamente un errore ed elaborarlo arbitrariamente, oltre alla fine del processo. Non forniamo il codice sorgente per tutti i wrapper nel libro, ma è disponibile gratuitamente su Internet (vedere la prefazione).

Valore errno

Quando si verifica un errore nella funzione Unix, alla variabile globale errno viene assegnato un valore positivo che indica il tipo di errore; la funzione di solito restituisce un valore di -1. La nostra funzione err_sys visualizza un messaggio corrispondente al codice di errore (ad esempio, Risorsa temporaneamente non disponibile - la risorsa è temporaneamente non disponibile se errno è impostato su EAGAIN).

La funzione assegna un valore a errno solo quando si verifica un errore. In caso di arresto normale, il valore di questa variabile non è definito. Tutti i valori positivi corrispondono a costanti con nomi in maiuscolo che iniziano con E, generalmente definiti nel file di intestazione . L'assenza di errori corrisponde a un valore di 0.

Quando si lavora con più thread, ognuno di essi deve avere una propria variabile errno. L'assegnazione di una variabile a ciascun thread avviene automaticamente, ma di solito ciò richiede un'indicazione al compilatore che dovrebbe esserci la possibilità di rientrare nel programma. Questo viene impostato usando –D_REENTRANT o –D_POSIX_C_SOURCE \u003d 199506L o chiavi equivalenti. Spesso nel titolo   errno viene definito come una macro espansa in una chiamata di funzione se viene definita la costante _REENTRANT. La funzione fornisce l'accesso a una copia di errno relativa a questo flusso.

Più avanti nel testo, usiamo espressioni come "la funzione mq_send restituisce EMSGSIZE", il che significa che la funzione restituisce un errore (di solito il valore restituito è -1) e imposta la variabile errno sul valore della costante specificata.

1.7. Standard Unix

Gli standard Unix sono attualmente definiti da Posix e The Open Group.

Posix

Il nome Posix deriva da "Portable Operating System Interface", che significa approssimativamente "interfaccia di sistema operativo portatile". Questo non è uno standard, ma un'intera famiglia sviluppata dall'Institute for Electrical and Electronics Engineers (IEEE). Gli standard Posix sono stati anche adottati come standard internazionali ISO (International Organization for Standardization, International Organization for Standardization) e IEC (International Electrotechnical Commission, International Electrotechnical Commission) o ISO / IEC. Gli standard Posix hanno attraversato diverse fasi di sviluppo.

■ Lo standard IEEE 1003.1-1988 (317 pagine) è stato il primo standard Posix. Ha definito l'interfaccia tra il linguaggio C e il kernel Unix nelle seguenti aree: primitive per l'implementazione di processi (fork, exec call, segnali e timer), ambiente di processo (ID utente, gruppi di processo), file e directory (tutte le funzioni I / O) , lavorare con il terminale, database di sistema (password e file di gruppo), formati di archivio tar e cpio.

NOTA

Il primo standard Posix è uscito in produzione con il nome IEEEIX nel 1986. Il nome Posix è stato proposto da Richard Stallman.

■ Poi è arrivato lo standard IEEE 1003.1-1990 (356 pagine). Era anche lo standard internazionale ISO / IEC 9945-1: 1990. Rispetto alla versione del 1988, le modifiche alla versione del 1990 erano minime. Il titolo è stato aggiunto: "Parte 1: System Application Program Interface (API)" ("Parte 1: System Programming Interface (API) [Language C])", e questo significa che lo standard ha descritto l'interfaccia di programmazione C (API) .

■ IEEE 1003.2-1992 è stato pubblicato in due volumi con un volume totale di circa 1300 pagine e il titolo conteneva la riga "Parte 2: Shell e utilità" (Parte 2: "Interprete e utilità"). Questa parte ha definito l'interprete (basato sulla shell Bourne in Unix System V) e circa un centinaio di utility (programmi solitamente chiamati dall'interprete - da awk e basename a vi e wass). In questo libro, faremo riferimento a questo standard sotto il nome di Posix. 2.

■ IEEE 1003.1b-1993 (590 pagine) era originariamente noto come IEEE P1003.4. Questo standard era un'aggiunta allo standard 1003.1-1990 e includeva estensioni in tempo reale sviluppate dal gruppo di lavoro P1003.4: sincronizzazione dei file, input-output asincrono, semafori, gestione della memoria, programmazione, clock, timer e code dei messaggi.

■ IEEE 1003.1, edizione 1996 (743 pagine), include 1003.1-1990 (API di base), 1003.1b-1993 (estensioni in tempo reale), 1003.1-1995 (Pthreads - Discussioni software Posix) e 1003.1i-1995 (modifiche tecniche a 1003.1b). Questo standard è anche chiamato ISO / IEC 9945-1: 1996. Sono stati aggiunti tre capitoli sui thread e sezioni aggiuntive sulla sincronizzazione dei thread (esclusioni reciproche e variabili condizionali), pianificazione dell'esecuzione dei thread e pianificazione della sincronizzazione. In questo libro, chiamiamo questo standard Posix.1.

NOTA

Più di un quarto delle 743 pagine dello standard era un'app intitolata "Razionale e note" ("Giustificazione e note"). Questa logica contiene informazioni storiche e una spiegazione dei motivi per cui alcune funzioni erano o non erano incluse nello standard. Spesso la logica non è meno utile dello standard stesso.

Sfortunatamente, gli standard IEEE non sono disponibili gratuitamente su Internet. Le informazioni su dove ordinare il libro sono fornite nella bibliografia sotto il link. Si noti che i semafori sono stati definiti nello standard per le estensioni in tempo reale, separati dalle mutue esclusioni e dalle variabili condizionali (che sono state definite nello standard Pthreads), il che spiega alcune delle differenze nelle API di questi strumenti.

Infine, si noti che i blocchi di lettura-scrittura non fanno parte degli standard Posix. Questo è descritto in maggior dettaglio nel capitolo 8.

In futuro prevediamo di rilasciare una nuova versione di IEEE 1003.1, che include lo standard P1003.1g, le interfacce di rete (socket e XTI), descritte nel primo volume di questo libro.

La prefazione Posix.1 del 1996 afferma che ISO / IEC 9945 è costituito dalle seguenti parti:

1. L'interfaccia di sistema per lo sviluppo di programmi (API) (linguaggio C).

2. Interprete e utilità.

3. Amministrazione del sistema (in sviluppo).

Le parti 1 e 2 sono quelle che chiamiamo Posix.1 e Posix.2.

Il lavoro sugli standard Posix è in corso e gli autori di libri ad essi correlati devono sparare a un bersaglio mobile. Lo stato attuale degli standard è disponibile all'indirizzo http://www.pasc.org/standing/sd11.html.

Il gruppo aperto

Open Group (Open Group) è stato costituito nel 1996 dall'unione di X / Open Company (fondata nel 1984) e Open Software Foundation (OSF, fondata nel 1988). Questo gruppo è un consorzio internazionale di produttori e consumatori dell'industria, del governo e delle istituzioni educative. I loro standard sono anche apparsi in diverse versioni:

■ Nel 1992 è stato pubblicato il quarto numero (Numero 4) e nel 1994 la sua seconda versione (Numero 4, Versione 2). Quest'ultimo è anche noto come Spec 1170, dove il numero magico 1170 è la somma del numero di interfacce di sistema (926), intestazioni (70) e comandi (174). Ci sono altri due nomi: X / Open Single Unix Specification e Unix 95.

■ Nel marzo 1997 è stata annunciata la seconda versione della specifica unificata Unix. Questo standard software è anche chiamato Unix 98, ed è così che ci riferiamo a questa specifica più avanti nel libro. Il numero di interfacce in Unix 98 è aumentato da 1170 a 1434, sebbene questo numero raggiunga 3030 per una workstation, poiché questo numero include CDE (Common Desktop Environment), che a sua volta richiede un sistema X Window e un utente Interfaccia a motivi. I dettagli sono scritti nel libro. Informazioni utili sono disponibili anche su http://www.UNIX-systems.org/version2.

NOTA

Da questo sito è possibile scaricare liberamente quasi interamente la specifica Unix unificata.

Versioni e portabilità Unix

Quasi tutte le versioni di Unix che potresti incontrare oggi corrispondono a qualsiasi versione dello standard Posix.1 o Posix.2. Diciamo "qualsiasi" perché dopo aver apportato modifiche a Posix (ad esempio, aggiungendo estensioni in tempo reale nel 1993 e flussi nel 1996), i produttori di solito hanno bisogno di un anno o due per personalizzare i loro programmi su questi standard.

Storicamente, la maggior parte dei sistemi Unix discendono da BSD o System V, ma le differenze tra loro vengono gradualmente cancellate man mano che i produttori passano all'utilizzo degli standard Posix. Le principali differenze si trovano nell'area dell'amministrazione del sistema, poiché attualmente non un singolo standard Posix descrive questa area.

Nella maggior parte degli esempi di questo libro, abbiamo usato i sistemi operativi Solaris 2.6 e Digital Unix 4.0B. Il fatto è che al momento della stesura del libro (fine 1997 - inizio 1998), solo questi due sistemi operativi supportavano thread software System V IPC, Posix IPC e Posix (Pthreads).

1.8. Commento su esempi IPC

Molto spesso, tre modelli (modelli) di interazione sono usati per illustrare varie funzioni in un libro:

1. File server: l'applicazione client-server e il client invia una richiesta al server con il nome del file e il server restituisce i suoi contenuti al client.

2. Produttore-consumatore: uno o più thread o processi (produttori) inseriscono i dati nel buffer pubblico e altri thread o processi (consumatori) eseguono varie operazioni con questi dati.

3. Aumentare il numero di sequenza: uno o più thread o processi aumentano l'indice comune a tutti. Questo numero può essere memorizzato in un file condiviso o in un'area di memoria condivisa.

Il primo esempio illustra varie forme di messaggistica, mentre gli altri due illustrano vari tipi di sincronizzazione e l'uso della memoria condivisa.

Le tabelle 1.5, 1.6 e 1.7 sono una sorta di guida ai programmi che sviluppiamo su vari argomenti delineati nel libro. Queste tabelle descrivono brevemente i programmi stessi e indicano i numeri dei rispettivi elenchi.

1.9. sommario

L'interazione con i processi è stata tradizionalmente una delle aree problematiche di Unix. Con lo sviluppo del sistema, sono state proposte varie soluzioni, nessuna delle quali perfetta. Dividiamo l'IPC in quattro tipi principali.

1. Messaggi (canali, FIFO, code di messaggi).

2. Sincronizzazione (esclusioni reciproche, variabili condizionali, blocchi di lettura / scrittura, semafori).

3. Memoria condivisa (senza nome e denominata).

4. Procedure di chiamata (porte di Solaris, RPC Sun).

Consideriamo l'interazione di entrambi i singoli thread di un processo e di diversi processi indipendenti.

La sopravvivenza di ciascun tipo di IPC è determinata dal processo, dal kernel o dal file system, a seconda della durata della sua esistenza. Quando si sceglie il tipo di IPC per una particolare applicazione, è necessario considerare la sua sopravvivenza.

Un'altra proprietà di ogni tipo di IPC è lo spazio dei nomi che definisce l'identificazione degli oggetti IPC da parte dei processi e dei thread che lo utilizzano. Alcuni oggetti non hanno nomi (canali, esclusioni reciproche, variabili condizionali, blocchi di lettura-scrittura), altri hanno nomi all'interno del file system (canali FIFO), altri sono caratterizzati da quelli che sono chiamati "nomi IPC Posix" nel capitolo 2 e quarto - un altro tipo di nome descritto nel capitolo 3 (chiavi IPC o identificatori di sistema V). In genere, un server crea un oggetto IPC con un nome e i client usano quel nome per accedere all'oggetto.

I codici sorgente forniti nel libro utilizzano le funzioni wrapper descritte nella Sezione 1.6 per ridurre la quantità di codice, fornendo comunque il controllo degli errori per qualsiasi funzione chiamata. I nomi di tutte le funzioni wrapper iniziano con una lettera maiuscola.

Gli standard IEEE Posix - Posix.1, che definisce le basi dell'interfaccia C su Unix, e Posix.2, che definisce i comandi di base, sono gli standard verso cui la maggior parte dei produttori si sta muovendo. Tuttavia, gli standard Posix vengono rapidamente assorbiti (inclusi come parte di) e ampliati dagli standard commerciali, in particolare The Open Group (Unix 98).

Tabella 1.5 Versioni del modello server client

messa in vendita	descrizione
4.1	Due canali tra i processi genitore e figlio
4.5	Utilizza popen e cat
4.6	Utilizza due canali FIFO tra i processi padre e figlio
4.7	Due canali FIFO tra un server indipendente e un client non correlato
4.10	Canali FIFO tra un server seriale indipendente e più client
4.12	Canale programma o FIFO: creazione di record in un flusso di byte
6.7	Due code di messaggi System V
6.12	Una coda di messaggi System V con più client
6.16	Una coda di messaggi System V per ciascun client; diversi clienti
15.15	Passando la maniglia attraverso la porta

Tabella 1.6 Versioni del modello produttore-consumatore

messa in vendita	descrizione
7.1	Mutua esclusione, diversi produttori, un consumatore
7.5	Esclusione reciproca e variabile condizionale, diversi produttori, un consumatore
10.8	Noto semafori Posix, un produttore, un consumatore
10.11	Semafori Posix in mente, un produttore, un consumatore
10.12	Posix semafori in memoria, diversi produttori, un consumatore
10.15	Semafori Posix in mente, diversi produttori, diversi consumatori
10.18	Semafori Posix in memoria, un produttore, un consumatore: più buffer

Tabella 1.7 Versioni del programma con numero progressivo crescente

messa in vendita	descrizione
9.1	Indice nel file, nessun blocco
9.3	Indice nel file, blocco con fcntl
9.9	Indice nel file, blocco mediante la funzione aperta
10.10	Indicizza in un file, blocca utilizzando un semaforo Posix denominato
12.2	Indice di memoria condivisa mmap, blocco mediante un semaforo Posix denominato
12.3	Indice in mmap di memoria condivisa, blocco mediante semaforo Posix in memoria
12.4	Indice nella memoria condivisa senza nome 4.4BSD, blocco mediante il semaforo Posix denominato
12.5	SVR4 / dev / zero indice di memoria condivisa, blocco mediante il semaforo Posix denominato
13.6	Posix indice di memoria condivisa, blocco tramite semaforo Posix in memoria
A.19	Misura delle prestazioni: blocco per esclusione reciproca tra thread
A.22	Misura delle prestazioni: blocco lettura / scrittura tra thread
A.23	Misura delle prestazioni: blocco tra i thread utilizzando i semafori Posix in memoria
A.25	Misura delle prestazioni: blocco tra i thread usando i semafori Posix
A.28	Misura delle prestazioni: blocco tra i thread utilizzando i semafori System V
A.29	Misura delle prestazioni: blocco tra thread usando fcntl
A.33	Misurazione delle prestazioni: blocco tra processi mediante eccezioni reciproche

esercizi

1. La Figura 1.1 mostra due processi che accedono a un singolo file. Se entrambi i processi aggiungono semplicemente i dati alla fine del file (possibilmente lungo), quale tipo di sincronizzazione sarà necessaria?

2. Esaminare il file di intestazione   sul tuo sistema e scopri come viene definito errno.

3. Completa la tabella. 1.3 le funzionalità utilizzate che sono supportate dai sistemi Unix.

CAPITOLO 2

2.1. introduzione

Dei tipi di IPC disponibili, i tre seguenti possono essere classificati come Posix IPC, ovvero metodi di comunicazione di processo conformi a Posix:

■ Code dei messaggi Posix (capitolo 5);

■ semafori Posix (capitolo 10);

■ Memoria condivisa Posix (capitolo 13).

Questi tre tipi di IPC hanno proprietà comuni e funzioni simili vengono utilizzate per lavorare con essi. In questo capitolo vengono illustrati i requisiti generali per i nomi di file completi utilizzati come identificatori, i flag specificati durante l'apertura o la creazione di oggetti IPC e le autorizzazioni di accesso.

Un elenco completo delle funzioni utilizzate per lavorare con questi tipi di IPC è riportato nella Tabella. 2.1.

Tabella 2.1 Posix IPC Features

	Code di messaggi	semafori	Memoria condivisa
File di intestazione
Funzioni per la creazione, l'apertura e l'eliminazione	mq_open mq_close mq_unlink	sem_open sem_close sem_unlink sem_init sem_destroy	shm_open shm_unlink
Operazioni di gestione	mq_getattr mq_setattr		ftruncate fstat
Operazioni IPC	mq_send mq_receive mq_notify	sem_wait sem_trywait sem_post sem_getvalue	mmap munmap

2.2. Nomi IPC

Nella tabella. 1.2 abbiamo notato che i tre tipi di standard Posix IPC hanno identificatori (nomi) che corrispondono a questo standard. Il nome IPC viene passato come primo argomento a una delle tre funzioni: mq_open, sem_open e shm_open e non deve corrispondere al file reale nel file system. Lo standard Posix.1 impone le seguenti restrizioni ai nomi IPC:

■ Il nome deve essere conforme ai requisiti esistenti per i nomi dei file (non superare i byte PATHMAX in lunghezza, incluso il carattere di terminazione con il codice 0).

■ Se il nome inizia con una barra (/), la chiamata a una di queste funzioni comporterà l'accesso alla stessa coda. In caso contrario, il risultato dipende dall'implementazione.

■ L'interpretazione di ulteriori barre in un nome dipende dall'implementazione.

Pertanto, per una migliore portabilità, i nomi dovrebbero iniziare con una barra (/) e non contenere altre barre. Sfortunatamente, queste regole, a loro volta, portano a problemi di portabilità.

Solaris 2.6 richiede una barra iniziale e non consente l'uso di barre aggiuntive. Per una coda di messaggi, ad esempio, vengono creati tre file nella directory / tmp e i nomi di questi file iniziano con .MQ. Ad esempio, se l'argomento della funzione mq_open ha il formato /queue.1234, i file creati avranno i nomi /tmp/.MQDqueue.1234, /tmp/.MQLqueue.1234 e /tmp/.MQPqueue.1234. Allo stesso tempo, su un sistema Digital Unix 4.0B, un file viene semplicemente creato con il nome specificato al momento della chiamata della funzione.

Il problema della portabilità si presenta quando si specifica un nome con una singola barra all'inizio: in questo caso, è necessario disporre dell'autorizzazione di scrittura per la directory principale. Ad esempio, una coda con il nome /tmp.1234 è accettabile dallo standard Posix e non causerà problemi sul sistema Solaris, ma Digital Unix non riuscirà a creare un file se non esiste l'autorizzazione alla scrittura nella directory principale del programma. Se specifichiamo il nome /tmp/test.1234, i problemi in Unix digitale e nei sistemi simili che creano un file con il nome specificato scompariranno (l'esistenza della directory / tmp e la presenza dell'autorizzazione del programma per scrivere su di esso, che è normale per la maggior parte dei sistemi Unix), tuttavia, l'utilizzo di Solaris non sarà possibile.

Per risolvere tali problemi di portabilità, è necessario definire il nome nell'intestazione utilizzando la direttiva #define per assicurarsi che possa essere facilmente modificato durante il trasferimento del programma su un altro sistema.

NOTA

Gli sviluppatori hanno cercato di consentire l'uso di code di messaggi, semafori e memoria condivisa per core Unix esistenti e in sistemi diskless indipendenti. Questo è il caso in cui lo standard è troppo generale e comporta problemi di portabilità. Per Posix, questo si chiama "come uno standard diventa non standard".

Lo standard Posix.1 definisce tre macro:

che accettano un singolo argomento: un puntatore a una struttura di tipo stat, i cui contenuti sono impostati dalle funzioni fstat, lstat e stat. Queste tre macro restituiscono un valore diverso da zero se l'oggetto IPC specificato (coda messaggi, semaforo o segmento di memoria condivisa) è implementato come un tipo speciale di file e la struttura stat fa riferimento a questo tipo. Altrimenti, la macro restituisce 0.

NOTA

Sfortunatamente, l'uso di queste macro non è sufficiente, perché non ci sono garanzie che questi tipi di IPC siano implementati come tipi separati di file. Ad esempio, in Solaris 2.6, tutte e tre le macro restituiscono sempre 0.

Tutte le altre macro utilizzate per verificare il tipo di file hanno nomi che iniziano con S_IS e accettano sempre un singolo argomento: il campo st_mode della struttura stat. Poiché le macro utilizzate per testare il tipo IPC accettano argomenti di un tipo diverso, i loro nomi iniziano con S_TYPEIS.

Funzione Px_ipc_name

C'è un'altra soluzione a questo problema di portabilità. Puoi definire la nostra funzione px_ipc_name, che aggiunge la directory richiesta come prefisso al nome IPC Posix.

char * px_ipc_name (const char * nome);

/ * Restituisce un puntatore in caso di successo, NULL in caso di errore * /

NOTA

Ecco come appaiono gli elenchi delle nostre funzioni, ovvero funzioni che non sono funzioni di sistema standard. In genere, è incluso il file di intestazione unpipc.h (Listato B.1).

argomento paté(nome) non deve contenere barre. Quindi, ad esempio, chiamando px_ipc_name ("test1") verrà restituito un puntatore alla linea / test1 in Solaris 2.6 o alla linea / tmp / test1 in Digital Unix 4.0B. La memoria per la stringa restituita viene allocata e liberata in modo dinamico chiamando free. È possibile impostare una variabile di ambiente arbitraria PX_IPC_NAME per impostare una directory predefinita diversa.

Il Listato 2.1 mostra la nostra implementazione di questa funzione.

NOTA

Forse è la prima volta che vedi la funzione snprintf in questo elenco. Una parte significativa dei programmi esistenti utilizza invece la funzione sprintf, ma quest'ultima non verifica la presenza di un overflow nel buffer di ricezione. Al contrario, snprintf prende la dimensione del buffer di ricezione come secondo argomento e successivamente ne impedisce l'overflow. Un hacker deliberato di buffer su un programma che utilizza sprintf è stato utilizzato dagli hacker per craccare i sistemi per molti anni.

La funzione snprintf non fa ancora parte dello standard ANSI C, ma è prevista per essere inclusa in uno standard aggiornato chiamato C9X. Tuttavia, molti produttori lo includono nella libreria standard C. Ovunque nel testo utilizziamo la funzione snprintf nella nostra versione, che fornisce una chiamata sprintf se la funzione snprinft non è nella libreria di sistema.

Listato 2.1. La funzione px_ipc_name nella nostra implementazione.

3 px_ipc_name (const char * name)

6 if ((dst \u003d malloc (PATN_MAX)) \u003d\u003d NULL)

8 / * è possibile impostare un nome di directory diverso utilizzando la variabile di ambiente * /

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

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

13 dir \u003d "/ tmp /"; / * impostazione predefinita * /

16 / * il nome della directory deve terminare con il carattere "/" * /

17 barra \u003d (dir \u003d\u003d "/")? "": "/";

18 snprintf (dst, PATH_MAX, "% s% s% s", dir, barra, nome);

19 ritorno (dst); / * per liberare questo puntatore, puoi chiamare free () * /

2.3. Crea e apri canali IPC

Tutte e tre le funzioni utilizzate per creare o aprire oggetti IPC: mq_open, sem_open e shm_open, accettano un flag speciale oflag  come secondo argomento. Definisce i parametri di apertura dell'oggetto richiesto allo stesso modo del secondo argomento della funzione open standard. Tutte le costanti da cui è possibile formare questo argomento sono riportate nella Tabella. 2.2.

Tabella 2.2 Costanti utilizzate durante la creazione e l'apertura di oggetti IPC

descrizione	mq_open	sem_open	shm_open
Sola lettura	O_RDONLY		O_RDONLY
Registra solo	O_WRONLY
Leggi e scrivi	O_RDWR		O_RDWR
Crea se non esiste	O_CREAT	O_CREAT	O_CREAT
Creazione esclusiva	O_EXCL	O_EXCL	O_EXCL
Nessuna serratura	O_NONBLOCK
Tronca esistente			O_TRUNC

Le prime tre righe descrivono il tipo di accesso all'oggetto creato: sola lettura, sola scrittura, lettura e scrittura. La coda dei messaggi può essere aperta in una delle tre modalità di accesso, mentre per un semaforo non è richiesta l'indicazione di queste costanti (per qualsiasi operazione con il semaforo, è richiesto l'accesso in lettura e scrittura). Infine, l'oggetto di memoria condivisa non può essere aperto solo per la scrittura.

Indicazione di altre bandiere dalla tabella. 2.2 è facoltativo.

O_CREAT - creazione di una coda di messaggi, semaforo o segmento di memoria condivisa, se non esiste già (vedere anche il flag O_EXCL, che influenza il risultato).

Quando si crea una nuova coda di messaggi, semaforo o segmento di memoria condivisa, è necessario almeno un argomento aggiuntivo che specifica la modalità. Questo argomento indica i bit di autorizzazione per accedere al file ed è formato dall'aggiunta logica bit a bit delle costanti dalla tabella. 2.3.

Tabella 2.3 Costanti della modalità di accesso durante la creazione di un nuovo oggetto IPC

Queste costanti sono definite nell'intestazione. . I bit di autorizzazione specificati vengono modificati sovrapponendo la maschera della modalità di creazione del file per il processo specificato (p. 83-85) o usando il comando umask interpreter.

Come per un file appena creato, durante la creazione di una coda di messaggi, semaforo o segmento di memoria condivisa, viene assegnato un identificativo utente corrispondente all'identificatore utente del processo effettivo. L'identificatore di un gruppo semaforo o di un segmento di memoria condivisa è impostato uguale all'identificatore del processo di gruppo corrente o all'identificatore di gruppo impostato per impostazione predefinita per il sistema nel suo insieme. L'identificatore di gruppo della coda messaggi è sempre impostato uguale all'identificatore di gruppo corrente del processo (p. 77-78 discute gli identificatori di gruppo e utente in modo più dettagliato).

NOTA

Sembra strano che ci sia una differenza nell'impostazione di un identificatore di gruppo per diversi tipi di Posix IPC. L'identificatore di gruppo del nuovo file creato utilizzando la funzione aperta è impostato sull'identificatore effettivo del gruppo di processi o sull'identificatore del gruppo di directory in cui viene creato il file, ma le funzioni IPC non possono presumere in anticipo che un file reale venga creato per l'oggetto IPC nel file system.

O_EXCL: se questo flag viene specificato contemporaneamente a O_CREAT, la funzione crea una nuova coda di messaggi, semaforo o oggetto di memoria condivisa solo se non esiste. Se l'oggetto esiste già e O_CREAT | O_EXCL, viene restituito un errore EEXIST.

La verifica dell'esistenza di una coda di messaggi, semaforo o segmento di memoria condivisa e la sua creazione (se assente) dovrebbe essere eseguita da un solo processo. Due flag simili sono disponibili in System V IPC, sono descritti nella sezione 3.4.

O_NONBLOCK - Questo flag crea una coda di messaggi senza bloccare. Un blocco è in genere impostato per leggere da una coda vuota o scrivere su una coda completa. Questo è descritto più dettagliatamente nelle sottosezioni sulle funzioni mq_send e mq_receive nella sezione 5.4.

O_TRUNC - se un segmento di memoria condivisa esistente è aperto per la lettura e la scrittura, questo flag indica la necessità di ridurne le dimensioni a 0.

In fig. La Figura 2.1 mostra la sequenza effettiva di operazioni logiche all'apertura di un oggetto IPC. Cosa si intende esattamente controllando le autorizzazioni di accesso è descritto nella sezione 2.4. Un altro approccio a quello mostrato in Fig. 2.1 è presentato in tabella. 2.4.

Fig. 2.1. Logica di apertura dell'oggetto IPC

Si noti che nella riga centrale della tabella. 2.4, dove è impostato solo il flag O_CREAT, non riceviamo alcuna informazione sul fatto che sia stato creato un nuovo oggetto o che ne sia stato aperto uno esistente.

Tabella 2.4 Logica di apertura dell'oggetto IPC

Argomento oflag	L'oggetto non esiste	L'oggetto esiste già
Nessuna bandiera speciale	Errore, errno \u003d ENOENT
O_CREAT	OK, viene creato un nuovo oggetto.	OK, si apre un oggetto esistente.
O_CREAT | O_EXCL	OK, viene creato un nuovo oggetto.	Errore, errno \u003d EEXIST

2.4. Autorizzazioni IPC

Una nuova coda di messaggi, un semaforo denominato o un segmento di memoria condivisa, viene creata dalle funzioni mq_open, sem_open e shm_open, a condizione che l'argomento oflag  contiene la costante O_CREAT. Secondo il tavolo. 2.3, a ciascuno di questi tipi di IPC vengono assegnate autorizzazioni specifiche, simili alle autorizzazioni dei file Unix.

Quando si apre una coda di messaggi, un semaforo o un segmento di memoria condivisa esistente con le stesse funzioni (nel caso in cui il flag O_CREAT non è specificato o O_CREAT è specificato senza O_EXCL e l'oggetto esiste già), viene eseguito il controllo delle autorizzazioni:

1. I bit di autorizzazione assegnati all'oggetto IPC al momento della creazione vengono controllati.

2. Viene controllato il tipo di accesso richiesto (O_RDONLY, O_WRONLY, O_RDWR).

3. Vengono verificati l'identificatore utente valido del processo chiamante, l'identificatore processo processo di gruppo valido e identificativi processo processo di gruppo aggiuntivi (quest'ultimo potrebbe non essere supportato).

La maggior parte dei sistemi Unix esegue i seguenti controlli specifici:

1. Se l'ID utente valido per il processo è 0 (utente privilegiato), l'accesso sarà consentito.

2. Se l'identificatore utente del processo valido corrisponde all'identificatore del proprietario dell'oggetto IPC: se è impostato il bit di autorizzazione corrispondente per l'utente, l'accesso è consentito, altrimenti l'accesso è negato.

Per bit di autorizzazione corrispondente, intendiamo, ad esempio, il bit di autorizzazione di lettura se il processo apre l'oggetto per sola lettura. Se un processo apre un oggetto per la scrittura, il bit di scrittura dell'utente deve essere impostato di conseguenza.

3. Se l'identificatore del gruppo di processi corrente o uno degli identificatori del gruppo di processi aggiuntivi corrisponde all'identificatore del gruppo di oggetti IPC: se viene impostato il bit di autorizzazione corrispondente per il gruppo, l'accesso sarà consentito, altrimenti l'accesso verrà negato.

4. Se è impostato il bit di autorizzazione di accesso corrispondente per altri utenti, l'accesso sarà consentito, altrimenti l'accesso verrà negato.

Questi quattro controlli vengono eseguiti in questo ordine. Pertanto, se il processo è il proprietario dell'oggetto IPC (passaggio 2), l'accesso è consentito o negato in base solo alle autorizzazioni dell'utente (proprietario). Le autorizzazioni di gruppo non sono controllate. Allo stesso modo, se il processo non possiede l'oggetto IPC, ma appartiene al gruppo desiderato, l'accesso è consentito o negato in base alle autorizzazioni del gruppo - le autorizzazioni per gli altri utenti non vengono verificate.

NOTA

Secondo il tavolo. 2.2, la funzione sem_open non utilizza i flag O_RDONLY, O_WRONLY, O_RDWR. La Sezione 10.2, tuttavia, dirà che alcune implementazioni di Unix implicano il flag O_RDWR, poiché qualsiasi accesso al semaforo comporta la lettura e la scrittura del suo valore.

2.5. sommario

I tre tipi di Posix IPC - code dei messaggi, semafori e memoria condivisa - sono identificati dal loro nome completo. Possono essere o meno nomi di file reali nel file system e ciò causa problemi di portabilità. La soluzione è utilizzare la funzione nativa px_ipc_name. Quando si crea o si apre un oggetto IPC, è necessario specificare un set di flag simili a quelli specificati quando si utilizza la funzione open. Quando si crea un nuovo oggetto IPC, è necessario specificare le autorizzazioni per esso utilizzando le stesse costanti S_xxx della funzione aperta (Tabella 2.3). Quando si apre un oggetto IPC esistente, le autorizzazioni di processo vengono verificate, in modo simile al controllo all'apertura di un file.

esercizi

1. In che modo i bit per l'impostazione dell'identificatore utente (set-user-ID, SUID) e l'impostazione dell'identificatore di gruppo (set-group-ID) (sezione 4.4) di un programma che utilizza Posix IPC influiscono sul controllo delle autorizzazioni descritto nella sezione 2.4?

2. Quando un programma apre un oggetto IPC, come può determinare se è stato creato un nuovo oggetto IPC o sta accedendo a un oggetto esistente?

CAPITOLO 3

3.1. introduzione

Dei tipi di IPC disponibili, i tre seguenti possono essere attribuiti a System V IPC, ovvero a elaborare metodi di interazione conformi allo standard System V:

■ Code dei messaggi di System V (capitolo 6);

■ semafori System V (capitolo 11);

■ Memoria condivisa System V (capitolo 14).

Il termine "System V IPC" si riferisce all'origine di questi strumenti: sono apparsi per la prima volta in Unix System V. Hanno molto in comune: funzioni simili sono usate per organizzare l'accesso agli oggetti; Inoltre, le forme di memorizzazione delle informazioni nel kernel sono simili. Questo capitolo descrive le funzionalità comuni ai tre tipi di IPC.

Le informazioni sulle funzioni sono riepilogate nella tabella. 3.1.

Tabella 3.1 Funzionalità IPC di System V

NOTA

Le informazioni sulla storia dello sviluppo e dello sviluppo delle funzionalità IPC di System V non sono troppo prontamente disponibili. fornisce le seguenti informazioni: code di messaggi, semafori e questo tipo di memoria condivisa sono stati sviluppati alla fine degli anni '70 presso una delle affiliate della Bell Laboratories a Columbus, Ohio, per una versione di Unix per uso interno. Questa versione si chiamava Columbus Unix o CB Unix. È stato utilizzato nei cosiddetti sistemi di supporto alle operazioni - sistemi di elaborazione delle transazioni - per automatizzare la gestione e la tenuta dei registri nella compagnia telefonica. Gli IPC di System V furono aggiunti alla versione commerciale di Unix System V. intorno al 1983.

3.2. Tasti di tipo key_t e ftok

Nella tabella. 1.2 è stato notato che i valori key_t sono stati utilizzati nei nomi dei tre tipi di System V IPC. File di intestazione   definisce il tipo key_t come numero intero (almeno 32 bit). I valori di variabili di questo tipo sono generalmente assegnati dalla funzione ftok.

La funzione ftok converte il nome completo completo e l'identificatore intero esistente in un valore di tipo key_t (chiamato chiave IPC):

key_t ftok (const char * nome percorso,  int id);

// Restituisce la chiave IPC o -1 se si verifica un errore

In effetti, la funzione utilizza il nome file completo e gli 8 bit inferiori dell'identificatore per formare la chiave intera IPC.

Questa funzione si basa sul presupposto che per una particolare applicazione che utilizza IPC, il client e il server utilizzano lo stesso nome oggetto IPC completo, che ha un significato nel contesto dell'applicazione. Questo può essere il nome del demone del server o il nome del file di dati utilizzato dal server o il nome di qualche altro oggetto del file system. Se il client e il server richiedono un solo canale IPC per la comunicazione, è possibile assegnare l'identificatore, ad esempio il valore 1. Se sono richiesti più canali IPC (ad esempio, uno dal server al client e uno nella direzione opposta), gli identificatori devono avere valori diversi: ad esempio, 1 e 2. Dopo che il client e il server hanno concordato il nome completo e l'identificatore, entrambi chiamano la funzione ftok per ottenere la stessa chiave IPC.

La maggior parte delle implementazioni di ftok chiama la funzione stat e quindi combina:

■ informazioni sul file system a cui si riferisce il nome completo percorso  (campo st_dev della struttura stat);

■ numero di nodo (i-node) nel file system (campo st_ino della struttura stat);

■ gli 8 bit inferiori dell'identificatore (che non dovrebbero essere zero).

Una combinazione di questi tre valori solitamente genera una chiave a 32 bit. Non vi è alcuna garanzia che per due percorsi diversi con lo stesso identificatore, saranno ottenute chiavi diverse, poiché il numero di bit di informazioni nei tre elementi elencati (identificativo del file system, numero di nodo, identificatore IPC) può superare il numero totale di bit (vedere Esercizio 3.5 ).

NOTA

Il numero di nodo è sempre diverso da zero, quindi la maggior parte delle implementazioni definisce la costante IPC_PRIVATE (sezione 3.4) come zero.

Se il nome completo specificato non esiste o non è accessibile al processo di chiamata, ftok restituisce -1. Ricorda che il file il cui nome viene utilizzato per calcolare la chiave non dovrebbe essere uno di quelli creati ed eliminati dal server durante il funzionamento, poiché ogni volta che li crei di nuovo, questi file ricevono, in generale, un diverso numero di nodo, e questo può cambiare la chiave restituito da Ftok alla chiamata successiva.

esempio

Il programma nel Listato 3.1 prende il nome completo come argomento dalla riga di comando, chiama le funzioni stat e ftok, quindi visualizza i campi st_dev e st_ino della struttura stat e la chiave IPC risultante. Questi tre valori vengono visualizzati in formato esadecimale, quindi è facile vedere esattamente come si forma la chiave IPC da questi due valori e l'identificatore 0x57.

Listato 3.1. Ricezione e output di informazioni sui file e chiave IPC generata

7 err_quit ("use: ftok ");

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

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

L'esecuzione di questo programma su un sistema Solaris 2.6 produrrà i seguenti risultati:

solaris% ftok / etc / system

st_dev: 800018, st_ino: 4a1b, chiave: 57018a1b

solaris% ftok / usr / tmp

st_dev: 800015, st_ino: 10b78, chiave: 57015b78

solaris% ftok /home/rstevens/Mail.out

st_dev: 80001f, st_ino: 3b03, chiave: 5702fb03

Ovviamente, l'identificatore identifica gli 8 bit alti della chiave; i 12 bit inferiori di st_dev definiscono i successivi 12 bit della chiave e, infine, i 12 bit inferiori di st_ino determinano i 12 bit inferiori della chiave.

Lo scopo di questo esempio non è successivamente fare affidamento su tale metodo per generare una chiave dalle informazioni elencate, ma illustrare l'algoritmo per combinare il nome completo e l'identificatore con un'implementazione specifica. In altre implementazioni, l'algoritmo potrebbe essere diverso.

NOTA

FreeBSD usa gli 8 bit inferiori dell'identificatore, gli 8 bit inferiori di st_dev e i 16 bit inferiori di st_ino.

Si noti che la mappatura prodotta dalla funzione ftok è a senso unico perché parte dei bit st_dev e st_ino non vengono utilizzati. Questa chiave non può determinare il nome file completo specificato per i calcoli.

3.3. Struttura Ipc_perm

Per ogni oggetto IPC, come per un normale file, un insieme di informazioni è memorizzato nel kernel in una struttura.

  uid_t uid; / * ID utente proprietario * /

  gid_t gid / * identificativo del gruppo proprietario * /

  uid_t cuid; / * ID utente creatore * /

  gid_t cgid; / * identificatore del gruppo creatore * /

  mode_t mode; / * permessi di lettura / scrittura * /

  ulong_t seq; / * numero di serie del canale * /

key_t key; / * Chiave IPC * /

Questa struttura, insieme ad altre costanti rinominate per le funzioni IPC di System V, è definita nel file . In questo capitolo, descriveremo i campi della struttura ipc_perm in modo più dettagliato.

3.4. Crea e apri canali IPC

Le tre funzioni getXXX utilizzate per creare o aprire oggetti IPC (Tabella 3.1) accettano una chiave IPC (di tipo key_t) come uno degli argomenti e restituiscono un identificatore intero. Questo identificatore è diverso da quello passato alla funzione ftok, come vedremo tra poco. Un'applicazione ha due opzioni per specificare una chiave (il primo argomento per ottenere le funzioniXXXX):

1. Chiama ftok, dagli il nome completo e l'identificatore.

2. Specificare la costante IPCPRIVATE come chiave, che garantisce la creazione di un nuovo oggetto IPC univoco.

La sequenza di azioni è illustrata in Fig. 3.1.

Fig. 3.1. Calcolo degli identificatori IPC per chiave

Tutte e tre le funzioni getXXX (Tabella 3.1) accettano un set di flag come secondo argomento oflag,  specificando i bit di autorizzazione in lettura e scrittura (campo mode della struttura ipc_perm) per l'oggetto IPC e determinando se viene creato un nuovo oggetto IPC o se ne accede uno esistente. Ci sono le seguenti regole per questo.

■ La chiave IPC_PRIVATE garantisce la creazione di un oggetto IPC univoco. Nessuna possibile combinazione del nome completo e dell'identificatore può far sì che la funzione ftok restituisca IPC_PRIVATE come chiave.

■ Impostazione del bit dell'argomento IPC_CREAT oflag  porta alla creazione di un nuovo record per la chiave specificata, se non esiste già. Se viene trovato un record esistente, viene restituito il suo identificatore.

Impostazione simultanea dei bit dell'argomento IPC_CREAT e IPC_EXCL oflagporta alla creazione di un nuovo record per la chiave specificata solo se tale record non esiste ancora. Se viene trovato un record esistente, la funzione restituisce un errore EEXIST (esiste già un oggetto IPC).

La combinazione di IPC_CREAT e IPC_EXCL per oggetti IPC agisce in modo simile alla combinazione di O_CREAT e O_EXCL per la funzione aperta.

L'impostazione del solo bit IPC_EXCL senza IPC_CREAT non ha alcun effetto.

Il diagramma logico della sequenza di azioni all'apertura dell'oggetto IPC è mostrato in Fig. 3.2. Nella tabella. 3.2 mostra una visione alternativa di questo processo.

Fig. 3.2. Diagramma di apertura dell'oggetto IPC

Si noti che nella riga centrale della tabella. 3.2 per il flag IPC_CREAT senza IPC_EXCL, non riceviamo alcuna informazione sulla creazione di un nuovo oggetto o sull'accesso a uno esistente. Per la maggior parte delle applicazioni, è tipico per il server creare un oggetto IPC con IPC_CREAT (se non fa alcuna differenza se l'oggetto esiste già) o IPC_CREAT | IPC_EXCL (se è richiesta la verifica dell'esistenza dell'oggetto). Il client non indica affatto flag, supponendo che il server abbia già creato l'oggetto.

NOTA

Le funzioni IPC di System V, diversamente dalle funzioni IPC di Posix, definiscono le proprie costanti IPC_xxx invece di utilizzare O_CREAT e OEXCL accettate dalla funzione open standard (Tabella 2.2).

Si noti inoltre che le funzioni IPC di System V combinano le costanti IPC_xxx con i bit di autorizzazione (descritti nella sezione successiva) in un singolo argomento oflag, mentre la funzione open e la funzione IPC Posix sono caratterizzate da due argomenti: oflag, in cui sono impostati i flag del modulo O_xxx e mode, che definisce i bit di autorizzazione di accesso.

Tabella 3.2 La logica di creazione e apertura di oggetti IPC

Argomento oflag	La chiave non esiste	La chiave esiste
Nessuna bandiera speciale impostata	Errore, errno \u003d ENOENT	OK, aprendo un oggetto esistente
IPC_CREAT	OK, viene creato un nuovo record.	OK, aprendo uno esistente
IPC CREAT | IPC_EXCL	OK, viene creato un nuovo record.	Errore, errno \u003d EEXIST

3.5. Autorizzazioni IPC

Quando si crea un nuovo oggetto IPC utilizzando una delle funzioni getXXX chiamate con il flag IPC_CREAT, le seguenti informazioni vengono inserite nella struttura ipc_perm (sezione 3.3):

1. Parte dei bit dell'argomento oflag  imposta il valore del campo mode della struttura ipc_perm. Nella tabella. La Figura 3.3 mostra i bit di autorizzazione per i tre tipi di IPC (scrivere \u003e\u003e 3 significa spostarsi a destra di tre bit).

2. I campi cuid e cgid ricevono valori uguali agli identificativi validi dell'utente e del gruppo del processo chiamante. Questi due campi sono chiamati identificatori del creatore.

3. Anche i campi uid e gid della struttura ipc_perm sono impostati uguali agli identificatori effettivi del processo chiamante. Questi due campi sono chiamati identificatori del proprietario.

Tabella 3.3 Valori della modalità per le autorizzazioni di lettura / scrittura IPC

Numero (ottale)	Coda messaggi	semaforo	Memoria condivisa	descrizione
0400	MSG_R	SEM_R	SHM_R	Lettura utente
0200	MSG_W	SEM_A	SHM_W	Utente - Record
0040	MSG R \u003e\u003e 3	SEM_R \u003e\u003e 3	SHM_R \u003e\u003e 3	Gruppo - Lettura
0020	MSG_W \u003e\u003e 3	SEM_A \u003e\u003e 3	SHM_W \u003e\u003e 3	Record di gruppo
0004	MSG_R \u003e\u003e 6	SEM_R \u003e\u003e 6	SHM_R \u003e\u003e 6	Altri: lettura
0002	MSG_W \u003e\u003e 6	SEM_A \u003e\u003e 6	SHM_W \u003e\u003e 6	Altri - registra

L'identificatore del creatore non può essere modificato, mentre l'identificatore del proprietario può essere modificato dal processo chiamando la funzione ctlXXX per questo meccanismo IPC con il comando IPC_SET. Tre funzioni ctlXXX consentono al processo di modificare i bit di autorizzazione di accesso (campo modalità) dell'oggetto IPC.

NOTA

Nella maggior parte delle implementazioni, sono definite sei costanti: MSG_R, MSG_W, SEM_R, SEM_A, SHM_R e SHM_W, mostrate nella tabella. 3.3. Queste costanti sono definite nei file di intestazione. ,   e . Tuttavia, lo standard Unix 98 non li richiede. Il suffisso A in SEM_A significa "alter" (modifica).

Le tre funzioni getXXX non usano la maschera standard di creazione di file Unix. Le autorizzazioni della coda messaggi, del semaforo e della memoria condivisa sono impostate esattamente uguali all'argomento della funzione.

Posix IPC impedisce al creatore di IPC di modificare la proprietà di un oggetto. Posix non ha analoghi per il comando IPC_SET. Tuttavia, in Posix IPC, il nome dell'oggetto appartiene al file system e quindi il proprietario può essere modificato come utente privilegiato usando il comando chown.

Quando un processo tenta di accedere all'oggetto IPC, viene eseguito un controllo in due passaggi: la prima volta che si apre il file (funzione getXXX) e quindi ogni volta che si accede all'oggetto IPC:

1. Quando si stabilisce l'accesso a un oggetto IPC esistente utilizzando una delle funzioni getXXX, l'argomento viene inizialmente verificato oflag,  processo di chiamata di funzione. L'argomento non dovrebbe indicare i bit di accesso che non sono impostati nel campo mode della struttura ipc_perm (il quadrato inferiore in Fig. 3.2). Ad esempio, un processo server può impostare il valore del membro mode per la coda dei messaggi in arrivo reimpostando i bit di lettura per il gruppo e altri utenti. Qualsiasi processo che tenti di specificare questi bit in un argomento oflag  funzione msgget, verrà visualizzato un errore. Va notato che questo controllo prodotto dalle funzioni getXXX è di scarsa utilità. Implica che il processo chiamante abbia informazioni su quale gruppo di utenti appartiene: potrebbe essere il proprietario del file, potrebbe appartenere allo stesso gruppo o ad altri utenti. Se il processo di creazione ripristina alcuni bit di autorizzazione e il processo di chiamata tenta di impostarli, la funzione getXXX restituirà un errore. Qualsiasi processo può saltare completamente questo controllo specificando un argomento oflag,  uguale a 0 se l'esistenza di un oggetto IPC è nota in anticipo.

2. Per qualsiasi operazione con oggetti IPC, le autorizzazioni vengono verificate per il processo che richiede questa operazione. Ad esempio, ogni volta che un processo tenta di mettere in coda un messaggio utilizzando il comando msgsnd, vengono eseguiti i seguenti controlli (i passaggi successivi vengono saltati quando si ottiene l'accesso).

□ L'utente privilegiato ha sempre accesso.

□ Se l'ID utente valido corrisponde all'uid o al cuid dell'oggetto IPC e il bit di autorizzazione di accesso corrispondente è impostato sul campo modalità dell'oggetto IPC, l'accesso sarà consentito. Per bit di autorizzazione di accesso corrispondente si intende un bit che consente la lettura se il processo di chiamata richiede un'operazione di lettura per questo oggetto IPC (ad esempio, la ricezione di un messaggio dalla coda) o un bit che consente la scrittura se il processo lo desidera eseguire.

□ Se l'identificatore di gruppo valido corrisponde al valore gid o cgid dell'oggetto IPC e il bit di autorizzazione di accesso corrispondente è impostato nel campo modalità dell'oggetto IPC, l'accesso sarà consentito.

□ Se l'accesso non era consentito nei passaggi precedenti, viene verificata la presenza dei bit di accesso impostati corrispondenti per altri utenti.

3.6. Riutilizzo ID

La struttura ipc_perm (sezione 3.3) contiene la variabile seq, che memorizza il numero seriale del canale. Questa variabile è il contatore che il kernel avvia per ogni oggetto IPC nel sistema. Quando un oggetto IPC viene eliminato, il numero del canale aumenta e quando trabocca, viene ripristinato a zero.

NOTA

In questa sezione, descriviamo l'implementazione specifica di SVR4. Lo standard Unix 98 non esclude l'uso di altre opzioni.

È necessario un contatore per due motivi. Innanzitutto, ricordare i descrittori di file memorizzati nel kernel per ciascuno dei file aperti. Di solito sono piccoli numeri interi che contano solo all'interno di un singolo processo: ogni processo ha i suoi descrittori. La lettura da un file con il descrittore 4 è possibile solo nel processo in cui è presente un file aperto con tale descrittore. Non importa se ci sono file aperti con lo stesso descrittore in altri processi. A differenza dei descrittori di file, gli identificatori IPC di System V sono impostati per l'intero sistema, non per il processo.

L'identificatore IPC viene restituito da una delle funzioni getXXX: msgget, semget, shmget. Come i descrittori di file, gli identificatori sono numeri interi che, a differenza dei descrittori, hanno lo stesso valore per tutti i processi. Se due processi non correlati (client e server) utilizzano la stessa coda di messaggi, il suo identificativo restituito dalla funzione msgget deve avere lo stesso valore intero in entrambi i processi affinché possano accedere alla stessa coda. Questa funzione consente a qualsiasi processo creato da un utente malintenzionato di provare a leggere un messaggio da una coda creata da un'altra applicazione, ordinando in sequenza vari identificatori (se fossero numeri interi piccoli) e sperando che l'esistenza di una coda che sia attualmente aperta e accessibile a tutti. . Se gli identificatori fossero piccoli numeri interi (come i descrittori di file), la probabilità di trovare l'identificatore corretto sarebbe di circa 1/50 (presupponendo un limite di 50 descrittori di processo).

Per eliminare questa possibilità, gli sviluppatori di strumenti IPC hanno deciso di ampliare il possibile intervallo di valori identificativi in \u200b\u200bmodo che includa tutti gli interi in generale, e non solo quelli piccoli. L'estensione dell'intervallo viene fornita aumentando il valore dell'identificatore restituito al processo di chiamata dal numero di voci nella tabella di sistema IPC ogni volta che una di esse viene riutilizzata. Ad esempio, se il sistema è configurato per utilizzare non più di 50 code di messaggi, l'identificatore 0 verrà restituito al processo quando il primo record viene utilizzato per la prima volta. Dopo aver eliminato questa coda di messaggi, quando si tenta di riutilizzare il primo record nella tabella, verrà restituito l'identificatore 50, quindi verranno restituiti i valori 100, 150, ecc. Dato che seq è generalmente definito come un intero lungo senza segno (ulong - vedere la struttura ipc_perm nella sezione 3.3), un ritorno agli identificatori già utilizzati si verifica quando si utilizza la voce della tabella chiamato 85899346 volte (2³² / 50 supponendo che l'intero sia a 32 bit).

Il secondo motivo necessario per inserire il numero seriale del canale è la necessità di eliminare il riutilizzo degli identificatori IPC di System V dopo breve tempo. Questo aiuta a garantire che il server che è stato terminato prematuramente e successivamente riavviato non utilizza lo stesso identificatore.

Per illustrare questa funzione, il programma nel Listato 3.2 mostra i primi dieci valori identificativi restituiti da msgget.

Listato 3.2. Identificatore della coda messaggi emesso dieci volte di seguito

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

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

9 Msgctl (msqid, IPC_RMID, NULL);

Al successivo passaggio del ciclo, msgget crea una coda di messaggi e msgctl con il comando IPC_RMID come argomento lo elimina. La costante SVMSG_MODE è definita nel nostro file di intestazione unpipc.h (Listato B.1) e imposta le autorizzazioni predefinite per la coda dei messaggi di System V. L'output del programma sarà simile al seguente:

Quando riavvierai il programma, vedremo una chiara illustrazione del fatto che il numero seriale del canale è una variabile che è memorizzata nel kernel e continua ad esistere anche dopo il completamento del processo.

3.7. Programmi Ipcs e ipcrm

Poiché gli oggetti IPC di System V non sono associati ai nomi nel file system, non è possibile visualizzare il loro elenco o eliminarli utilizzando i programmi ls e rm standard. Invece, sui sistemi che supportano questi tipi di IPC, vengono forniti due programmi speciali: ipcs, che visualizza varie informazioni sulle proprietà di System V IPC e ipcrm, che rimuove la coda di messaggi System V, il semaforo o il segmento di memoria condivisa. La prima di queste funzioni supporta circa una dozzina di opzioni della riga di comando che controllano la visualizzazione di informazioni sui vari tipi di IPC. Il secondo (ipcrm) può specificare fino a sei parametri. Informazioni dettagliate su di essi possono essere ottenute nel sistema di aiuto.

NOTA

Poiché System V IPC non è standardizzato da Posix, questi comandi non fanno parte di Posix.2. Sono descritti nello standard Unix 98.

3.8. Limitazioni del kernel

La maggior parte delle implementazioni IPC di System V sono caratterizzate da vincoli interni del kernel. Questo, ad esempio, è il numero massimo di code di messaggi o il limite del numero massimo di semafori in un set. I valori caratteristici di queste restrizioni sono riportati nella tabella. 6.2, 11.1 e 14.1. La maggior parte delle restrizioni sono ereditate dall'implementazione originale del Sistema V.

NOTA

La sezione 11.2 del libro e il capitolo 8 descrivono l'implementazione di code di messaggi, semafori e memoria condivisa nel sistema V. Alcune di queste limitazioni sono già descritte lì.

Sfortunatamente, alcune delle restrizioni imposte sono piuttosto severe, poiché sono ereditate dall'implementazione originale, che era basata su un sistema con un piccolo spazio di indirizzi (PDP-11 a 16 bit). Fortunatamente, la maggior parte dei sistemi consente a un amministratore di modificare alcune delle restrizioni predefinite, ma i passaggi richiesti sono specifici per ciascuna versione di Unix. Nella maggior parte dei casi, è necessario riavviare il kernel dopo aver apportato le modifiche. Sfortunatamente, alcune implementazioni usano ancora numeri interi a 16 bit per memorizzare alcuni parametri, e questo già imposta limiti hardware.

In Solaris 2.6, ad esempio, ci sono 20 di tali restrizioni: i loro valori attuali possono essere visualizzati usando il comando sysdef. Si noti che invece di valori reali, gli zeri verranno visualizzati se il modulo del kernel corrispondente non viene caricato (ovvero, lo strumento non è stato precedentemente utilizzato). Questo può essere eliminato aggiungendo una delle seguenti istruzioni al file / etc / system. Il file / etc / system viene letto durante il riavvio del sistema:

imposta msgsys: msginfo_msgseg \u003d valore

imposta msgsys: msginfo_msgssz \u003d valore

imposta msgsys: msginfo_msgtql \u003d valore

imposta msgsys: msginfo_msgmap \u003d valore

imposta msgsys: msginfo_msgmax \u003d valore

imposta msgsys: msginfo_msgmnb \u003d valore

imposta msgsys: msginfo_msgmni \u003d valore

imposta semsys: seminfo_semopm \u003d valore

imposta semsys: seminfo_semume \u003d valore

imposta semsys: seminfo_semaem \u003d valore

imposta semsys: seminfo_semmap \u003d valore

imposta semsys: seminfo_semvmx \u003d valore

imposta semsys: seminfo_semmsl \u003d valore

imposta semsys: seminfo_semmni \u003d valore

imposta semsys: seminfo_semmns \u003d valore

imposta semsys: seminfo_semmnu \u003d valore

imposta shmsys: shminfo_shmmin \u003d valore

imposta shmsys: shminfo_shmseg \u003d valore

imposta shmsys: shminfo_shmmax \u003d valore

set shmsys: shminfo_shmmni \u003d valore

Gli ultimi sei caratteri del nome a sinistra del segno di uguale sono le variabili elencate nella Tabella. 6.2, 11.1 e 14.1.

In Digital Unix 4.0B, sysconfig ti consente di conoscere o modificare molti parametri e limitazioni del kernel. Di seguito è riportato l'output di questo comando, avviato con l'opzione –q. Il comando visualizza le restrizioni correnti per il sottosistema ipc. Alcune righe nell'output non correlate agli strumenti IPC System V sono state omesse:

alfa% / sbin / sysconfig –q ipc

È possibile specificare altri valori predefiniti per queste opzioni modificando il file / etc / sysconfigtab. Questo dovrebbe essere fatto usando il programma sysconfigdb. Questo file viene letto anche durante il processo di avvio del sistema.

3.9. sommario

Il primo argomento delle funzioni msgget, semget e shmget è il tasto IPC System V. Questi tasti sono calcolati dal nome file completo usando la funzione di sistema ftok. La chiave può anche essere impostata su IPCPRIVATE. Queste tre funzioni creano un nuovo oggetto IPC o ne aprono uno esistente e restituiscono l'identificatore IPC di System V, un numero intero che viene quindi utilizzato per riconoscere l'oggetto in altre funzioni correlate a IPC. Questi identificatori hanno senso non solo nell'ambito di un processo (come i descrittori di file), ma anche nell'intero sistema. Possono essere riutilizzati dal core, ma solo dopo un po 'di tempo.

Una struttura ipc_perm è associata a ciascun oggetto IPC di System V, che contiene informazioni al riguardo, come ID utente del proprietario, ID gruppo, autorizzazioni di lettura e scrittura, ecc. Una delle differenze tra System V e Posix IPC è quella per l'oggetto IPC di System V le informazioni sono sempre disponibili (l'accesso ad esse può essere ottenuto utilizzando una delle funzioni XXXctl con l'argomento IPC_STAT) e in Posix l'accesso IPC dipende dall'implementazione. Se l'oggetto Posix IPC è memorizzato nel file system e ne conosciamo il nome, possiamo accedere a queste informazioni utilizzando gli strumenti standard del file system.

Quando si crea un nuovo o si apre un oggetto IPC di System V esistente, getXXX passa due flag (IPC_CREAT e IPC_EXCL) e 9 bit di autorizzazioni.

Senza dubbio, il problema principale nell'uso di System V IPC sono i limiti artificiali nella maggior parte delle implementazioni. Le limitazioni sono imposte alla dimensione degli oggetti e provengono dalle prime implementazioni. Ciò significa che un uso intensivo delle applicazioni IPC di System V richiede una modifica delle restrizioni del kernel e queste modifiche vengono apportate in modo diverso in ciascun sistema.

esercizi

1. Leggi la funzione msgctl nella sezione 6.5 e modifica il programma nel Listato 3.2 in modo che sia visualizzato non solo l'identificatore, ma anche il campo seq della struttura ipc_perm.

2. Immediatamente dopo aver eseguito il Listato 3.2, eseguiamo un programma che crea due code di messaggi. Supponendo che nessun'altra applicazione abbia utilizzato le code dei messaggi dall'avvio del sistema, determinare quali valori verranno restituiti da msgget come identificatori della coda dei messaggi.

3. Nella sezione 3.5, è stato osservato che le funzioni getXXX System V IPC non utilizzano la maschera di creazione del file. Scrivi un programma di test che crea il canale FIFO (usando la funzione mkfifo descritta nella Sezione 4.6) e la coda dei messaggi di System V, specificando sia la risoluzione 666 (in formato ottale). Confronta le autorizzazioni per gli oggetti creati (FIFO e code di messaggi). Prima di avviare il programma, assicurarsi che il valore di umask sia diverso da zero.

4. Il server deve creare una coda messaggi unica per i suoi client. Quale è preferibile: utilizzare un nome file costante (ad esempio, nome server) come argomento per la funzione ftok o utilizzare la chiave IPC_PRIVATE?

5. Modificare il Listato 3.1 in modo da visualizzare solo la chiave IPC e il percorso del file. Esegui il programma find per elencare tutti i file nel tuo file system e passare l'output al tuo programma appena creato. A quanti nomi di file corrisponderà la stessa chiave?

6. Se il sistema ha un programma sar (reporter attività di sistema - informazioni sull'attività del sistema), eseguire il comando

Sullo schermo verrà visualizzato il numero di operazioni al secondo con code di messaggi e semafori misurate ogni 5 secondi 6 volte.

Osservazioni:

L'IPC è un concetto correlato, ma ha senso capire di cosa si tratta in modo più dettagliato.

contenuto:

Pagina teorica

Tutti almeno immaginano il lavoro di un normale sistema operativo.

Ora immagina che il lavoro del nostro sistema operativo che ci è familiare si è trasformato nel suo doppio malvagio, che non solo non sembra originale, ma adempie anche a tutti i suoi doveri.

Un simile sviluppo sarebbe potuto accadere se non fosse stato integrato nel nostro sistema IPC.

Se studi bene la questione della dipendenza dei programmi l'uno dall'altro, puoi capire che ci sono parecchie applicazioni che non dipendono l'una dall'altra.

Questo è abbastanza logico, poiché per un elevato coefficiente di funzionamento di qualsiasi sistema è semplicemente necessario tra i componenti.

Ad esempio, quando una persona ha una domanda nel suo lavoro che dipende dal suo lavoro, prende le informazioni di cui ha bisogno da una fonte, sia essa una persona o qualsiasi altra fonte.

Sebbene il "nucleo" del nostro computer sia la ricerca di informazioni in una fonte specifica, il principio dei robot è essenzialmente lo stesso.

Principio di funzionamento

Per il corretto funzionamento del sistema, le applicazioni necessitano necessariamente di una comunicazione ininterrotta tra, o devono esse stesse fornire le informazioni necessarie su richiesta dei processi.

È proprio a causa di questa necessità di uno scambio costante di informazioni con le applicazioni che un certo numero di meccanismi sono integrati nel sistema operativo che sono responsabili del mantenimento di un flusso di informazioni costante e privo di errori.

Tali meccanismi o programmi sono chiamati "comunicazione tra processi" - con traduzione Inter-process Communication (IPC).

È importante:  IPC è un meccanismo o un programma che fornisce uno scambio reciproco stabile di dati tra i flussi / processori di informazioni di processo.

Questo programma funziona direttamente nel sistema operativo stesso ed è la base per il trasferimento di qualsiasi informazione.

Esempi IPC

Anche prima dello sviluppo delle tecnologie di rete, è emersa la questione della necessità di trasferire informazioni da un processore a un processore in esecuzione su un singolo computer.

Ci sono solo un numero enorme di esempi in cui questo programma è stato usato in meccanismi abbastanza primitivi, per oggi.

Considera uno degli esempi chiave che illustra chiaramente l'importanza dell'IPC anche nei sistemi molto semplici e precoci, per non parlare oggi delle sue esigenze.

Versioni precedenti di IPC moderno erano presenti in MS-DOS.

Nel processo di sviluppo tecnologico, quando le tecnologie e i sistemi di rete stavano appena iniziando il loro lungo percorso di sviluppo, è emersa la necessità di meccanismi per la creazione di processori interconnessi che sono implementati in un'unica rete.

A quel tempo, risolvere questo problema era molto problematico.

Il fatto è che tale connessione potrebbe scambiare dati, se solo le loro piattaforme o sistemi operativi appartenessero agli stessi modelli.

In una rete moderna, questi problemi non disturbano nessuno da molto tempo.  Ecco un breve esempio illustrativo di come lavorare in tali reti.

Questi processi vengono eseguiti su due computer diversi, in due posti diversi:

• il browser sul tuo sistema
• server - in qualsiasi altro sistema o assolutamente ovunque.

E non ti chiedi affatto che tipo di server sia il sistema operativo.

Toccando il principio generale di funzionamento di tali moduli come IPC, e non solo come esso, viene utilizzato principalmente il concetto client-server.

È chiaro che il "client" è un'applicazione che richiede informazioni e che la richiesta di informazioni va già al "server", un'applicazione che fornisce le informazioni necessarie.

Posizione generale

Avendo considerato tutte le possibilità e gli esempi dell'utilizzo dell'interazione tra processori, tu stesso puoi assicurarti che questo software sia semplicemente necessario per il sistema operativo con cui siamo abituati a lavorare.

Le aree di interazione IPC saranno elencate di seguito, sia in un sistema che in una rete multiutente.

Oggi, i requisiti per i sistemi operativi stanno aumentando in proporzione al livello di tecnologia.

Questa crescita è causata dal fatto che ogni giorno sempre più componenti aggiuntivi arrivano ai nostri sistemi operativi, che a loro volta migliorano le caratteristiche del nostro computer.

Ma poche persone sanno che i moderni sistemi operativi che supportano dovrebbero avere tali programmi o meccanismi che garantiscono la sincronizzazione dei processori senza esclusioni reciproche e con ritardi minimi.

Questi criteri sono molto importanti nel funzionamento del nostro computer.

Se parliamo di un sistema multi-tasking ideale, allora tutti i processi in esecuzione in esso dovrebbero essere indipendenti l'uno dall'altro, cioè essere asincroni.

In realtà, un tale sistema "ideale" è impossibile, poiché prima o poi sorgono situazioni in cui i processi hanno bisogno di accedere ad alcune risorse comuni.

Per ottenere questa opportunità, sono disponibili risorse speciali a livello del sistema operativo che offrono loro questa opportunità.

Ma qui, ovviamente, non senza eccezioni.  L'esecuzione di processi paralleli può causare problemi.

Per esempio:  quando si lavora insieme, ogni processo che accede ai dati condivisi rende impossibile l'accesso simultaneo a tutti gli altri processi - questo fenomeno è chiamato esclusione reciproca.

Tre tipi principali di IPC

• locale

Questo tipo di IPC è completamente legato al tuo computer; il lavoro viene eseguito solo all'interno di un sistema (computer).

È il principale e obbligatorio per il lavoro dei processi che forniscono il trasferimento di dati attraverso il sistema, in particolare per canali, code di messaggi e memoria condivisa.

A causa delle sue limitazioni in termini di spazio di comunicazione, i dati IPC possono funzionare solo entro i propri limiti.

Ma grazie a questa limitazione, è possibile utilizzare interfacce più veloci e semplici.

• remoto

Per garantire l'interazione all'interno del sistema con un processore o tra programmi su processori diversi collegati attraverso una rete, vengono utilizzati meccanismi speciali che forniscono IPC remoto.

• Alto livello

L'ultimo e, forse, uno dei più difficili da usare IPC è quello di alto livello.

Questa vista è un pacchetto software.

Questo pacchetto di dati crea il cosiddetto "livello intermedio", che offre la possibilità di comunicare tra la piattaforma di sistema e l'applicazione.

Garantire il corretto funzionamento dello scambio di dati

Insieme alla sua funzione principale, garantendo interazioni tra processori, gli strumenti ICP sono collegati alla risoluzione dei problemi che sorgono durante l'organizzazione del calcolo parallelo.

Ecco alcuni esempi del loro campo di attività:

1 Konkurentnye  situazioni tra processi.Possiamo immaginare un sistema ideale in cui ha luogo solo un'azione, sta leggendo i dati da un file. Questo sistema è completamente calmo fino a quando uno dei processi deve cambiare questo file. In questo caso, tra i processi sorge una "situazione competitiva". Questo può essere paragonato a un ciottolo in una sorta di meccanismo.

2 Accodare le informazioni di registrazione sequenziale.  Al fine di fornire agli utenti la possibilità di registrare dati in modo rapido e affidabile, vengono create code speciali. Penso che tu sappia cos'è una linea. In realtà, non uno, ma due code vengono create. Queste code differiscono da quelle reali solo perché una è utilizzata solo per la lettura e l'altra ci consente già di registrare le informazioni necessarie. Questa coda è stata creata per prevenire deadlock, di cui parleremo poco dopo.

Che dire di quei processi che richiedono una velocità intrinseca della loro decisione?

In precedenza, durante la creazione delle code di cui sopra, si verificava un problema in cui alcuni processi potevano attendere a lungo per la loro coda, in un momento in cui questo processo era urgente.

Dopo qualche tempo, l'idea era quella di creare code che eseguissero una tale routine di processi che non interferivano con i processi principali o più importanti.

Inoltre, esiste un termine che, sia in teoria che in pratica, è giustificato dal suo nome: è un vicolo cieco.

La sua peculiarità è che sebbene i processi siano già stati liberati, non possono passare al passaggio successivo per completare il processo.

Se è più facile da spiegare, in pratica si ottiene quanto segue: abbiamo un processo X, quando accede al file X, inizia ad attendere che il file Y si liberi, per completare il suo lavoro. Insieme a loro, il processo Y, dopo aver ottenuto l'accesso al file Y, attende che il file X venga liberato.

Questi processi sono chiusi tra loro al momento e attendono il rilascio reciproco del file, senza rilasciare il loro file.

Tale "chiusura" può essere evitata se l'utente si assicura che le risorse siano numerate.

Devono anche essere costruiti rigorosamente in ordine crescente di numeri.

Esempi attuali di ICP

Per visualizzare l'interazione dei programmi su un computer, esiste una risorsa familiare: gli appunti.

Non stupitevi, i nostri buoni vecchi appunti sono anche uno dei meccanismi IPC.

E il principio del suo lavoro è il seguente: il testo selezionato da un editor di testo dopo la selezione viene inserito o nello stesso programma per il layout.

Tu stesso puoi assicurarti che tracce di meccanismi di comunicazione tra processi possano essere trovate anche in piccoli dettagli.

Ci sono stati molti tentativi di creare programmi o meccanismi che garantissero un trasferimento rapido ed efficiente delle informazioni tra i processori.

Sebbene siano stati creati alcuni di questi strumenti, molti di essi sono ancora conservati o serviti come base per i modelli futuri.

Vale la pena notare che molti di essi sono stati implementati in Windows 9x, e ancora di più in Windows NT / 2000.

Vorrei attirare la vostra attenzione sul fatto che l'esistenza di un modo universale di scambiare dati che sarebbe utile in tutte le situazioni è semplicemente impossibile.

Qualunque sia l'ambiente in cui si trova l'utente, sarà preferibile utilizzare esattamente uno dei metodi, sebbene non vi sia molta differenza tra loro in condizioni normali.

Ma possiamo assicurarti che dopo questo articolo non sarà più difficile navigare tra le risorse associate a IPC o la scelta di un particolare metodo di robot, soppesando tutti i pro e i contro.

Per quelle persone che pensano che lo sviluppo di questa tecnologia non sia prefigurato, c'è un fatto che cambierà idea.

Programmi e meccanismi associati a IPC sono direttamente correlati al sistema operativo. Ossia, l'efficienza e l'affidabilità di queste risorse aumenteranno con il miglioramento dei robot.

Molti utenti delle reti locali spesso non sospettano che le loro unità siano risorse di rete a cui è possibile connettersi, denominate risorse amministrative e condivise nascoste C $, ADMIN $, FAX $, IPC $, PRINT $. Devi disabilitarli se non ti servono!

Tipi di condivisioni di rete in Windows XP / 200

Per impostazione predefinita, in Windows XP / 2000 possono essere create le seguenti condivisioni amministrative nascoste:

1. partizioni o volumi root C $ ( D $, E $, F $, ecc.);
2. directory principale del sistema operativo ADMIN $
3. fAX $ share
4. iPC $ share
5. condividi STAMPA $.

Per partizioni e volumi root  come nome della risorsa condivisa, viene utilizzato il nome del disco, a cui il simbolo " $ ". Ad esempio, per accedere alle unità C  e D  verranno create risorse condivise   C $  e   D $.

Directory principale del sistema operativo (  % SYSTEMROOT%) Directory in cui è installato il sistema operativo Windows. Risorsa condivisa   Admin $  Fornisce agli amministratori l'accesso a questa cartella sulla rete.

Condividi FAX $  utilizzato dagli utenti per inviare fax. Questa cartella memorizza nella cache file e copertine che si trovano sul file server.

Condividi IPC $  utilizzato quando si organizzano connessioni temporanee create da applicazioni per lo scambio di dati utilizzando named pipe. Di norma, viene utilizzato per l'amministrazione remota dei server su una rete.

Condividi STAMPA $  utilizzato per l'amministrazione remota delle stampanti.

Se si eliminano le risorse amministrative nascoste create dal sistema operativo ( ad esempio ADMIN $ o C $), quindi dopo aver riavviato il computer o riavviato il servizio Server, verranno nuovamente creati. Se si eliminano le risorse amministrative nascoste create dagli utenti, dopo il riavvio del computer non verranno ricreate. Microsoft Windows XP Home Edition non crea condivisioni amministrative nascoste.

Connessione alle condivisioni di rete in Windows XP / 2000

È possibile utilizzare il comando standard di Windows XP / 2000 per connettersi a condivisioni amministrative e di rete nascoste.   uso netto:

Comando net use  Viene utilizzato per connettersi e disconnettersi dalle risorse di rete e per visualizzare informazioni sulle connessioni correnti a tali risorse. Se la risorsa di rete è l'unità corrente o viene utilizzata da un'applicazione in esecuzione, è impossibile disconnettersi da tale risorsa.

Di seguito è riportato un esempio dell'uso del comando net use per connettersi a una condivisione standard   C $, un computer che esegue Windows 2000, con il nome completo Pro2000, situato sulla rete locale:

Comando net use  completato correttamente con il nome utente Amministratore e una password vuota! Nella maggior parte dei casi, dopo l'installazione di Windows, la password dell'account con il nome Amministratore, creata per impostazione predefinita, viene dimenticata o semplicemente non si desidera impostare, ma accade che durante l'installazione sia stato creato un altro account amministrativo e l'account con il nome Amministratore creato per impostazione predefinita lasciato incustodito!

C: \\\u003e cd / d q: Q: \\\u003e dir Il volume nel dispositivo Q non ha etichetta. Numero di serie del volume: 407D-A72A Contenuto della cartella Q: 13/03/2012 08:46 0 AUTOEXEC.BAK 13/03/2012 08:57 Documenti e impostazioni 17/06/2012 08:34 Intel 04/01/2012 04:02 AM MySoft 17/06/2012 11: 35 NC 18/06/2012 10:10 OpenSSL-Win32 18/06/2012 10:08 File di programma 25/06/2012 15:48 PUBBLICO 18/05/2012 10:53 rms 29/04/2012 10:48 Temp 11/06/2012 22:28 PM WINDOWS 1 file 0 byte 10 cartelle 1 919 221 760 byte liberi Q: \\\u003e

Dopo aver collegato la risorsa C $  e la sua associazione con la lettera di unità, risorsa C $  sarà disponibile nel tuo esploratore e sarà possibile lavorare con esso proprio come con un normale disco locale, beh, e quindi tutto dipenderà dalle tue capacità e dalla tua immaginazione ...

ATTENZIONE !!! Le risorse condivise saranno disponibili solo quando il servizio Server è abilitato / in esecuzione e se non hai intenzione di condividere le tue risorse, è meglio non solo arrestarlo, ma disabilitarlo completamente. Servizio server: fornisce supporto per la condivisione di file, stampanti e pipe denominate per un determinato computer tramite una connessione di rete. Se il servizio viene interrotto, tali funzioni falliranno. Se questo servizio non è consentito, non è possibile avviare servizi esplicitamente dipendenti.

L'esempio sopra mostra chiaramente la vulnerabilità delle risorse di rete aperte.  e account amministratore creato di default con una password vuota! Al fine di evitare la formazione di tali lacune e come risultato della regolare reinstallazione di Windows con il successivo anatema di Bill Gates, è sufficiente coprire inizialmente, per così dire, tutte le lacune e buchi !!!

Disabilitazione / rimozione delle condivisioni di rete

Il modo più semplice è disabilitare il servizio Server, ma alcuni servizi e programmi necessitano del suo supporto, nel qual caso la disabilitazione del servizio Server non è adatta a noi.

Per disabilitare le condivisioni amministrative e di rete ( C $, ADMIN $, FAX $, IPC $, STAMPA $) in Windows XP / 2000 è necessario:

NOTA! In Windows 2000, non è necessario aggiungere il parametro AutoShareWks.

Dopo il riavvio del PC, tutte le risorse di rete condivise verranno eliminate, ad eccezione di un IPC $, non potrà essere eliminato:

IPC $ Risorsa condivisa speciale

Rappresenta una risorsa per la condivisione dell'accesso alle named pipe che forniscono comunicazione tra i programmi. Utilizzato per amministrare in remoto un computer e per visualizzare risorse condivise su un computer. Questa risorsa non può essere eliminata.

La condivisione speciale IPC $ è necessaria per il funzionamento del servizio server e non può essere eliminata. Per visualizzare l'elenco delle condivisioni di rete correnti, utilizzare il comando net share

Ripetiamo che per evitare la formazione di lacune nelle risorse di rete condivise e come risultato della regolare reinstallazione di Windows con il successivo anatema di Bill Gates, è sufficiente coprire inizialmente, per così dire, tutte le lacune e buchi !!!

Che cos'è IPC $? Ho sentito che l'hacking remoto è possibile attraverso di esso? È necessario disabilitare questa risorsa, in tal caso, come si fa?

IPC $, o comunicazione tra processi, è una risorsa amministrativa speciale per la creazione di named pipe. Attraverso quest'ultimo, i computer si scambiano varie informazioni di servizio sul Web. IPC $ serve anche per la gestione remota del server (Fig. 10.1).

Fig. 10.1.Abilitazione del servizio di condivisione di rete IPC $

Per decidere se disabilitare questa risorsa o meno, è necessario considerare quanto segue:

¦ se si tratta di una workstation che deve essere controllata a distanza, è meglio non disconnettersi;

¦ se la workstation non richiede l'amministrazione remota, è possibile disabilitarla;

¦ Se si tratta di un server, non vale la pena disconnettersi, poiché sarà impossibile raggiungerlo attraverso la rete.

IPC $ è disabilitato tramite CMD con il comando net share ipc $ / delete (dopo il riavvio, questa risorsa viene ancora attivata da sola, quindi è possibile scrivere il file BAT corrispondente e inserirlo in autoload).

Il mio computer è su una rete locale. È necessario assicurarsi che la macchina fornisca risorse aperte per l'accesso generale e allo stesso tempo in modo che le risorse condivise nascoste C $, D $, ecc. Non siano disponibili. Come si fa

Tutto quello che devi fare è creare un parametro AutoshareWks di tipo DWORD con un valore nullo nella seguente sezione :.

Cos'è lo spoofing e come proteggerti da esso?

In effetti, lo spoofing è un sostituto. In questo caso, intendo spoofing IP, ovvero spoofing IP. Sostituzione, in cui un utente malintenzionato, utilizzando un indirizzo IP esterno situato all'interno della zona attendibile di indirizzi IP o un indirizzo esterno autorizzato, finge di essere un oggetto di cui ci si può fidare. Molto spesso, per proteggere dallo spoofing IP, viene utilizzato il metodo di associazione dell'indirizzo IP all'indirizzo della scheda di rete (indirizzo MAC), ma questo metodo è anche imperfetto: attualmente sono note utility che sostituiscono l'attuale MAC.

Che cosa sta annusando e ci sono garanzie specifiche contro di esso?

Nel caso più semplice, annusare significa acquisire pacchetti sul Web. Più specificamente: lo sniffer mette la scheda di rete (dove è installata) nella cosiddetta "modalità non udibile", grazie alla quale la macchina attaccante cattura tutti i pacchetti di rete, anche quelli che non sono previsti. Un esempio di uno sniffer è Cain & Abel. Come protezione durante la costruzione di una rete locale, è possibile raccomandare l'uso di switch (switch), non hub (hub), nonché l'uso di protocolli che non trasmettono dati in formato chiaro (SSH, SSL, Kerberos). Ma anche in questo caso, è possibile intercettare i pacchetti usando tecniche avanzate (ad esempio, ARP Poizoning).

Che cos'è il phishing e puoi proteggerti da esso?

Il phishing è una tecnica per ingannare i visitatori del sito. La linea di fondo: il visitatore visita un sito molto simile all'originale, riempie le colonne che richiedono informazioni riservate (numero di carta di credito, password, ecc.). Inoltre, tutte queste informazioni vengono inviate all'attaccante che ha creato questo falso sito. Gli strumenti di protezione dal phishing sono disponibili nelle ultime versioni dei browser Internet, nonché nei pacchetti antivirus e nei firewall. Tuttavia, si dovrebbe riconoscere che fino ad oggi non esiste un modo efficace per proteggersi dal phishing. Il principale strumento di protezione in questo caso è la vigilanza dell'utente.

È noto che molti virus sostituiscono i file di sistema con i propri. Come determinare questa sostituzione?

Per essere sempre consapevoli di tali "trucchi", è necessario abilitare la funzione di notifica di protezione file. Ciò avviene inserendo nel registro HKEY_ LOCAL_MACHINE \\ Software \\ Microsoft \\ Windows \\ CurrentVersion \\ Sys-temFileProtection un parametro del tipo DWORD ShowPopups uguale a 1.

Come cancellare le password memorizzate in IE?

Una cosa abbastanza conveniente è integrata in Internet Explorer: compilazione automatica e archiviazione password. Per cancellare le password memorizzate, procedi come segue: in IE vai a Strumenti\u003e Opzioni Internet\u003e Contenuto\u003e Dati personali\u003e Riempimento automatico,quindi premere il pulsante Cancella password.

Come posso nascondere gli indirizzi dei siti visitati che vengono visualizzati automaticamente nella barra degli indirizzi quando inserisco un nuovo indirizzo?

Tali tracce possono essere eliminate cancellando le corrispondenti voci di registro in. Nota: qui vengono salvate altre tracce, come la cronologia dell'accesso alle unità remote C $, D $ per LAN, la cronologia di ciò che è stato digitato nei moduli di ricerca, ecc.

Dopo aver controllato da Kaspersky, si è scoperto che il record di avvio principale è stato modificato nel sistema. Cosa può essere e come ripristinare lo stato iniziale del record di avvio (Fig. 10.2)?

Fig. 10.2.Controlla i record di avvio?

Molto probabilmente, il bootloader modificato è la conseguenza del virus di avvio, sebbene sia possibile che il bootloader sia cambiato e non a causa di un'infezione da virus. È possibile ripristinare il bootloader dalla console di ripristino di emergenza: per fare ciò, avviare la Console di ripristino di emergenza e registrare i comandi fix mbr e fix boot. È possibile avviare la Console di ripristino di emergenza tramite un disco XP avviabile selezionando Riparare l'installazione di Windows XP ®e ConsoLe © di recupero.Tuttavia, recuperare in questo modo non è il modo migliore. Nella maggior parte dei casi, il bootloader non viene ancora ripristinato. Solo software specializzati possono risolvere tali problemi, un vivido esempio dei quali è ADINF32.

Dimmi dove sono registrati gli aggiornamenti in Kaspersky Anti-Virus 7.0. E poi quando reinstalli il sistema, dovrai scaricare di nuovo tutti gli aggiornamenti.

Aggiornamenti: la cartella del database si trova in e Impostazioni \\ Tutti gli utenti \\ Dati applicazioni \\ Kaspersky Lab \\ AVP7 \\ Bases.

Dati i risultati di numerosi test, possiamo dire che nessuno dei browser esistenti è sicuro al 100%. Nel frattempo, alcuni dei prodotti possono ancora essere considerati abbastanza sicuri. Uno di questi prodotti è Opera.

La situazione è questa: il mio computer si trova sulla rete locale e ho accesso a Internet tramite una scheda. Il limite della vecchia scheda è stato esaurito, ma non è possibile inserire un nuovo accesso e password, poiché quando si tenta di accedere a qualsiasi sito, la finestra di autenticazione con il server non viene visualizzata (tutte le impostazioni del server proxy sono corrette). Come restituire la finestra di accesso e la password di input?

Per visualizzare nuovamente la finestra di autenticazione, è necessario eliminare il vecchio login e la password tramite lo snap-in Account utente(Fig. 10.3) - per questo, vai al menu Start? Run,inserisci il controllo comando userpasswords2, nella finestra che appare, fai clic su Extra? Gestione password? Elimina.

Durante il caricamento del sistema Kaspersky Anti-Virus, che in precedenza funzionava senza errori, per qualche motivo ha smesso di avviarsi; quando si tenta di forzare un avvio, si disconnette anche se stesso. Cosa può essere e come gestirlo?

Molto probabilmente, il tuo sistema è infetto da un virus che disabilita Kaspersky Anti-Virus. Tale "infezione" è molto probabilmente configurata per disabilitare altri popolari prodotti antivirus. La via d'uscita è l'avvio da un ambiente pulito, come un disco di avvio (Windows LiveCD). Inoltre, come opzione, controllare il sistema in questo ambiente con un antivirus che non richiede installazione (un tale antivirus può essere avviato da un'unità flash, ad esempio il popolare prodotto Dr.Web CureIt Scanner (Fig. 10.4), che può essere scaricato dal sito Web ufficiale Dr.Web) .

Fig. 10.3.Gestione password

Fig. 10.4.Scanner CureIt in azione

Ho controllato il mio disco rigido con Kaspersky e ho trovato un vero virus nelle distribuzioni di Panda Titanium! Come essere

Molto probabilmente, il file non è infetto da nulla e non è necessario generare un allarme. La maggior parte dei programmi antivirus funziona di volta in volta durante la scansione di file di altri antivirus.

Sono un amministratore di sistema principiante e vorrei conoscere la tua opinione su quale dei sistemi operativi server può essere considerato il più affidabile e produttivo?

Il mio firewall segnala costantemente pacchetti provenienti da qualche parte con il flag "syn". Cosa significa questo?

Molto probabilmente, qualcuno o qualcosa (ad esempio un worm di rete) esegue la scansione del computer. La scansione è di solito una preparazione per un attacco. Pertanto, hai qualcosa a cui pensare.