L'AIS distribuito è diventato una realtà quotidiana. Numerosi AIS aziendali utilizzano database distribuiti. Sono stati elaborati metodi di distribuzione dei dati e gestione dei dati distribuiti, approcci architetturali che garantiscono la scalabilità dei sistemi, implementando i principi dell'architettura client-server multi-tier, nonché l'architettura del livello intermedio.

Le architetture mobili iniziano ad essere applicate nella pratica. Questo vale sia per i sistemi di database che per le applicazioni Web.

Si sta riprendendo un approccio alla costruzione di sistemi distribuiti basati su un'architettura peer-to-peer, in cui, contrariamente all'architettura client-server che domina oggi nei sistemi distribuiti, i ruoli delle parti interagenti nella rete non sono fissi. Sono assegnati in base alla situazione nella rete, al carico di lavoro dei suoi nodi.

In connessione con l'intenso sviluppo delle tecnologie di comunicazione, l'AIS mobile si sta sviluppando attivamente. Sono stati sviluppati i mezzi tecnici e il software per la loro creazione. Ciò ha portato allo sviluppo di sistemi di database mobili. Molti team di ricerca conducono ricerche sulle caratteristiche specifiche di tali sistemi e creano i loro vari prototipi. Le tecnologie Java sono diventate uno strumento importante per lo sviluppo di software mobile.

È stato creato uno standard Wireless Application Protocol (WAP) ed è già supportato da alcuni modelli di telefoni cellulari. Basato su WAP e XML, il W3C ha sviluppato un linguaggio di markup per le comunicazioni wireless, WML (Wireless Markup Language).

Nello sviluppo dell'AIS, si è cominciato a prestare maggiore attenzione ai metadati. In questo caso, si procede in due direzioni: standardizzare la presentazione dei metadati e garantire il loro supporto nel sistema.

AIS utilizza una varietà di modi e mezzi per presentare i metadati (vari tipi di repository di metadati). La mancanza di unificazione in quest'area complica notevolmente la soluzione dei problemi di mobilità delle applicazioni, riutilizzo e integrazione delle risorse informative e delle tecnologie dell'informazione, nonché la reingegnerizzazione dell'AIS.

Per superare queste difficoltà, si sta attivamente perseguendo lo sviluppo di standard di metadati incentrati su varie tecnologie dell'informazione. In questo ambito esistono già una serie di standard internazionali, nazionali e di settore che definiscono la presentazione dei metadati e lo scambio di metadati in AIS. Alcuni di loro hanno già acquisito lo status di standard de facto. Ci limiteremo qui a citare solo i più significativi di essi.

Probabilmente il primo standard de facto per questa categoria è stato il linguaggio di descrizione dei dati CODASYL per i database in rete. Dovrebbero essere nominati i seguenti standard: lo standard del linguaggio di query SQL per i database relazionali, contenente la definizione del cosiddetto schema delle informazioni - un insieme di rappresentazioni di schemi di database relazionali; il componente standard del database degli oggetti ODMG che descrive le interfacce del repository dello schema degli oggetti; standard internazionale IRDS (Information Resource Dictionary Systems), che descrive i sistemi per creare e mantenere gli elenchi delle risorse informative di un'organizzazione.

Si ricorda poi lo standard Common Warehouse Metamodel (CWM) per la rappresentazione dei metadati del data warehouse sviluppato dal consorzio OMG, basato sullo standard OIM (Open Information Model) precedentemente creato per scopi più ampi dal consorzio MDC (Meta Data Coalition). .

La nuova piattaforma tecnologica XML per il Web include anche gli standard di presentazione dei metadati. Il supporto dei metadati è una delle innovazioni più importanti del Web, che cambia radicalmente la tecnologia per la gestione delle proprie risorse informative. Sebbene il supporto dei metadati fosse originariamente richiesto nelle tecnologie di database, i metadati non erano supportati sul Web di prima generazione.

Gli standard di metadati Web includono un sottoinsieme del linguaggio XML utilizzato per descrivere la struttura logica di alcuni tipi di documenti XML. Questa descrizione è chiamata DTD (Document Type Definition). Inoltre, la piattaforma XML include lo standard XML Schema, che offre funzionalità più avanzate per la descrizione di documenti XML. Lo standard Resource Definition Framework (RDF) definisce un semplice linguaggio di rappresentazione della conoscenza per descrivere il contenuto dei documenti XML. Infine, l'emergente standard OWL (Ontology Web Language) definisce un linguaggio formale di descrizione dell'ontologia per il Web semantico.

Lo standard Unified Modeling Language (UML), che fornisce la rappresentazione dei metadati per l'analisi degli oggetti visivi CASE e gli strumenti di progettazione, è stato sviluppato dal consorzio OMG. Questa lingua è supportata in molti prodotti software CASE. L'OMG ha anche creato lo standard XML Metadata Interchange (XMI) per lo scambio di metadati tra gli strumenti CASE utilizzando UML.

Va qui menzionato anche lo standard Dublin Core (DC), un insieme di elementi di metadati per descrivere il contenuto di documenti di diversa natura. Questo standard ha rapidamente guadagnato popolarità e ha trovato, in particolare, un uso diffuso nell'ambiente Web (vedere la Sezione 3.3).

Proseguono i lavori per lo sviluppo degli esistenti e la creazione di nuovi standard per la presentazione dei metadati per AIS. Informazioni più dettagliate sugli standard in questione possono essere trovate nell'enciclopedia.

Secondo il noto esperto nel campo dell'informatica E. Tanenbaum, non esiste una definizione generalmente accettata e allo stesso tempo rigorosa di un sistema distribuito. Alcuni ingegno sostengono che distribuito è tale sistema informatico, in cui un malfunzionamento di un computer, della cui esistenza gli utenti non sospettavano nemmeno prima, porta alla cessazione di tutto il loro lavoro. Una parte significativa dei sistemi informatici distribuiti, purtroppo, soddisfa questa definizione, ma formalmente si riferisce solo a sistemi con un unico punto di vulnerabilità ( singolo punto di errore).

Spesso, quando si definisce un sistema distribuito, l'attenzione è posta sulla suddivisione delle sue funzioni tra più computer. Con questo approccio, any è distribuito sistema informatico dove l'elaborazione dei dati è suddivisa tra due o più computer. Sulla base della definizione di E. Tanenbaum, un sistema distribuito un po' più strettamente può essere definito come un insieme di computer indipendenti collegati da canali di comunicazione, che, dal punto di vista di un utente di un software, sembrano un tutt'uno.

Questo approccio alla definizione di un sistema distribuito ha i suoi svantaggi. Ad esempio, tutto ciò che viene utilizzato in un sistema così distribuito Software potrebbe funzionare su un unico computer, ma dal punto di vista della definizione di cui sopra, tale sistema non sarà più distribuito. Pertanto, il concetto di sistema distribuito dovrebbe probabilmente essere basato sull'analisi del software che costituisce tale sistema.

Come base per descrivere l'interazione di due entità, si consideri il modello generale di interazione client-server, in cui una delle parti (il client) avvia lo scambio di dati inviando una richiesta all'altra parte (il server). Il server elabora la richiesta e, se necessario, invia una risposta al client (Fig. 1.1).

Riso. 1.1.

L'interazione nell'ambito del modello client-server può essere sincrona, quando il client è in attesa che il server elabori la sua richiesta, o asincrona, in cui il client invia una richiesta al server e continua la sua esecuzione senza attendere la richiesta del server. risposta. Il modello client e server può essere utilizzato come base per descrivere varie interazioni. Per questo corso è importante l'interazione delle parti costitutive del software che forma un sistema distribuito.

Riso. 1.2.

Considera una certa applicazione tipica, che, secondo i concetti moderni, può essere suddivisa nei seguenti livelli logici (Fig. 1.2): interfaccia utente(PI), logica applicativa (LP) e accesso ai dati (DD), lavorando con il database (DB). L'utente del sistema interagisce con esso attraverso l'interfaccia utente, il database memorizza i dati che descrivono il dominio dell'applicazione e il livello logico dell'applicazione implementa tutti gli algoritmi relativi a argomento.

Poiché, in pratica, diversi utenti del sistema sono solitamente interessati ad accedere agli stessi dati, la separazione più semplice delle funzioni di un tale sistema tra più computer sarà la separazione dei livelli logici dell'applicazione tra una parte server dell'applicazione , che è responsabile dell'accesso ai dati, e alle parti client situate su più computer che implementano l'interfaccia utente. La logica dell'applicazione può essere assegnata al server, ai client o condivisa tra loro (Figura 1.3).

Riso. 1.3.

L'architettura delle applicazioni costruite su questo principio è chiamata client-server o two-tier. In pratica, tali sistemi spesso non sono classificati come distribuiti, ma formalmente possono essere considerati i rappresentanti più semplici di sistemi distribuiti.

Lo sviluppo dell'architettura client-server è un'architettura a tre livelli, in cui l'interfaccia utente, la logica applicativa e l'accesso ai dati sono separati in componenti indipendenti del sistema che possono operare su computer indipendenti (Fig. 1.4).

Riso. 1.4.

La richiesta dell'utente in tali sistemi viene elaborata in sequenza dalla parte client del sistema, dal server della logica dell'applicazione e dal server del database. Tuttavia, un sistema distribuito è generalmente inteso come un sistema con un'architettura più complessa rispetto a uno a tre livelli.

Nel capitolo precedente, abbiamo esaminato sistemi multiprocessore strettamente accoppiati con memoria condivisa, strutture di dati del kernel condivise e un pool condiviso da cui vengono invocati i processi. Spesso, tuttavia, è desiderabile allocare i processori in modo tale che siano autonomi dall'ambiente operativo e dalle condizioni operative per scopi di condivisione delle risorse. Supponiamo, ad esempio, che un utente di un personal computer debba accedere a file che si trovano su una macchina più grande, ma allo stesso tempo mantenere il controllo sul personal computer. Sebbene alcuni programmi, come uucp, supportino il trasferimento di file di rete e altre funzioni di rete, il loro utilizzo non sarà nascosto all'utente, poiché l'utente è consapevole di utilizzare la rete. Inoltre, va notato che programmi come gli editor di testo non funzionano con i file eliminati, come con quelli ordinari. Gli utenti dovrebbero disporre del set standard di funzioni del sistema UNIX e, a parte il potenziale collo di bottiglia delle prestazioni, non dovrebbero sentire l'attraversamento dei confini della macchina. Quindi, ad esempio, il lavoro delle funzioni di sistema aperte e lette con file su macchine remote non dovrebbe differire dal loro lavoro con file appartenenti a sistemi locali.

L'architettura del sistema distribuito è mostrata nella Figura 13.1. Ciascun computer mostrato nella figura è un'unità autonoma costituita da CPU, memoria e periferiche. Il modello non si rompe anche se il computer non dispone di un file system locale: deve disporre di periferiche per comunicare con altre macchine e tutti i file che gli appartengono possono essere localizzati su un altro computer. La memoria fisica disponibile per ogni macchina è indipendente dai processi in esecuzione su altre macchine. Sotto questo aspetto, i sistemi distribuiti differiscono dai sistemi multiprocessore strettamente accoppiati discussi nel capitolo precedente. Di conseguenza, il nucleo del sistema su ciascuna macchina funziona indipendentemente dalle condizioni operative esterne dell'ambiente distribuito.

Figura 13.1. Modello di sistema ad architettura distribuita

I sistemi distribuiti, ben descritti in letteratura, rientrano tradizionalmente nelle seguenti categorie:

Sistemi periferici, che sono gruppi di macchine che hanno una forte comunanza e sono associati a una macchina (di solito più grande). I processori periferici condividono il loro carico con il processore centrale e inoltrano ad esso tutte le chiamate al sistema operativo. L'obiettivo di un sistema periferico è aumentare le prestazioni complessive della rete e fornire la capacità di allocare un processore a un singolo processo in un ambiente operativo UNIX. Il sistema si avvia come un modulo separato; A differenza di altri modelli di sistemi distribuiti, i sistemi periferici non hanno una reale autonomia, tranne nei casi relativi al dispacciamento dei processi e all'allocazione della memoria locale.

Sistemi distribuiti come "Newcastle", che consentono la comunicazione remota tramite i nomi dei file remoti nella libreria (il nome è tratto dall'articolo "The Newcastle Connection" - vedi). I file eliminati hanno un BOM (nome distinto) che, nel percorso di ricerca, contiene caratteri speciali o un componente del nome facoltativo che precede la radice del file system. L'implementazione di questo metodo non comporta modifiche al kernel di sistema, e quindi è più semplice degli altri metodi discussi in questo capitolo, ma meno flessibile.

I sistemi distribuiti sono completamente trasparenti, in cui i nomi distinti standard sono sufficienti per fare riferimento a file che si trovano su altre macchine; sta al kernel riconoscere questi file come cancellati. I percorsi di ricerca dei file specificati nei loro nomi compositi attraversano i confini della macchina nei punti di montaggio, indipendentemente da quanti punti di questo tipo si formano quando i filesystem sono montati sui dischi.

In questo capitolo esamineremo l'architettura di ciascun modello; tutte le informazioni fornite non si basano sui risultati di sviluppi specifici, ma su informazioni pubblicate in vari articoli tecnici. Ciò presuppone che i moduli di protocollo e i driver di dispositivo siano responsabili dell'indirizzamento, del routing, del controllo del flusso e del rilevamento e correzione degli errori, in altre parole, che ogni modello sia indipendente dalla rete utilizzata. Gli esempi di utilizzo delle funzioni di sistema mostrati nella sezione successiva per i sistemi periferici funzionano in modo simile per sistemi come Newcastle e per sistemi completamente trasparenti, che verranno discussi in seguito; quindi, li considereremo in dettaglio una volta, e nelle sezioni dedicate ad altri tipi di sistemi, ci concentreremo principalmente sulle caratteristiche che distinguono questi modelli da tutti gli altri.

13.1 PROCESSORI PERIFERICI

L'architettura del sistema periferico è mostrata in Figura 13.2. L'obiettivo di questa configurazione è migliorare le prestazioni complessive della rete riassegnando i processi in esecuzione tra la CPU e i processori periferici. Ciascuno dei processori periferici non dispone di altri dispositivi periferici locali oltre a quelli necessari per comunicare con l'unità di elaborazione centrale. Il file system e tutti i dispositivi sono a disposizione del processore centrale. Supponiamo che tutti i processi utente siano eseguiti sul processore periferico e non si spostino tra processori periferici; una volta trasferiti al processore, rimangono su di esso fino al completamento. Il processore periferico contiene una versione leggera del sistema operativo progettata per gestire le chiamate locali al sistema, la gestione degli interrupt, l'allocazione della memoria, i protocolli di rete e un driver per la comunicazione con il processore centrale.

Quando il sistema viene inizializzato sul processore centrale, il core carica il sistema operativo locale su ciascuno dei processori periferici tramite linee di comunicazione. Qualsiasi processo in esecuzione sulla periferia è associato a un processo satellite appartenente al processore centrale (vedi); quando un processo in esecuzione su un processore periferico chiama una funzione di sistema che richiede solo i servizi del processore centrale, il processo periferico comunica con il suo satellite e la richiesta viene inviata al processore centrale per l'elaborazione. Il processo satellitare svolge una funzione di sistema e invia i risultati al processore periferico. La relazione tra un processo periferico e il suo satellite è simile alla relazione client-server discussa in dettaglio nel Capitolo 11: il processo periferico agisce come client del suo satellite, che supporta le funzioni di lavoro con il file system. In questo caso, il processo del server remoto dispone di un solo client. Nella sezione 13.4 esamineremo i processi server con più client.

Figura 13.2. Configurazione del sistema periferico

Figura 13.3. Formati dei messaggi

Quando un processo periferico chiama una funzione di sistema che può essere elaborata localmente, il kernel non ha bisogno di inviare una richiesta al processo satellite. Quindi, ad esempio, per ottenere memoria aggiuntiva, un processo può chiamare la funzione sbrk per l'esecuzione locale. Tuttavia, se sono richiesti i servizi del processore centrale, ad esempio, per aprire un file, il kernel codifica le informazioni sui parametri passati alla funzione chiamata e le condizioni di esecuzione del processo in un messaggio inviato al processo satellite (Figura 13.3). Il messaggio include un segno da cui segue che la funzione di sistema viene eseguita dal processo satellite per conto del cliente, parametri passati alla funzione e dati sull'ambiente di esecuzione del processo (ad esempio codici identificativi utente e gruppo), che sono diverso per funzioni diverse. Il resto del messaggio è costituito da dati a lunghezza variabile (ad esempio, un nome di file composto o dati da scrivere con la funzione di scrittura).

Il processo satellite attende le richieste dal processo periferico; quando riceve una richiesta, decodifica il messaggio, determina il tipo di funzione del sistema, la esegue e converte i risultati in una risposta inviata al processo periferico. La risposta, oltre ai risultati dell'esecuzione della funzione di sistema, include il messaggio di errore (se presente), il numero di segnale e un array di dati a lunghezza variabile contenente, ad esempio, informazioni lette da un file. Il processo periferico è sospeso fino a quando non si riceve una risposta, dopo averla ricevuta, decrittografa e trasmette i risultati all'utente. Questo è lo schema generale per la gestione delle chiamate al sistema operativo; passiamo ora ad una considerazione più dettagliata delle singole funzioni.

Per spiegare come funziona il sistema periferico, considera una serie di funzioni: getppid, open, write, fork, exit e signal. La funzione getppid è piuttosto semplice in quanto si occupa di semplici moduli di richiesta e risposta che vengono scambiati tra la periferica e la CPU. Il core sul processore periferico genera un messaggio che ha un segno, dal quale ne consegue che la funzione richiesta è la funzione getppid, e invia la richiesta al processore centrale. Il processo satellite sul processore centrale legge il messaggio dal processore periferico, decodifica il tipo di funzione di sistema, lo esegue e ottiene l'identificatore del suo genitore. Quindi genera una risposta e la trasmette a un processo periferico in sospeso all'altra estremità della linea di comunicazione. Quando il processore periferico riceve una risposta, la passa al processo che ha chiamato la funzione di sistema getppid. Se il processo periferico memorizza i dati (come l'ID di processo del genitore) nella memoria locale, non deve comunicare affatto con il suo compagno.

Se viene chiamata la funzione di sistema aperto, il processo periferico invia un messaggio al suo compagno, che include il nome del file e altri parametri. In caso di successo, il processo associato alloca un indice e un punto di ingresso alla tabella dei file, alloca una voce nella tabella dei descrittori di file utente nel suo spazio e restituisce il descrittore di file al processo periferico. Per tutto questo tempo, all'altra estremità della linea di comunicazione, il processo periferico è in attesa di una risposta. Non ha strutture a sua disposizione che memorizzino informazioni sul file in fase di apertura; Il descrittore restituito da open è un puntatore a una voce nel processo compagno nella tabella dei descrittori di file utente. I risultati dell'esecuzione della funzione sono mostrati nella Figura 13.4.

Figura 13.4. Richiamo della funzione open da un processo periferico

Se viene effettuata una chiamata alla funzione di sistema write, il processore periferico genera un messaggio costituito da un segno della funzione write, un descrittore di file e la quantità di dati da scrivere. Quindi, dallo spazio del processo periferico, copia i dati al processo satellitare attraverso la linea di comunicazione. Il processo satellitare decifra il messaggio ricevuto, legge i dati dalla linea di comunicazione e li scrive nel file corrispondente (il descrittore contenuto nel messaggio viene utilizzato come puntatore all'indice di cui e al record di cui viene utilizzato nella tabella del file ); tutte queste azioni vengono eseguite sul processore centrale. Al termine del lavoro, il processo satellite invia al processo periferico un messaggio che conferma la ricezione del messaggio e contiene il numero di byte di dati che sono stati copiati con successo nel file. L'operazione di lettura è simile; il satellite comunica al processo periferico il numero di byte effettivamente letti (nel caso di lettura di dati da terminale o da canale, tale numero non sempre coincide con la quantità specificata nella richiesta). Per eseguire l'una o l'altra funzione, potrebbe essere necessario inviare messaggi informativi più volte sulla rete, che è determinata dalla quantità di dati inviati e dalla dimensione dei pacchetti di rete.

L'unica funzione che deve essere modificata durante l'esecuzione sulla CPU è la funzione del sistema fork. Quando un processo esegue questa funzione sulla CPU, il kernel seleziona per esso un processore periferico e invia un messaggio a un processo speciale, il server, informandolo che sta per iniziare a scaricare il processo corrente. Supponendo che il server abbia accettato la richiesta, il kernel utilizza il fork per creare un nuovo processo periferico, allocando una voce della tabella del processo e uno spazio di indirizzi. Il processore centrale scarica una copia del processo che ha chiamato la funzione fork al processore periferico, sovrascrivendo lo spazio degli indirizzi appena assegnato, genera un satellite locale per comunicare con il nuovo processo periferico e invia un messaggio alla periferica per inizializzare il contatore di programma per il nuovo processo. Il processo satellite (sulla CPU) è un discendente del processo chiamato fork; un processo periferico è tecnicamente un discendente del processo server, ma logicamente è un discendente del processo che ha chiamato la funzione fork. Il processo server non ha una connessione logica con il figlio quando il fork viene completato; l'unico compito del server è aiutare a scaricare il bambino. A causa della forte connessione tra i componenti del sistema (i processori periferici non hanno autonomia), il processo periferico e il processo satellitare hanno lo stesso codice identificativo. La relazione tra i processi è mostrata nella Figura 13.5: la linea continua mostra la relazione genitore-figlio e la linea tratteggiata mostra la relazione tra pari.

Figura 13.5. Esecuzione di una funzione fork sulla CPU

Quando un processo esegue la funzione fork sul processore periferico, invia un messaggio al suo satellite sulla CPU, che esegue quindi l'intera sequenza di azioni sopra descritta. Il satellite seleziona un nuovo processore periferico e fa i preparativi necessari per scaricare l'immagine del vecchio processo: invia una richiesta al processo periferico genitore di leggere la sua immagine, in risposta alla quale inizia il trasferimento dei dati richiesti dall'altra parte del canale di comunicazione. Il satellite legge l'immagine trasmessa e la sovrascrive al discendente periferico. Quando lo scaricamento dell'immagine è terminato, il satellite processa il fork, creando il suo figlio sulla CPU, e passa il valore del program counter alla periferica figlio in modo che quest'ultimo sappia da quale indirizzo iniziare l'esecuzione. Ovviamente sarebbe meglio se il figlio del processo compagno fosse assegnato al figlio periferico come genitore, ma nel nostro caso i processi generati sono in grado di girare su altri processori periferici, non solo su quello su cui vengono creati. La relazione tra i processi alla fine della funzione fork è mostrata nella Figura 13.6. Quando il processo periferico termina il suo lavoro, invia un messaggio corrispondente al processo satellite, e anche questo termina. Un processo complementare non può avviare un arresto.

Figura 13.6. Esecuzione di una funzione fork su un processore periferico

Sia nei sistemi multiprocessore che monoprocessore, il processo deve rispondere ai segnali nello stesso modo: il processo o completa l'esecuzione della funzione di sistema prima del controllo dei segnali, oppure, al contrario, alla ricezione del segnale, esce immediatamente dallo stato di sospensione e interrompe bruscamente il lavoro della funzione del sistema, se questo è coerente con la priorità con cui è stato sospeso. Poiché il processo satellite svolge funzioni di sistema per conto del processo periferico, deve rispondere ai segnali in coordinamento con quest'ultimo. Se, su un sistema uniprocessore, un segnale provoca l'interruzione della funzione da parte di un processo, il processo compagno su un sistema multiprocessore dovrebbe comportarsi allo stesso modo. Lo stesso si può dire del caso in cui il segnale inviti il ​​processo a terminare il suo lavoro utilizzando la funzione di uscita: il processo periferico termina e invia il messaggio corrispondente al processo satellite, che, ovviamente, termina anch'esso.

Quando un processo periferico chiama la funzione del sistema di segnale, memorizza le informazioni correnti in tabelle locali e invia un messaggio al suo satellite informandolo se il segnale specificato deve essere ricevuto o ignorato. Il processo satellitare non si preoccupa se intercetta il segnale o l'azione predefinita. La reazione di un processo a un segnale dipende da tre fattori (Figura 13.7): se un segnale viene ricevuto mentre il processo sta eseguendo una funzione di sistema, se viene fornita un'indicazione utilizzando la funzione di segnale per ignorare il segnale, se il segnale si verifica su lo stesso processore periferico o su un altro. Passiamo a considerare le varie possibilità.

algoritmo sighandle / * algoritmo di elaborazione del segnale * /

if (il processo attuale è il compagno di qualcuno o ha un prototipo)

if (segnale ignorato)

if (il segnale è arrivato durante l'esecuzione di una funzione di sistema)

mettere un segnale davanti al processo satellitare;

inviare un messaggio di segnalazione a un processo periferico;

else (/ * processo periferico * /

/ * se un segnale è stato ricevuto o meno durante l'esecuzione di una funzione di sistema * /

inviare un segnale al processo satellitare;

algoritmo satellite_end_of_syscall / * terminazione di una funzione di sistema richiamata da un processo periferico * /

informazioni di input: assente

impronta: nessuna

if (è stato ricevuto un interrupt durante l'esecuzione di una funzione di sistema)

inviare un messaggio di interruzione, segnale al processo periferico;

else / * l'esecuzione della funzione di sistema non è stata interrotta * /

invia risposta: abilita il flag che mostra l'arrivo del segnale;

Figura 13.7. Elaborazione del segnale nel sistema periferico

Supponiamo che un processo periferico abbia sospeso il suo lavoro mentre il processo satellite svolge una funzione di sistema per suo conto. Se il segnale si verifica altrove, il processo satellitare lo rileva prima del processo periferico. Sono possibili tre casi.

1. Se, in attesa di qualche evento, il processo satellite non è entrato nello stato di sospensione, dal quale uscirebbe alla ricezione di un segnale, svolge fino in fondo la funzione di sistema, invia i risultati dell'esecuzione al processo periferico e mostra quale dei segnali ha ricevuto.

2. Se il processo ha richiesto di ignorare questo tipo di segnale, il satellite continua a seguire l'algoritmo di esecuzione della funzione di sistema senza uscire dallo stato sospeso di longjmp. Nella risposta inviata al processo periferico, non ci sarà alcun messaggio di ricezione di segnale.

3. Se, alla ricezione di un segnale, il processo satellite interrompe l'esecuzione di una funzione di sistema (tramite longjmp), ne informa il processo periferico e gli comunica il numero del segnale.

Il processo periferico cerca informazioni sulla ricezione dei segnali nella risposta ricevuta e, se presenti, elabora i segnali prima di uscire dalla funzione di sistema. Pertanto, il comportamento di un processo in un sistema multiprocessore corrisponde esattamente al comportamento in un sistema uniprocessore: o esce senza uscire dalla modalità kernel, oppure chiama una funzione di elaborazione del segnale personalizzata, oppure ignora il segnale e completa con successo la funzione di sistema.

Figura 13.8. Interruzione durante l'esecuzione di una funzione di sistema

Supponiamo, ad esempio, che un processo periferico chiami una funzione di lettura da un terminale collegato al processore centrale e metta in pausa il suo lavoro mentre il processo satellite esegue la funzione (Figura 13.8). Se l'utente preme il tasto break, il core della CPU invia un segnale al processo satellite. Se il satellite era in uno stato sospeso, in attesa di una porzione di dati dal terminale, esce immediatamente da questo stato e termina la funzione di lettura. In risposta a una richiesta di un processo periferico, il satellite fornisce un codice di errore e un numero di segnale corrispondente all'interruzione. Il processo periferico analizza la risposta e, poiché il messaggio dice che è arrivato un interrupt, invia il segnale a se stesso. Prima di uscire dalla funzione di lettura, il nucleo periferico controlla la segnalazione, rileva un segnale di interruzione dal processo satellitare e lo elabora come di consueto. Se, a seguito della ricezione di un segnale di interrupt, il processo periferico termina il suo lavoro utilizzando la funzione di uscita, questa funzione si occupa di interrompere il processo satellitare. Se il processo periferico intercetta i segnali di interruzione, chiama la funzione di gestione del segnale definita dall'utente e restituisce un codice di errore all'utente all'uscita dalla funzione di lettura. Se invece il satellite esegue la funzione di sistema stat per conto del processo periferico, non interromperà la sua esecuzione quando riceve un segnale (la funzione stat è garantita per uscire da qualsiasi pausa, poiché ha un tempo di attesa della risorsa limitato ). Il satellite completa l'esecuzione della funzione e restituisce il numero del segnale al processo periferico. Il processo periferico invia un segnale a se stesso e lo riceve all'uscita dalla funzione di sistema.

Se si verifica un segnale sul processore periferico durante l'esecuzione di una funzione di sistema, il processo periferico sarà all'oscuro se tornerà presto al controllo dal processo satellitare o quest'ultimo entrerà in uno stato sospeso a tempo indeterminato. Il processo periferico invia un messaggio speciale al satellite, informandolo del verificarsi di un segnale. Il core della CPU decodifica il messaggio e invia un segnale al satellite, la cui reazione alla ricezione del segnale è descritta nei paragrafi precedenti (interruzione anomala dell'esecuzione della funzione o suo completamento). Il processo periferico non può inviare un messaggio direttamente al satellite perché il satellite è impegnato nell'esecuzione di una funzione di sistema e non sta leggendo i dati dalla linea di comunicazione.

Facendo riferimento all'esempio letto, va notato che il processo periferico non ha idea se il suo compagno è in attesa di input dal terminale o sta eseguendo altre azioni. Il processo periferico invia un messaggio di segnalazione al satellite: se il satellite è in stato di sospensione con priorità interrompibile, esce immediatamente da questo stato e termina la funzione del sistema; in caso contrario, la funzione viene portata avanti fino al completamento con successo.

Si consideri infine il caso dell'arrivo di un segnale in un momento non associato all'esecuzione di una funzione di sistema. Se un segnale ha avuto origine su un altro processore, il satellite lo riceve per primo e invia un messaggio di segnale al processo periferico, indipendentemente dal fatto che il segnale riguardi il processo periferico o meno. Il nucleo periferico decifra il messaggio e invia un segnale al processo, che reagisce nel modo consueto. Se il segnale ha avuto origine sul processore periferico, il processo esegue azioni standard senza ricorrere ai servizi del suo satellite.

Quando un processo periferico invia un segnale ad altri processi periferici, codifica un messaggio di chiamata kill e lo invia al processo satellite, che esegue localmente la funzione chiamata. Se alcuni dei processi a cui è destinato il segnale si trovano su altri processori periferici, i loro satelliti riceveranno il segnale (e reagiranno ad esso come descritto sopra).

13.2 TIPO DI COMUNICAZIONE NEWCASTLE

Nella sezione precedente, abbiamo considerato un tipo di sistema strettamente accoppiato, caratterizzato dall'invio di tutte le chiamate alle funzioni del sottosistema di gestione dei file che sorgono sul processore periferico a un processore remoto (centrale). Passiamo ora alla considerazione dei sistemi con una connessione più debole, che consistono in macchine che effettuano chiamate a file che si trovano su altre macchine. In una rete di personal computer e workstation, ad esempio, gli utenti spesso accedono a file che si trovano su una macchina di grandi dimensioni. Nelle prossime due sezioni esamineremo le configurazioni di sistema in cui tutte le funzioni di sistema vengono eseguite in sottosistemi locali, ma allo stesso tempo è possibile accedere ai file (tramite le funzioni del sottosistema di gestione dei file) che si trovano su altre macchine.

Questi sistemi utilizzano uno dei due percorsi seguenti per identificare i file eliminati. Su alcuni sistemi, al nome del file composito viene aggiunto un carattere speciale: il componente del nome che precede questo carattere identifica la macchina, il resto del nome è il file su quella macchina. Quindi, per esempio, il nome distinto

"sftig! / fs1 / mjb / rje"

identifica il file "/fs1/mjb/rje" sulla macchina "sftig". Questo schema di identificazione dei file segue la convenzione uucp per il trasferimento di file tra sistemi simili a UNIX. In un altro schema, i file eliminati vengono identificati aggiungendo un prefisso speciale al nome, ad esempio:

/../sftig/fs1/mjb/rje

dove "/../" è un prefisso che indica che il file è stato cancellato; il secondo componente del nome file è il nome della macchina remota. Questo schema usa la familiare sintassi dei nomi dei file UNIX, quindi a differenza del primo schema, i programmi utente non hanno bisogno di adattarsi all'uso di nomi con una costruzione insolita (vedi).

Figura 13.9. Formulazione di richieste al file server (processore)

Dedicheremo il resto di questa sezione a un modello di un sistema che utilizza un collegamento Newcastle, in cui il kernel non si occupa di riconoscere i file cancellati; questa funzione è completamente assegnata ai sottoprogrammi della libreria standard C, che in questo caso svolgono il ruolo di interfaccia di sistema. Queste routine analizzano la prima componente del nome del file, che in entrambi i metodi di identificazione descritti contiene un segno della lontananza del file. Questa è una partenza dalla routine in cui le routine di libreria non analizzano i nomi dei file. La Figura 13.9 mostra come vengono formulate le richieste a un file server. Se il file è locale, il kernel del sistema locale elabora la richiesta normalmente. Consideriamo il caso opposto:

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

La subroutine aperta nella libreria C analizza i primi due componenti del nome file distinto e sa cercare il file sulla macchina remota "sftig". Per avere informazioni sul fatto che il processo abbia avuto in precedenza una connessione con una data macchina, la subroutine avvia una struttura speciale in cui ricorda questo fatto e, in caso di risposta negativa, stabilisce una connessione con il file server in esecuzione sul remoto macchina. Quando il processo formula la sua prima richiesta di elaborazione remota, il server remoto conferma la richiesta, se necessario, registra nei campi dei codici identificativi dell'utente e del gruppo e crea un processo satellite che agirà per conto del processo client.

Per soddisfare le richieste del client, il satellite deve disporre degli stessi permessi di file sulla macchina remota del client. In altre parole, l'utente "mjb" deve avere gli stessi diritti di accesso sia ai file remoti che a quelli locali. Purtroppo è possibile che il codice identificativo del cliente "mjb" possa coincidere con il codice identificativo di un altro cliente sulla macchina remota. Pertanto, gli amministratori di sistema sulle macchine in esecuzione sulla rete devono garantire che a ciascun utente venga assegnato un codice di identificazione univoco per l'intera rete o eseguire la conversione del codice al momento della formulazione di una richiesta di servizio di rete. In caso contrario, il processo associato avrà i diritti di un altro client sulla macchina remota.

Un problema più delicato è ottenere i diritti di superutente in relazione all'utilizzo di file remoti. Da un lato, il client superutente non dovrebbe avere gli stessi diritti sul sistema remoto per non fuorviare i controlli di sicurezza del sistema remoto. D'altra parte, alcuni programmi, se non vengono concessi i diritti di superutente, semplicemente non saranno in grado di funzionare. Un esempio di tale programma è il programma mkdir (vedi Capitolo 7), che crea una nuova directory. Il sistema remoto non consentirebbe al client di creare una nuova directory perché i diritti di superutente non sono attivi al momento dell'eliminazione. Il problema della creazione di directory remote serve come una seria ragione per rivedere la funzione di sistema mkdir nella direzione di espandere le sue capacità nello stabilire automaticamente tutte le connessioni necessarie per l'utente. Tuttavia, è ancora un problema comune che i programmi setuid (come il programma mkdir) ottengano privilegi di superutente sui file remoti. Forse la soluzione migliore a questo problema sarebbe quella di impostare caratteristiche aggiuntive per i file che descrivono l'accesso ad essi da parte di superutenti remoti; sfortunatamente, ciò richiederebbe modifiche alla struttura dell'indice del disco (in termini di aggiunta di nuovi campi) e creerebbe troppo disordine nei sistemi esistenti.

Se la subroutine aperta ha successo, la libreria locale lascia una nota corrispondente su questo in una struttura accessibile all'utente contenente l'indirizzo del nodo di rete, l'ID del processo satellite, il descrittore di file e altre informazioni simili. Le routine di lettura e scrittura della libreria determinano, in base al descrittore di file, se il file viene eliminato e, in tal caso, inviano un messaggio al satellite. Il processo client interagisce con il suo compagno in tutti i casi di accesso a funzioni di sistema che richiedono i servizi di una macchina remota. Se un processo accede a due file situati sulla stessa macchina remota, utilizza un satellite, ma se i file si trovano su macchine diverse, sono già utilizzati due satelliti: uno su ciascuna macchina. Vengono utilizzati due satelliti anche quando due processi accedono a un file su una macchina remota. Richiamando la funzione di sistema via satellite, il processo genera un messaggio che include il numero della funzione, il nome del percorso di ricerca e altre informazioni necessarie, simile a quella inclusa nella struttura del messaggio nel sistema con processori periferici.

Il meccanismo per eseguire operazioni sulla directory corrente è più complesso. Quando il processo seleziona una directory remota come quella corrente, la routine della libreria invia un messaggio al satellite, che cambia la directory corrente e la routine ricorda che la directory è stata cancellata. In tutti i casi in cui il nome del percorso di ricerca inizia con un carattere diverso da una barra (/), la subroutine invia il nome alla macchina remota, dove il processo satellite lo instrada dalla directory corrente. Se la directory corrente è locale, la routine passa semplicemente il nome del percorso di ricerca al kernel del sistema locale. La funzione chroot di sistema su una directory remota è simile, ma passa inosservata per il kernel locale; in senso stretto, il processo può ignorare questa operazione, poiché solo la libreria ne registra l'esecuzione.

Quando un processo chiama fork, la routine della libreria appropriata invia messaggi a ciascun satellite. I processi satellite si diramano e inviano i loro ID figlio al client genitore. Il processo client esegue la funzione del sistema fork, che trasferisce il controllo al figlio che genera; il figlio locale sta dialogando con il figlio satellite remoto i cui indirizzi sono memorizzati dalla routine della biblioteca. Questa interpretazione della funzione fork rende più facile per i processi satellite controllare i file aperti e le directory correnti. Quando il processo che lavora con i file remoti esce (chiamando la funzione exit), la subroutine invia messaggi a tutti i suoi satelliti remoti in modo che facciano lo stesso quando ricevono il messaggio. Alcuni aspetti dell'implementazione delle funzioni del sistema exec e exit sono discussi negli esercizi.

Il vantaggio di un collegamento Newcastle è che l'accesso di un processo ai file remoti diventa trasparente (invisibile all'utente), senza la necessità di apportare modifiche al kernel di sistema. Tuttavia, questo sviluppo presenta una serie di svantaggi. Innanzitutto, durante la sua implementazione, è possibile una diminuzione delle prestazioni del sistema. A causa dell'utilizzo della libreria C estesa, la dimensione della memoria utilizzata da ciascun processo aumenta, anche se il processo non accede ai file remoti; la libreria duplica le funzioni del kernel e richiede più spazio di memoria. L'aumento della dimensione dei processi allunga il periodo di avvio e può creare più contesa per le risorse di memoria, creando le condizioni per lo scarico e il paging più frequenti delle attività. Le richieste locali verranno eseguite più lentamente a causa dell'aumento della durata di ogni chiamata al kernel, e anche l'elaborazione delle richieste remote può essere rallentata, il costo del loro invio in rete aumenta. L'elaborazione aggiuntiva di richieste remote a livello di utente aumenta il numero di cambi di contesto, operazioni di scaricamento e scambio. Infine, per accedere ai file remoti, i programmi devono essere ricompilati utilizzando le nuove librerie; i vecchi programmi e i moduli oggetto forniti non saranno in grado di lavorare con file remoti senza di esso. Tutti questi svantaggi sono assenti dal sistema descritto nella sezione successiva.

13.3 FILE SYSTEM DISTRIBUITI "TRASPARENTI"

Il termine "allocazione trasparente" significa che gli utenti su una macchina possono accedere ai file su un'altra macchina senza rendersi conto che stanno attraversando i confini della macchina, proprio come sono sulla loro macchina quando passano da un file system all'altro attraversano i punti di montaggio. I nomi con cui i processi si riferiscono ai file situati su macchine remote sono simili ai nomi dei file locali: non ci sono caratteri distintivi in ​​essi. Nella configurazione mostrata in Figura 13.10, la directory "/usr/src" appartenente alla macchina B è "montata" nella directory "/usr/src" appartenente alla macchina A. lo stesso codice sorgente di sistema, tradizionalmente presente nella cartella "/ usr/src". Gli utenti in esecuzione sulla macchina A possono accedere ai file situati sulla macchina B utilizzando la sintassi familiare di scrittura dei nomi dei file (ad esempio: "/usr/src/cmd/login.c") e il kernel stesso decide se il file è remoto o locale . Gli utenti in esecuzione sulla macchina B hanno accesso ai propri file locali (non consapevoli che gli utenti della macchina A possono accedere agli stessi file), ma, a loro volta, non hanno accesso ai file che si trovano sulla macchina A. Naturalmente, sono possibili altre opzioni, in in particolare, quelli in cui tutti i sistemi remoti sono montati alla radice del sistema locale, in modo che gli utenti possano accedere a tutti i file su tutti i sistemi.

Figura 13.10. File system dopo il montaggio remoto

Le somiglianze tra il montaggio di filesystem locali e il consentire l'accesso a filesystem remoti hanno portato all'adattamento della funzione di montaggio ai filesystem remoti. In questo caso, il kernel ha a sua disposizione una tabella di montaggio in formato esteso. Eseguendo la funzione di montaggio, il kernel organizza una connessione di rete con una macchina remota e memorizza le informazioni che caratterizzano questa connessione nella tabella di montaggio.

Un problema interessante ha a che fare con i nomi di percorso che includono "..". Se un processo crea la directory corrente da un filesystem remoto, è più probabile che l'uso dei caratteri ".." nel nome restituisca il processo al filesystem locale piuttosto che accedere ai file sopra la directory corrente. Tornando ancora alla Figura 13.10, si noti che quando un processo appartenente alla macchina A, avendo precedentemente selezionato la directory corrente "/usr/src/cmd" che si trova nel file system remoto, eseguirà il comando

la directory corrente sarà la directory radice della macchina A, non la macchina B. L'algoritmo namei in esecuzione nel kernel del sistema remoto, dopo aver ricevuto la sequenza di caratteri "..", verifica se il processo chiamante è un agente del client process e, in caso affermativo, imposta, se il client sta trattando la directory di lavoro corrente come la radice del file system remoto.

La comunicazione con una macchina remota assume una delle due forme seguenti: una chiamata di procedura remota o una chiamata di funzione di sistema remoto. Nella prima forma, ogni procedura del kernel che si occupa di indici verifica se l'indice punta a un file remoto e, in caso affermativo, invia una richiesta alla macchina remota per eseguire l'operazione specificata. Questo schema si inserisce naturalmente nella struttura astratta di supporto per file system di vario tipo, descritta nella parte finale del Capitolo 5. Pertanto, un accesso a un file remoto può avviare il trasferimento di più messaggi sulla rete, il cui numero è determinato dal numero di operazioni implicite sul file, con un corrispondente aumento del tempo di risposta alla richiesta, tenuto conto del tempo di attesa accettato in rete. Ogni insieme di operazioni remote include almeno azioni per il blocco dell'indice, il conteggio dei riferimenti, ecc. Al fine di migliorare il modello, sono state proposte varie soluzioni di ottimizzazione relative alla combinazione di più operazioni in un'unica query (messaggio) e al buffering dei dati più importanti (cm. ).

Figura 13.11. Apertura di un file remoto

Considera un processo che apre un file remoto "/usr/src/cmd/login.c", dove "src" è il punto di montaggio. Analizzando il nome del file (usando lo schema namei-iget), il kernel rileva che il file è stato cancellato e invia una richiesta alla macchina host per ottenere l'indice bloccato. Ricevuta la risposta desiderata, il kernel locale crea una copia dell'indice in memoria corrispondente al file remoto. Quindi il kernel verifica i diritti di accesso necessari al file (per la lettura, ad esempio) inviando un altro messaggio alla macchina remota. L'algoritmo aperto continua in piena conformità con il piano delineato nel Capitolo 5, inviando messaggi alla macchina remota secondo necessità, fino a quando l'algoritmo non è completo e l'indice viene liberato. La relazione tra le strutture dati del kernel al completamento dell'algoritmo aperto è mostrata nella Figura 13.11.

Se il client chiama la funzione di lettura del sistema, il kernel del client blocca l'indice locale, emette un blocco sull'indice remoto, una richiesta di lettura, copia i dati nella memoria locale, invia una richiesta per liberare l'indice remoto e libera l'indice locale . Questo schema è coerente con la semantica del kernel uniprocessore esistente, ma la frequenza di utilizzo della rete (chiamate multiple a ciascuna funzione di sistema) riduce le prestazioni dell'intero sistema. Tuttavia, per ridurre il flusso di messaggi sulla rete, è possibile combinare più operazioni in un'unica richiesta. Nell'esempio con la funzione read, il client può inviare al server una richiesta di "lettura" generale e il server stesso decide di prendere e rilasciare l'indice quando viene eseguito. La riduzione del traffico di rete può essere ottenuta anche utilizzando buffer remoti (come discusso sopra), ma è necessario prestare attenzione per garantire che le funzioni del file di sistema che utilizzano questi buffer vengano eseguite correttamente.

Nella seconda forma di comunicazione con una macchina remota (una chiamata a una funzione di sistema remoto), il kernel locale rileva che la funzione di sistema è correlata a un file remoto e invia i parametri specificati nella sua chiamata al sistema remoto, che esegue il funzione e restituisce i risultati al client. La macchina client riceve i risultati dell'esecuzione della funzione ed esce dallo stato di chiamata. La maggior parte delle funzioni di sistema può essere eseguita utilizzando una sola richiesta di rete e ricevendo una risposta dopo un tempo ragionevole, ma non tutte le funzioni rientrano in questo modello. Quindi, ad esempio, alla ricezione di determinati segnali, il kernel crea un file per il processo chiamato "core" (Capitolo 7). La creazione di questo file non è associata a una funzione di sistema specifica, ma finisce per eseguire diverse operazioni come la creazione di un file, il controllo dei permessi e l'esecuzione di una serie di scritture.

Nel caso della funzione di sistema aperto, la richiesta di esecuzione della funzione inviata alla macchina remota include la parte del nome del file rimasta dopo aver escluso i componenti del nome del percorso di ricerca che contraddistinguono il file remoto, oltre a vari flag. Nel precedente esempio di apertura del file "/usr/src/cmd/login.c", il kernel invia il nome "cmd / login.c" alla macchina remota. Il messaggio include anche credenziali come codici di identificazione utente e gruppo, necessari per verificare le autorizzazioni dei file su una macchina remota. Se viene ricevuta una risposta dalla macchina remota che indica una funzione di apertura riuscita, il kernel locale recupera un indice libero nella memoria della macchina locale e lo contrassegna come indice del file remoto, memorizza le informazioni sulla macchina remota e l'indice remoto e alloca regolarmente una nuova voce nella tabella dei file. Rispetto all'indice reale sulla macchina remota, l'indice posseduto dalla macchina locale è formale e non viola la configurazione del modello, che è sostanzialmente la stessa della configurazione utilizzata quando si chiama la procedura remota (Figura 13.11). Se una funzione chiamata da un processo accede a un file remoto tramite il suo descrittore, il kernel locale sa dall'indice (locale) che il file è remoto, formula una richiesta che include la funzione chiamata e la invia alla macchina remota. La richiesta contiene un puntatore all'indice remoto mediante il quale il processo satellite può identificare il file remoto stesso.

Dopo aver ricevuto il risultato dell'esecuzione di qualsiasi funzione di sistema, il kernel può ricorrere ai servizi di un programma speciale per elaborarlo (al termine del quale il kernel finirà di lavorare con la funzione), poiché l'elaborazione locale dei risultati utilizzata in un sistema uniprocessore non è sempre adatto per un sistema con più processori. Di conseguenza, sono possibili cambiamenti nella semantica degli algoritmi di sistema, volti a fornire supporto per l'esecuzione di funzioni di sistema remote. Tuttavia, allo stesso tempo, nella rete circola un flusso minimo di messaggi, garantendo il tempo minimo di risposta del sistema alle richieste in entrata.

13.4 MODELLO DISTRIBUITO SENZA PROCESSI DI TRASFERIMENTO

L'uso di processi di trasferimento (processi satellite) in un sistema distribuito trasparente rende più facile tenere traccia dei file eliminati, ma la tabella dei processi del sistema remoto è sovraccaricata di processi satellite che sono inattivi per la maggior parte del tempo. In altri schemi, vengono utilizzati processi server speciali per elaborare le richieste remote (vedi e). Il sistema remoto dispone di un insieme (pool) di processi server che assegna di volta in volta per elaborare le richieste remote in entrata. Dopo aver elaborato la richiesta, il processo del server torna al pool ed entra in uno stato pronto per elaborare altre richieste. Il server non salva il contesto utente tra due chiamate, perché può elaborare richieste da più processi contemporaneamente. Pertanto, ogni messaggio in arrivo da un processo client deve includere informazioni sul suo ambiente di esecuzione, ovvero: codici identificativi dell'utente, directory corrente, segnali, ecc. funzioni.

Quando un processo apre un file remoto, il kernel remoto assegna un indice per i successivi collegamenti al file. La macchina locale mantiene una tabella descrittore di file personalizzata, una tabella di file e una tabella di indice con un insieme regolare di record, con una voce della tabella di indice che identifica la macchina remota e l'indice remoto. Nei casi in cui una funzione di sistema (ad esempio read) utilizza un descrittore di file, il kernel invia un messaggio che punta all'indice remoto precedentemente assegnato e trasferisce le informazioni relative al processo: codice identificativo utente, dimensione massima del file, ecc. la macchina ha un processo server a sua disposizione, l'interazione con il client assume la forma descritta in precedenza, tuttavia, la connessione tra il client e il server viene stabilita solo per la durata della funzione del sistema.

L'utilizzo di server anziché di processi satellitari può rendere più difficile la gestione del traffico dati, dei segnali e dei dispositivi remoti. Un numero elevato di richieste a una macchina remota in assenza di un numero sufficiente di server dovrebbe essere messo in coda. Ciò richiede un protocollo di livello superiore rispetto a quello utilizzato sulla rete principale. Nel modello satellitare, invece, la sovrasaturazione viene eliminata perché tutte le richieste dei client vengono elaborate in modo sincrono. Un client può avere al massimo una richiesta in sospeso.

Anche l'elaborazione di segnali che interrompono l'esecuzione di una funzione di sistema è complicata quando si utilizzano i server, poiché la macchina remota deve cercare il server appropriato che serve l'esecuzione della funzione. È anche possibile che, a causa dell'occupazione di tutti i server, una richiesta di una funzione di sistema sia in attesa di elaborazione. Le condizioni per l'emergere della concorrenza si verificano anche quando il server restituisce il risultato della funzione di sistema al processo chiamante e la risposta del server include l'invio di un corrispondente messaggio di segnalazione attraverso la rete. Ogni messaggio deve essere contrassegnato in modo che il sistema remoto possa riconoscerlo e, se necessario, terminare i processi del server. Quando si utilizzano i satelliti, viene automaticamente identificato il processo che gestisce l'adempimento della richiesta del cliente e, in caso di segnale in arrivo, non è difficile verificare se la richiesta è stata elaborata o meno.

Infine, se una funzione di sistema chiamata dal client provoca una pausa indefinita del server (ad esempio, durante la lettura di dati da un terminale remoto), il server non può elaborare altre richieste per liberare il pool di server. Se più processi accedono a dispositivi remoti contemporaneamente e se il numero di server è limitato dall'alto, c'è un collo di bottiglia abbastanza tangibile. Ciò non accade con i satelliti, poiché un satellite è assegnato a ciascun processo client. Un altro problema con l'utilizzo di server per dispositivi remoti sarà trattato nell'Esercizio 13.14.

Nonostante i vantaggi offerti dall'uso dei processi satellitari, la necessità di voci libere nella tabella dei processi diventa in pratica così acuta che nella maggior parte dei casi i servizi dei processi server vengono ancora utilizzati per elaborare le richieste remote.

Figura 13.12. Schema concettuale di interazione con file remoti a livello di kernel

13.5 CONCLUSIONI

In questo capitolo abbiamo considerato tre schemi per lavorare con file situati su macchine remote, trattando i file system remoti come un'estensione di quello locale. Le differenze architettoniche tra questi layout sono mostrate nella Figura 13.12. Tutti loro, a loro volta, differiscono dai sistemi multiprocessore descritti nel capitolo precedente in quanto i processori qui non condividono la memoria fisica. Un sistema di processori periferici è costituito da un insieme strettamente accoppiato di processori che condividono le risorse di file del processore centrale. Una connessione di tipo Newcastle fornisce l'accesso nascosto ("trasparente") a file remoti, ma non tramite il kernel del sistema operativo, ma tramite l'uso di una speciale libreria C. Per questo motivo, tutti i programmi che intendono utilizzare questo tipo di collegamento devono essere ricompilati, il che, in generale, è un grave inconveniente di questo schema. La lontananza di un file è indicata tramite una sequenza speciale di caratteri che descrivono la macchina su cui si trova il file, e questo è un altro fattore che limita la portabilità dei programmi.

Nei sistemi distribuiti trasparenti, viene utilizzata una modifica della funzione di sistema di montaggio per accedere ai file remoti. Gli indici sul sistema locale sono contrassegnati come file remoti e il kernel locale invia un messaggio al sistema remoto descrivendo la funzione di sistema richiesta, i suoi parametri e l'indice remoto. La comunicazione in un sistema distribuito "trasparente" è supportata in due forme: sotto forma di chiamata a procedura remota (viene inviato un messaggio alla macchina remota contenente un elenco di operazioni associate all'indice) e sotto forma di chiamata a una funzione del sistema remoto (il messaggio descrive la funzione richiesta). La parte finale del capitolo discute le questioni relative all'elaborazione delle richieste remote utilizzando processi e server satellitari.

13.6 ESERCIZI

*1. Descrivere l'implementazione della funzione del sistema di uscita in un sistema con processori periferici. Qual è la differenza tra questo caso e quando il processo termina alla ricezione di un segnale non rilevato? In che modo il kernel dovrebbe scaricare il contenuto della memoria?

2. I processi non possono ignorare i segnali SIGKILL; Spiegare cosa succede nel sistema periferico quando il processo riceve tale segnale.

* 3. Descrivere l'implementazione della funzione di sistema exec su un sistema con processori periferici.

*4. In che modo il processore centrale dovrebbe distribuire i processi tra i processori periferici per bilanciare il carico complessivo?

*5. Cosa succede se il processore periferico non ha memoria sufficiente per ospitare tutti i processi scaricati su di esso? Come dovrebbe essere eseguito lo scarico e lo scambio dei processi nella rete?

6. Considera un sistema in cui le richieste a un file server remoto vengono inviate se viene trovato un prefisso speciale nel nome del file. Lascia che il processo chiami execl ("/../ sftig / bin / sh", "sh", 0); L'eseguibile si trova su una macchina remota, ma deve essere in esecuzione sul sistema locale. Spiegare come viene migrato il modulo remoto nel sistema locale.

7. Se l'amministratore ha bisogno di aggiungere nuove macchine a un sistema esistente con una connessione come Newcastle, qual è il modo migliore per informare i moduli della libreria C di questo?

*otto. Durante l'esecuzione della funzione exec, il kernel sovrascrive lo spazio degli indirizzi del processo, comprese le tabelle di libreria utilizzate dal collegamento Newcastle per tenere traccia dei collegamenti ai file remoti. Dopo aver eseguito la funzione, il processo deve mantenere la capacità di accedere a questi file tramite i loro vecchi descrittori. Descrivi l'implementazione di questo punto.

*nove. Come mostrato nella sezione 13.2, chiamare la funzione di sistema di uscita su sistemi con una connessione Newcastle provoca l'invio di un messaggio al processo compagno, costringendo quest'ultimo a terminare. Questo viene fatto a livello delle routine di libreria. Cosa succede quando un processo locale riceve un segnale che gli dice di uscire in modalità kernel?

*dieci. In un sistema con un collegamento Newcastle, in cui i file remoti sono identificati anteponendo al nome un prefisso speciale, come può un utente, specificando ".." (directory principale) come componente del nome file, attraversare il punto di montaggio remoto?

11. Sappiamo dal Capitolo 7 che vari segnali fanno sì che il processo scarichi il contenuto della memoria nella directory corrente. Cosa dovrebbe succedere se la directory corrente proviene dal file system remoto? Che risposta daresti se il sistema utilizzasse una relazione come Newcastle?

*12. Quali implicazioni avrebbe per i processi locali se tutti i processi satellite o server venissero rimossi dal sistema?

*13. Considera come implementare l'algoritmo di collegamento in un sistema distribuito trasparente, i cui parametri possono essere due nomi di file remoti, nonché l'algoritmo exec, associato all'esecuzione di diverse operazioni di lettura interne. Considera due forme di comunicazione: una chiamata di procedura remota e una chiamata di funzione di sistema remota.

*quattordici. Quando si accede al dispositivo, il processo server può entrare nello stato sospeso, dal quale verrà rimosso dal driver del dispositivo. Naturalmente, se il numero di server è limitato, il sistema non sarà più in grado di soddisfare le richieste della macchina locale. Elabora uno schema affidabile in base al quale non tutti i processi del server vengono sospesi in attesa del completamento dell'I/O relativo al dispositivo. La funzione di sistema non terminerà mentre tutti i server sono occupati.

Figura 13.13. Configurazione del server terminal

*15. Quando un utente accede al sistema, la disciplina della linea del terminale memorizza l'informazione che il terminale è un terminale operatore che guida un gruppo di processi. Per questo motivo, quando l'utente preme il tasto "break" sulla tastiera del terminale, tutti i processi del gruppo ricevono il segnale di interruzione. Si consideri una configurazione di sistema in cui tutti i terminali sono fisicamente collegati a una macchina, ma la registrazione dell'utente è implementata logicamente su altre macchine (Figura 13.13). In ogni caso, il sistema crea un processo getty per il terminale remoto. Se le richieste a un sistema remoto vengono elaborate da un insieme di processi server, notare che quando viene eseguita la procedura aperta, il server smette di attendere una connessione. Al termine della funzione open, il server torna al pool di server, interrompendo la connessione al terminale. Come viene attivato un segnale di interrupt premendo il tasto "break" inviato agli indirizzi dei processi inclusi nello stesso gruppo?

*16. La condivisione della memoria è una funzionalità inerente alle macchine locali. Da un punto di vista logico, l'allocazione di un'area comune di memoria fisica (locale o remota) può essere effettuata per processi appartenenti a macchine diverse. Descrivi l'implementazione di questo punto.

* 17. Il processo di paginazione e gli algoritmi di paginazione discussi nel Capitolo 9 presuppongono l'uso di un cercapersone locale. Quali modifiche dovrebbero essere apportate a questi algoritmi per poter supportare i dispositivi di offload remoto?

*diciotto. Supponiamo che la macchina remota (o la rete) subisca un arresto anomalo e che il protocollo del livello di rete locale registri questo fatto. Sviluppare uno schema di ripristino per un sistema locale che effettua richieste a un server remoto. Inoltre, sviluppa uno schema di ripristino per un sistema server che ha perso il contatto con i client.

*19. Quando un processo accede a un file remoto, è possibile che il processo attraversi più macchine alla ricerca del file. Prendi come esempio il nome "/ usr / src /uts / 3b2 / os", dove "/ usr" è la directory appartenente alla macchina A, "/ usr / src" è il punto di montaggio della radice della macchina B, " / usr / src / uts / 3b2 "è il punto di montaggio della radice della macchina C. Camminare attraverso più macchine fino alla sua destinazione finale è chiamato multihop. Tuttavia, se esiste una connessione di rete diretta tra le macchine A e C, l'invio di dati attraverso la macchina B sarebbe inefficiente. Descrivere le caratteristiche dell'implementazione del "multishopping" in un sistema con connessione Newcastle e in un sistema distribuito "trasparente".

Attualmente, tutti gli IS sviluppati per scopi commerciali hanno un'architettura distribuita, che implica l'uso di reti globali e/o locali.

Storicamente, l'architettura file-server è stata la prima a diffondersi, poiché la sua logica è semplice ed è più facile trasferire su tale architettura gli IS già in uso. Successivamente è stato trasformato in un'architettura server-client, che può essere interpretata come la sua logica continuazione. I moderni sistemi utilizzati nella rete globale INTERNET riguardano principalmente l'architettura degli oggetti distribuiti (vedi Fig. III‑15 )

Si può immaginare IS costituito dalle seguenti componenti (Fig. III-16)

III.03.2. a Applicazioni file server.

È storicamente la prima architettura distribuita (Fig. III-17). È organizzato in modo molto semplice: ci sono solo dati sul server e tutto il resto appartiene alla macchina client. Poiché le reti locali sono piuttosto economiche e poiché con tale architettura il software applicativo è autonomo, oggi viene spesso utilizzata tale architettura. Possiamo dire che questa è una variante dell'architettura client-server, in cui solo i file di dati si trovano sul server. Personal computer diversi interagiscono solo tramite un archivio dati comune, quindi i programmi scritti per un computer sono i più facili da adattare a tale architettura.

Professionisti:

Pro di un'architettura di file server:

Facilità di organizzazione;

Non contraddice i requisiti necessari affinché il database mantenga l'integrità e l'affidabilità.

Congestione della rete;

Risposta imprevedibile a una richiesta.

Questi svantaggi sono spiegati dal fatto che qualsiasi richiesta al database porta al trasferimento di quantità significative di informazioni sulla rete. Ad esempio, per selezionare una o più righe dalle tabelle, l'intera tabella viene scaricata sulla macchina client e il DBMS seleziona già lì. Il traffico di rete significativo è particolarmente carico dell'organizzazione dell'accesso remoto al database.

III.03.2. b Applicazioni client-server.

In questo caso, c'è una distribuzione delle responsabilità tra il server e il client. A seconda di come sono separati distinguere Grasso e thin client.

Nel modello thin client, tutto il lavoro applicativo e la gestione dei dati vengono eseguiti sul server. L'interfaccia utente in questi sistemi "migra" su un personal computer e l'applicazione software stessa svolge le funzioni di un server, ad es. esegue tutti i processi applicativi e gestisce i dati. Il modello thin client può essere implementato anche dove i client sono computer o workstation. I dispositivi di rete eseguono il browser Internet e l'interfaccia utente implementati all'interno del sistema.

Principale difetto modelli thin client: server e carico di rete elevati. Tutti i calcoli vengono eseguiti sul server e ciò può portare a un traffico di rete significativo tra il client e il server. C'è abbastanza potenza di calcolo nei computer moderni, ma non è praticamente utilizzata nel modello / thin client della banca

Al contrario, il modello thick client utilizza la potenza di elaborazione delle macchine locali: l'applicazione stessa viene posizionata sul computer client. Un esempio di questo tipo di architettura sono i sistemi ATM, in cui l'ATM è il client e il server è il computer centrale che serve il database dei conti dei clienti.

III.03.2. c Architettura client-server a due e tre livelli.

Tutte le architetture discusse sopra sono a due livelli. Differenziano tra il livello client e il livello server. A rigor di termini, l'IC si compone di tre livelli logici:

· Livello utente;

Livello di applicazione:

· Livello dati.

Pertanto, in un modello a due livelli, in cui sono coinvolti solo due livelli, si verificano problemi di scalabilità e prestazioni se si sceglie il modello thin client o problemi di gestione del sistema se si sceglie il modello thick client. Questi problemi possono essere evitati se applichiamo un modello composto da tre livelli, dove due di essi sono server (Fig. III-21).

Server dati

Infatti, il server delle applicazioni e il server dei dati possono trovarsi sulla stessa macchina, ma non possono svolgere le funzioni l'uno dell'altro. La cosa bella del modello a tre livelli è che separa logicamente l'esecuzione dell'applicazione e la gestione dei dati.

Tabella III-5 Applicazione di diversi tipi di architetture

Architettura	Applicazione
Thin client a due livelli	1 Sistemi legacy in cui non è consigliabile separare l'esecuzione dell'applicazione e la gestione dei dati. 2 Applicazioni ad alta intensità di calcolo con poca gestione dei dati. 3 Applicazioni con grandi quantità di dati, ma poca computazione.
Cliente di spessore a due livelli	1 Applicazioni in cui l'utente richiede un'elaborazione dati intensiva, ovvero la visualizzazione dei dati. 2 Applicazioni con un insieme relativamente costante di funzioni utente applicate a un ambiente di sistema ben gestito.
Client-server a tre livelli	1 Grandi applicazioni con celle e migliaia di client 2 Applicazioni in cui sia i dati che i metodi di elaborazione cambiano frequentemente. 3 Applicazioni che integrano dati da più fonti.

Questo modello è adatto a molti tipi di applicazioni, ma limita gli sviluppatori IS che devono decidere dove fornire servizi, fornire supporto per la scalabilità e sviluppare strumenti per connettere nuovi clienti.

III.03.2. d Architettura a oggetti distribuiti.

Un approccio più generale è fornito da un'architettura a oggetti distribuiti, di cui gli oggetti sono i componenti principali. Forniscono una serie di servizi attraverso le loro interfacce. Altri oggetti inviano richieste senza differenziare tra client e server. Gli oggetti possono trovarsi su diversi computer in una rete e interagire tramite middleware, simile al bus di sistema, che consente di connettere dispositivi diversi e supportare la comunicazione tra dispositivi hardware.

…

Gestore driver ODBC

Pilota 1

Autista K

DB 1

DB K

Lavorare con SQL

…

L'architettura ODBC include componenti:

1. Applicazione (es. IS). Esegue compiti: richiede una connessione all'origine dati, invia query SQL all'origine dati, descrive l'area di archiviazione e il formato per le query SQL, gestisce gli errori e ne informa l'utente, esegue il commit o ripristina le transazioni, richiede una connessione al fonte di dati.

2. Gestione dispositivi. Carica i driver su richiesta delle applicazioni, offre un'unica interfaccia per tutte le applicazioni e l'interfaccia di amministrazione ODBC è la stessa e indipendentemente dal DBMS con cui interagirà l'applicazione. Il Driver Manager fornito da Microsoft è una libreria a caricamento dinamico (DLL).

3. Il driver dipende dal DBMS. Un driver ODBC è una libreria a collegamento dinamico (DLL) che implementa le funzioni ODBC e interagisce con un'origine dati. Un driver è un programma che elabora una richiesta per una funzione specifica di un DBMS (può modificare le richieste in conformità con il DBMS) e restituisce il risultato all'applicazione. Ogni DBMS che supporta la tecnologia ODBC deve fornire agli sviluppatori di applicazioni un driver per quel DBMS.

4. L'origine dati contiene le informazioni di controllo specificate dall'utente, informazioni sull'origine dati e viene utilizzata per accedere a un DBMS specifico. In questo caso vengono utilizzati i mezzi del sistema operativo e della piattaforma di rete.

Modello dinamico

Questo modello assume molti aspetti, per i quali vengono utilizzati almeno 5 diagrammi in UML, vedi pp. 2.04.2- 2.04.5.

Considera l'aspetto gestionale. Il modello di governance integra i modelli strutturali.

Indipendentemente da come viene descritta la struttura del sistema, essa consiste in un insieme di unità strutturali (funzioni o oggetti). Affinché funzionino nel loro insieme, devono essere controllati e non ci sono informazioni di controllo nei diagrammi statici. I modelli di controllo progettano il flusso di controllo tra i sistemi.

Esistono due tipi principali di controllo nei sistemi software.

1. Gestione centralizzata.

2. Gestione basata sugli eventi.

La gestione centralizzata può essere:

· gerarchico- sulla base del principio "call-return" (è così che funzionano più spesso i programmi educativi)

· Modello di spedizioniere che viene utilizzato per i sistemi paralleli.

V modelli di spedizioniere si presume che uno dei componenti del sistema sia un dispatcher. Gestisce sia l'avvio e l'arresto dei sistemi che il coordinamento del resto dei processi nel sistema. I processi possono essere eseguiti in parallelo tra loro. Un processo fa riferimento a un programma, sottosistema o procedura attualmente in esecuzione. Questo modello può essere applicato anche in sistemi sequenziali, dove il programma di controllo chiama singoli sottosistemi in funzione di alcune variabili di stato (tramite l'operatore Astuccio).

Gestione di eventi presuppone l'assenza di qualsiasi sottoprogramma responsabile della gestione. Il controllo viene effettuato da eventi esterni: pressione di un pulsante del mouse, pressione di una tastiera, modifica delle letture del sensore, modifica delle letture del timer, ecc. Ogni evento esterno viene codificato e inserito nella coda degli eventi. Se viene fornita una reazione a un evento in coda, viene chiamata la procedura (subroutine) che esegue la reazione a questo evento. Gli eventi a cui reagisce il sistema possono verificarsi sia in altri sottosistemi che nell'ambiente esterno del sistema.

Un esempio di tale gestione è l'organizzazione delle applicazioni in Windows.

Tutti i modelli strutturali descritti in precedenza possono essere implementati utilizzando la gestione centralizzata o la gestione basata sugli eventi.

Interfaccia utente

Quando si sviluppa un modello di interfaccia, si dovrebbero prendere in considerazione non solo i compiti del software progettato, ma anche le caratteristiche del cervello associate alla percezione delle informazioni.

III.03.4. a Caratteristiche psicofisiche di una persona associate alla percezione e all'elaborazione delle informazioni.

La parte del cervello, che può essere convenzionalmente chiamata processore di percezione, costantemente, senza la partecipazione della coscienza, elabora le informazioni in arrivo, le confronta con l'esperienza passata e le archivia.

Quando un'immagine visiva attira la nostra attenzione, allora l'informazione che ci interessa arriva nella memoria a breve termine. Se la nostra attenzione non è stata attratta, le informazioni nella memoria scompaiono, sostituite dalle seguenti parti.

In ogni momento, il focus dell'attenzione può essere fissato in un punto, quindi se diventa necessario seguire contemporaneamente diverse situazioni, il focus si sposta da un oggetto tracciato all'altro. Allo stesso tempo, l'attenzione è dispersa e alcuni dettagli potrebbero essere trascurati. È anche significativo che la percezione sia in gran parte basata sulla motivazione.

Quando cambi l'inquadratura, il cervello si blocca per un po': padroneggia una nuova immagine, evidenziando i dettagli più significativi. Ciò significa che se hai bisogno di una risposta rapida da parte dell'utente, non dovresti cambiare le immagini bruscamente.

La memoria a breve termine è il collo di bottiglia nel sistema di elaborazione delle informazioni di una persona. La sua capacità è di 7 ± 2 oggetti non collegati. Le informazioni non reclamate vengono memorizzate al suo interno per non più di 30 secondi. Per non dimenticare nessuna informazione importante per noi, di solito ce la ripetiamo, aggiornando le informazioni nella memoria a breve termine. Pertanto, quando si progettano interfacce, va tenuto presente che la stragrande maggioranza trova difficile, ad esempio, ricordare e inserire numeri contenenti più di cinque cifre su un'altra schermata.

Sebbene la capacità e il tempo di archiviazione della memoria a lungo termine siano illimitati, l'accesso alle informazioni non è facile. Il meccanismo per estrarre informazioni dalla memoria a lungo termine è di natura associativa. Per migliorare la memorizzazione delle informazioni, è legata ai dati che la memoria già immagazzina e ne facilita l'ottenimento. Poiché l'accesso alla memoria a lungo termine è difficile, è consigliabile aspettarsi che l'utente non ricordi le informazioni, ma sul fatto che l'utente le riconoscerà.

III.03.4. b Criteri di base per la valutazione delle interfacce

Numerosi sondaggi e sondaggi condotti dalle principali società di sviluppo software hanno dimostrato che gli utenti apprezzano un'interfaccia:

1) facilità di mastering e memorizzazione - stimare in modo specifico il tempo di mastering e la durata della conservazione delle informazioni e della memoria;

2) la velocità di raggiungimento dei risultati durante l'utilizzo del sistema, determinata dal numero di comandi e impostazioni immessi o selezionati dal mouse;

3) soddisfazione soggettiva per il funzionamento del sistema (facilità d'uso, fatica, ecc.).

Inoltre, per gli utenti professionali che lavorano costantemente con lo stesso pacchetto, il secondo e il terzo criterio vengono rapidamente al primo posto e per gli utenti non professionisti che lavorano periodicamente con il software ed eseguono attività relativamente semplici: il primo e il terzo.

Da questo punto di vista, oggi le migliori caratteristiche per gli utenti professionali sono le interfacce con navigazione libera e per gli utenti non professionali le interfacce a manipolazione diretta. È stato a lungo notato che quando si esegue un'operazione di copia di file, a parità di altre condizioni, la maggior parte dei professionisti utilizza shell come Far, mentre i non professionisti utilizzano il "trascina e rilascia" di Windows.

III.03.4. c Tipi di interfacce utente

Si distinguono i seguenti tipi di interfacce utente:

Primitivo

Navigazione gratuita

Manipolazione diretta.

L'interfaccia è primitiva

Primitivo si chiama interfaccia che organizza l'interazione con l'utente e viene utilizzata in modalità console. L'unica deviazione dal processo sequenziale fornito dai dati è il ciclo attraverso più set di dati.

Interfaccia del menù.

A differenza dell'interfaccia primitiva, consente all'utente di selezionare un'operazione da un apposito elenco visualizzato dal programma. Queste interfacce presuppongono l'implementazione di molti scenari di lavoro, la sequenza di azioni in cui è determinata dagli utenti. L'organizzazione ad albero del menu suggerisce che è difficile trovare un elemento su più di due livelli di menu.

(Materiale del sito http://se.math.spbu.ru)

Introduzione.

Al giorno d'oggi, sono distribuiti praticamente tutti i grandi sistemi software. Sistema distribuito- un sistema in cui l'elaborazione delle informazioni non è concentrata su un computer, ma è distribuita su più computer. Nella progettazione di sistemi distribuiti, che ha molto in comune con la progettazione del software in generale, ci sono ancora alcune specificità da considerare.

Ci sono sei caratteristiche principali dei sistemi distribuiti.

1. Condivisione di risorse. I sistemi distribuiti consentono la condivisione di risorse sia hardware (dischi rigidi, stampanti) che software (file, compilatori).
2. Apertura.È la capacità di espandere il sistema aggiungendo nuove risorse.
3. Parallelismo.Nei sistemi distribuiti, più processi possono essere eseguiti contemporaneamente su diversi computer della rete. Questi processi possono interagire mentre sono in esecuzione.
4. Scalabilità . Sotto scalabilità si comprende la possibilità di aggiungere nuove proprietà e metodi.
5. Tolleranza ai guasti. La presenza di più computer consente la duplicazione delle informazioni e la resistenza ad alcuni errori hardware e software. I sistemi distribuiti possono supportare funzionalità parziali in caso di errore. Un guasto completo del sistema si verifica solo con errori di rete.
6. Trasparenza.Agli utenti viene fornito pieno accesso alle risorse nel sistema, mentre allo stesso tempo vengono nascoste le informazioni sulla distribuzione delle risorse in tutto il sistema.

I sistemi distribuiti presentano anche una serie di svantaggi.

1. Complessità... È molto più difficile comprendere e valutare le proprietà dei sistemi distribuiti in generale e sono più difficili da progettare, testare e mantenere. Inoltre, le prestazioni del sistema dipendono dalla velocità della rete e non dai singoli processori. La riallocazione delle risorse può modificare in modo significativo la velocità del sistema.
2. Sicurezza... In genere, è possibile accedere al sistema da diverse macchine, i messaggi sulla rete possono essere monitorati e intercettati. Pertanto, in un sistema distribuito, è molto più difficile mantenere la sicurezza.
3. Controllabilità... Il sistema può essere costituito da diversi tipi di computer sui quali possono essere installate diverse versioni di sistemi operativi. Gli errori su una macchina possono propagarsi ad altre macchine in modo imprevedibile.
4. Imprevedibilità ... La reazione dei sistemi distribuiti ad alcuni eventi è imprevedibile e dipende dal carico completo del sistema, dalla sua organizzazione e dal carico di rete. Poiché questi parametri possono cambiare costantemente, quindi, il tempo di risposta alla richiesta può differire notevolmente dal tempo.

Da queste carenze, puoi vedere che durante la progettazione di sistemi distribuiti sorgono una serie di problemi che devono essere considerati dagli sviluppatori.

1. Identificazione delle risorse ... Le risorse nei sistemi distribuiti si trovano su computer diversi, quindi il sistema di denominazione delle risorse dovrebbe essere pensato in modo che gli utenti possano accedere facilmente e fare riferimento alle risorse di cui hanno bisogno. Un esempio è il sistema URL (Uniform Resource Locator), che definisce i nomi delle pagine Web.
2. Comunicazione... L'operatività universale di Internet e l'implementazione efficiente dei protocolli TCP/IP in Internet per la maggior parte dei sistemi distribuiti sono esempi del modo più efficace di organizzare la comunicazione tra computer. Tuttavia, in alcuni casi in cui sono richieste prestazioni o affidabilità speciali, è possibile utilizzare strumenti specializzati.
3. Qualità del servizio di sistema ... Questo parametro riflette le prestazioni, l'integrità e l'affidabilità. Numerosi fattori influiscono sulla qualità del servizio: la distribuzione dei processi, delle risorse, dell'hardware e l'adattabilità del sistema.
4. Architettura software ... L'architettura software descrive la distribuzione delle funzioni di sistema tra i componenti del sistema, nonché la distribuzione di questi componenti tra i processori. Se è necessario mantenere un servizio di sistema di alta qualità, la scelta dell'architettura giusta è fondamentale.

La sfida per i progettisti di sistemi distribuiti consiste nel progettare software e hardware per fornire tutte le caratteristiche richieste di un sistema distribuito. Ciò richiede la conoscenza dei vantaggi e degli svantaggi delle varie architetture di sistemi distribuiti. Esistono tre tipi di architetture di sistema distribuito.

1. Architettura client/server ... In questo modello, il sistema può essere pensato come un insieme di servizi forniti dai server ai client. In tali sistemi, i server ei client differiscono in modo significativo l'uno dall'altro.
2. Architettura a tre livelli ... In questo modello, il server non fornisce servizi ai client direttamente, ma tramite il server della logica aziendale.

Si è detto più di una volta sui primi due modelli, soffermiamoci più in dettaglio sul terzo.

1. Architettura a oggetti distribuiti ... In questo caso, non ci sono differenze tra server e client e il sistema può essere pensato come un insieme di oggetti interagenti, la cui posizione non ha molta importanza. Non c'è distinzione tra il fornitore di servizi e i suoi utenti.

Questa architettura è ampiamente utilizzata oggi ed è anche chiamata architettura dei servizi web. Un servizio web è un'applicazione accessibile su Internet e fornisce alcuni servizi, la cui forma è indipendente dal provider (poiché viene utilizzato il formato dati universale - XML) e dalla piattaforma operativa. Attualmente, ci sono tre diverse tecnologie che supportano il concetto di sistemi a oggetti distribuiti. Queste sono le tecnologie EJB, CORBA e DCOM.

Innanzitutto, alcune parole su cosa sia XML in generale. XML è un formato di dati generico utilizzato per fornire servizi Web. I servizi Web sono basati su standard e protocolli aperti: SOAP, UDDI e WSDL.

1. SAPONE ( Il Simple Object Access Protocol, sviluppato dal W3C, definisce il formato per le richieste ai servizi Web. I messaggi tra un servizio Web e il suo utente sono impacchettati nelle cosiddette buste SOAP (a volte chiamate anche buste XML). Il messaggio stesso può contenere una richiesta di eseguire un'azione o una risposta, il risultato di questa azione.
2. WSDL (linguaggio di descrizione del servizio Web).L'interfaccia del servizio Web è descritta nei documenti WSDL (e WSDL è un sottoinsieme di XML). Prima di distribuire un servizio, lo sviluppatore ne compone la descrizione in linguaggio WSDL, specifica l'indirizzo del servizio Web, i protocolli supportati, un elenco di operazioni consentite e i formati di richiesta e risposta.
3. UDDI (Descrizione Universale, Scoperta e Integrazione) - Protocollo di ricerca dei servizi Web Internet ( http://www.uddi.org/). È un registro delle imprese in cui i fornitori di servizi Web registrano i servizi e gli sviluppatori trovano i servizi che devono includere nelle loro applicazioni.

Dal discorso, può sembrare che i servizi Web siano la soluzione migliore e incontrastata, e l'unica questione è la scelta degli strumenti di sviluppo. Tuttavia, non lo è. Esiste un'alternativa ai servizi Web, il Web semantico, di cui il creatore del WWW Tim Berners-Lee ha parlato cinque anni fa.

Se l'obiettivo dei servizi Web è facilitare la comunicazione tra le applicazioni, il Web semantico è progettato per risolvere un problema molto più complesso: utilizzare meccanismi di metadati per aumentare l'efficienza del valore delle informazioni che possono essere trovate sul Web. Questo può essere fatto abbandonando l'approccio orientato ai documenti a favore di quello orientato agli oggetti.

Bibliografia

1. SomervilleI. Ingegneria del software.
2. Dranitsa A. Java vs. .NET. - "Computer", # 516.
3. Risorse Internet.