Protocollo rpc. Il meccanismo di chiamata di procedura remota è RPC. Compila il campo del titolo

Chiamata di procedure remote RPC Il concetto di chiamare procedure remote L'idea di chiamare procedure remote Chiamata di procedura remota - RPC è di estendere il meccanismo ben noto e comprensibile per il trasferimento di controllo e dati all'interno di un programma in esecuzione su una macchina al trasferimento di controllo e dati sulla rete. Gli strumenti di chiamata di procedura remota sono progettati per facilitare l'organizzazione del calcolo distribuito.La massima efficienza dell'uso di RPC si ottiene in quelle applicazioni in cui esiste una connessione interattiva tra componenti remoti con un tempo di risposta breve e una quantità relativamente piccola di dati trasmessi.

Tali applicazioni sono chiamate orientate RPC. Le caratteristiche della chiamata delle procedure locali sono l'asimmetria, ovvero una delle parti interagenti è l'iniziatore del sincronismo, ovvero l'esecuzione della procedura di chiamata si interrompe quando viene emessa la richiesta e riprende solo dopo il ritorno dalla procedura chiamata. L'implementazione delle chiamate remote è molto più complicata rispetto all'implementazione delle chiamate di procedure locali.

Innanzitutto, poiché le procedure di chiamata e chiamata vengono eseguite su macchine diverse, hanno spazi di indirizzi diversi e ciò crea problemi quando si passano parametri e risultati, soprattutto se le macchine non sono identiche. Poiché RPC non può contare sulla memoria condivisa, questo significa che i parametri RPC non devono contenere puntatori a celle di memoria non stack e che i valori dei parametri devono essere copiati da un computer a un altro.

La differenza successiva tra RPC e la chiamata locale è che utilizza necessariamente il sistema di comunicazione sottostante, ma ciò non dovrebbe essere chiaramente visibile né nella definizione delle procedure né nelle procedure stesse. La lontananza introduce ulteriori problemi. L'esecuzione del programma chiamante e la procedura locale chiamata in una macchina sono implementate come parte di un singolo processo, ma almeno due processi sono coinvolti nell'implementazione RPC - uno in ogni macchina.

Nel caso in cui uno di essi si arresti in modo anomalo, possono verificarsi le seguenti situazioni nel caso in cui una procedura di chiamata causi accidentalmente l'estinzione di procedure remote e, nel caso di un completamento di emergenza di procedure remote, le procedure di chiamata non riuscite attenderanno la risposta dalle procedure remote senza alcun risultato. problemi associati all'eterogeneità dei linguaggi di programmazione e delle strutture di dati degli ambienti operativi e delle strutture di chiamata supportate in un programmatore di un solo linguaggio Il supporto non è supportato allo stesso modo in tutte le altre lingue.

La diffusa tecnologia RPC che sta alla base di molti sistemi operativi distribuiti risolve questi e alcuni altri problemi. Operazioni RPC di base Per comprendere il funzionamento di RPC, prenderemo prima in considerazione la possibilità di effettuare una chiamata di procedura locale in una macchina normale che lavora in modo autonomo.Per esempio, essere un conteggio delle chiamate di sistema leggere fd, buf, nbytes dove fd è un numero intero, buf è un array di caratteri, nbytes è un numero intero .

Per effettuare una chiamata, la procedura di chiamata inserisce i parametri nello stack nell'ordine inverso della Figura 3.1. Dopo che la chiamata di lettura è stata completata, inserisce il valore di ritorno nel registro, sposta l'indirizzo di ritorno e restituisce il controllo alla procedura di chiamata, che seleziona i parametri dallo stack, riportandolo al suo stato originale. Si noti che in C, i parametri possono essere richiamati per riferimento per nome o per valore. In relazione alla procedura chiamata, i valori dei parametri sono variabili locali inizializzabili.

La procedura chiamata può modificarli e ciò non influirà sul valore degli originali di queste variabili nella procedura di chiamata. Se un puntatore a una variabile viene passato alla procedura chiamata, la modifica del valore di questa variabile mediante la procedura chiamata comporta la modifica del valore di questa variabile per la procedura di chiamata, fatto molto significativo per RPC. Esiste anche un altro meccanismo di passaggio dei parametri che non viene utilizzato in C. Si chiama ripristino call-by-copy e consiste nella necessità per il chiamante di copiare le variabili nello stack come valori e quindi di copiarle dopo che la chiamata è stata effettuata sui valori originali della procedura di chiamata.

La decisione sul meccanismo di trasferimento dei parametri da utilizzare viene presa dagli sviluppatori del linguaggio. A volte dipende dal tipo di dati da trasferire, ad esempio in C, i dati interi e altri dati scalari vengono sempre passati per valore e gli array per riferimento.

Fig. 3.1. a Stack prima di eseguire la chiamata in lettura b Stack durante l'esecuzione della procedura sullo Stack dopo il ritorno al programma chiamante L'idea alla base di RPC è di rendere la chiamata di procedura remota il più possibile simile alla chiamata di procedura locale. In altre parole, rendere l'RPC trasparente alla procedura di chiamata non è necessario sapere che la procedura chiamata si trova su un'altra macchina e viceversa: l'RPC raggiunge la trasparenza nel modo seguente.

Quando la procedura chiamata è veramente remota, un'altra versione della procedura, chiamata stub del client stub, viene collocata nella libreria invece della procedura locale - uno stub. Come la procedura originale, lo stub viene chiamato usando la sequenza di chiamata come in Figura 3.1 e si verifica un interrupt quando si accede al kernel. Solo, a differenza della procedura originale, non inserisce i parametri nei registri e non richiede i dati dal kernel, ma genera un messaggio da inviare al kernel della macchina remota. Passaggi di esecuzione RPC L'interazione dei componenti software quando si effettua una chiamata di procedura remota è illustrata nella Figura 3.2. Dopo che lo stub client è stato chiamato dal programma client, la sua prima attività è riempire il buffer con il messaggio inviato.

In alcuni sistemi, lo stub client ha un singolo buffer di lunghezza fissa, che viene riempito ogni volta dall'inizio quando arriva ogni nuova richiesta. Su altri sistemi, un buffer di messaggi è un pool di buffer per singoli campi di messaggi, alcuni dei quali sono già pieni.

Questo metodo è particolarmente adatto per i casi in cui il pacchetto ha un formato costituito da un gran numero di campi, ma i valori di molti di questi campi non cambiano da chiamata a chiamata. Quindi, i parametri dovrebbero essere convertiti nel formato appropriato e inseriti nel buffer dei messaggi, a questo punto il messaggio è pronto per essere trasmesso, quindi un interrupt viene eseguito quando viene chiamato il kernel. Fig. 3.2. Chiamata di procedura remota Quando il kernel ottiene il controllo, cambia contesto, salva i registri del processore e una scheda di memoria, descrittori di pagina, installa una nuova scheda di memoria, che verrà utilizzata per funzionare in modalità kernel. Poiché i contesti del kernel e dell'utente sono diversi, il kernel deve copiare accuratamente il messaggio nel proprio spazio di indirizzi, in modo da avere accesso ad esso, ricordare l'indirizzo di destinazione e, possibilmente, altri campi di intestazione, e deve passarlo all'interfaccia di rete.

Questo conclude il lavoro sul lato client.

Il timer di trasferimento è attivato e il kernel può scorrere la disponibilità della risposta oppure trasferire il controllo allo scheduler, che sceglierà qualche altro processo da eseguire. Nel primo caso, la query viene accelerata, ma non è presente la multiprogrammazione. Sul lato server, i bit in arrivo vengono posizionati dall'apparecchiatura ricevente nel buffer incorporato o nella RAM e quando vengono ricevute tutte le informazioni, viene generato un interrupt.

Il gestore di interrupt verifica la correttezza dei dati del pacchetto e determina quale stub deve passarlo.Se nessuno degli stub si aspetta questo pacchetto, il gestore deve inserirlo nel buffer o rifiutarlo del tutto. Se è presente uno stub in sospeso, il messaggio gli viene copiato. Infine, viene eseguito il cambio di contesto, a seguito del quale vengono ripristinati i registri e la scheda di memoria, prendendo quei valori che avevano nel momento in cui lo stub ha effettuato una chiamata di ricezione.

Ora lo stub del server inizia a funzionare. Disimballa i parametri e li spinge di conseguenza sullo stack. Quando tutto è pronto, viene effettuata una chiamata al server. Una volta completata la procedura, il server passa i risultati al client, per cui tutti i passaggi sopra descritti vengono eseguiti solo nell'ordine inverso. La Figura 3.3 mostra la sequenza di comandi che devono essere eseguiti per ciascuna chiamata RPC e la Figura 3.4 mostra la quantità di tempo totale di esecuzione RPC impiegata in ciascuno dei 14 passaggi descritti sopra.

Gli studi sono stati condotti su una workstation multiprocessore DEC Firefly e, sebbene la presenza di cinque processori abbia necessariamente influenzato i risultati della misurazione, l'istogramma mostrato nella figura fornisce un'idea generale del processo di esecuzione RPC. Fig. 3.3. Passaggi della procedura RPC 3.4. Distribuzione del tempo tra le 14 fasi dell'esecuzione di RPC 1. Richiamo dello stub 2. Preparazione del buffer 3. Imballaggio dei parametri 4. Compilare il campo di intestazione 5. Calcolo del checksum nel messaggio 6. Interruzione nel kernel 7. Coda per l'esecuzione 8. Trasferimento del messaggio nel controller tramite QBUS 9. Tempo di trasmissione Ethernet 10. Ricezione di un pacchetto dal controller 11. Interruzione della procedura di elaborazione 12. Calcolo del checksum 13. Passaggio dal contesto allo spazio utente 14. Esecuzione dello stub del server Collegamento dinamico Considerare la domanda su come fare clic nt imposta la posizione del server.

Uno dei metodi per risolvere questo problema è l'uso diretto dell'indirizzo di rete del server nel programma client.

Lo svantaggio di questo approccio è la sua estrema mancanza di flessibilità quando si sposta il server o quando si aumenta il numero di server o quando si cambia l'interfaccia in tutti questi e molti altri casi, è necessario ricompilare tutti i programmi che utilizzano impostazioni rigide dell'indirizzo del server. Al fine di evitare tutti questi problemi, Alcuni sistemi distribuiti utilizzano quello che viene chiamato collegamento dinamico.

Il punto di partenza per il collegamento dinamico è la definizione formale di una specifica del server. La specifica contiene il nome del file server, il numero di versione e un elenco di procedure di servizio fornite da questo server per i client. Figura 3.5. Viene fornita una descrizione dei suoi parametri per ciascuna procedura, indicando se questo parametro è input o output rispetto al server.Alcuni parametri possono essere sia input che output, ad esempio, alcuni array che vengono inviati dal client al server vengono modificati lì, quindi l'operazione viene restituita al client copia ripristino. Fig. 3.5. Specifiche del server RPC Le specifiche del server formale vengono utilizzate come input per il programma generatore di stub, che crea sia client che server stub.

Quindi vengono inseriti nelle librerie appropriate. Quando un programma client utente chiama una procedura definita nelle specifiche del server, la procedura stub corrispondente è associata al codice binario del programma.

Allo stesso modo, quando viene compilato un server, gli stub del server sono associati ad esso. All'avvio del server, la sua prima azione è quella di trasferire la sua interfaccia server a un programma speciale chiamato binder. Questo processo, noto come processo di registrazione del server, prevede che il server trasmetta il nome, il numero di versione, l'identificatore univoco e il descrittore della posizione del server, che è indipendente dal sistema e può essere IP, Ethernet, X.500 o qualche altro indirizzo.

Inoltre, può contenere altre informazioni, ad esempio relative all'autenticazione. Quando il client chiama una delle procedure remote per la prima volta, ad esempio, leggi, lo stub client vede che non è ancora collegato al server e invia un messaggio al programma legante con una richiesta di importare l'interfaccia della versione desiderata del server desiderato. Se esiste un tale server, passa il raccoglitore descrittore e identificatore univoco per lo stub client.

Lo stub client utilizza un descrittore come indirizzo quando si invia un messaggio di richiesta. Il messaggio contiene parametri e un identificatore univoco che il core del server utilizza per indirizzare il messaggio in arrivo al server desiderato se ce ne sono diversi su questa macchina. Questo metodo di importazione delle interfacce di esportazione è altamente flessibile, ad esempio potrebbero esserci diversi server che supportano la stessa interfaccia e i client sono distribuiti casualmente tra i server.

Nell'ambito di questo metodo, diventa possibile interrogare periodicamente i server, analizzarne le prestazioni e, in caso di guasto, spegnersi automaticamente, aumentando così la tolleranza d'errore globale del sistema. Questo metodo può anche supportare l'autenticazione client. Ad esempio, un server può determinare che può essere utilizzato solo dai client di un elenco specifico, tuttavia i collegamenti dinamici presentano svantaggi, come sovraccarico aggiuntivo, tempo impiegato per esportare e importare interfacce.

L'entità di questi costi può essere significativa, poiché molti processi client esistono per un breve periodo e ad ogni avvio del processo è necessario ripetere la procedura di importazione dell'interfaccia. Inoltre, nei sistemi distribuiti di grandi dimensioni, il programma legante può diventare un collo di bottiglia e la creazione di numerosi programmi con uno scopo simile aumenta anche il sovraccarico di creazione e sincronizzazione dei processi Semantica RPC in caso di guasti Idealmente, RPC dovrebbe funzionare correttamente in caso di guasti.

Considerare le seguenti classi di errore: 1. Il client non è in grado di determinare la posizione del server, ad esempio, in caso di errore del server desiderato o perché il programma client è stato compilato molto tempo fa e ha utilizzato la versione precedente dell'interfaccia del server. In questo caso, in risposta a una richiesta del client, viene ricevuto un messaggio contenente un codice di errore. 2. La richiesta dal client al server viene persa La soluzione più semplice è ripetere la richiesta dopo un certo tempo. 3. Perso il messaggio di risposta dal server al client.

Questa opzione è più complicata della precedente, poiché alcune procedure non sono idempotenti. Viene chiamata una procedura idempotente, la cui richiesta di esecuzione può essere ripetuta più volte e il risultato non cambierà. Un esempio di tale procedura è la lettura di un file, ma la procedura per prelevare un determinato importo da un conto bancario non è idempotente e, in caso di perdita di risposta, una seconda richiesta può modificare in modo significativo lo stato del conto del cliente.

Una possibile soluzione è quella di portare tutte le procedure in una forma idempotente. Tuttavia, in pratica ciò non è sempre possibile, quindi è possibile utilizzare un altro metodo: numerazione sequenziale di tutte le richieste da parte del core del client. Il core del server ricorda il numero della richiesta più recente da ciascuno dei client e al ricevimento di ogni richiesta, analizza se questa richiesta è primaria o ripetuta. 4. Il server si è arrestato in modo anomalo dopo aver ricevuto la richiesta, anche in questo caso la proprietà idempotency è importante, ma sfortunatamente l'approccio con richieste di numerazione non può essere applicato.

In questo caso, è importante quando si è verificato l'errore, prima o dopo l'operazione. Ma il core del client non può riconoscere queste situazioni, poiché sa solo che il tempo di risposta è scaduto. Esistono tre approcci a questo problema: attendere fino al riavvio del server e tentare di eseguire nuovamente l'operazione, in modo che l'RPC sia stato completato fino alla fine almeno una volta, e possibilmente più. Informare immediatamente l'applicazione sull'errore.

Questo approccio garantisce che l'RPC sia stato completato non più di una volta. Il terzo approccio non garantisce nulla. Quando il server fallisce, non c'è supporto per il client. L'RPC può o meno essere eseguito o eseguito più volte. In ogni caso, questo metodo è molto facile da implementare. Nessuno di questi approcci è molto interessante e l'opzione ideale, che garantirebbe esattamente un'implementazione di RPC, nel caso generale non può essere implementata per ragioni fondamentali.

Supponiamo, ad esempio, che un'operazione remota stampi del testo, che include il caricamento del buffer della stampante e l'impostazione di un bit in un determinato registro di controllo della stampante, a seguito del quale la stampante viene avviata. L'errore del server può verificarsi sia in un microsecondo prima che in un microsecondo dopo aver impostato un bit di controllo. Il momento dell'errore determina completamente la procedura di recupero, ma il client non può scoprire il momento dell'errore.

In breve, la possibilità di crash del server cambia radicalmente la natura di RPC e riflette chiaramente la differenza tra un sistema centralizzato e distribuito. Nel primo caso, un arresto anomalo del server provoca un arresto anomalo del client e il ripristino non è possibile. Nel secondo caso, le azioni per ripristinare il sistema sono sia possibili che necessarie. 1. Il client si è arrestato in modo anomalo dopo aver inviato la richiesta. In questo caso, i calcoli vengono eseguiti con risultati che nessuno si aspetta e tali calcoli sono chiamati orfani. La presenza di orfani può causare vari problemi di sovraccarico del tempo del processore, il blocco delle risorse, la sostituzione della risposta alla richiesta corrente con la risposta alla richiesta emessa dal computer client prima del riavvio del sistema.

Cosa fare con gli orfani? Considera 4 possibili soluzioni. Distruzione. Prima che lo stub client invii un messaggio RPC, annota una nota nel registro, che consente di sapere cosa farà ora, il registro viene archiviato sul disco o in un'altra memoria con tolleranza agli errori.

Dopo l'incidente, il sistema si riavvia, il registro viene analizzato e gli orfani vengono liquidati. Gli svantaggi di questo approccio includono, in primo luogo, i maggiori costi associati alla scrittura di ciascun RPC su disco e, in secondo luogo, la possibile inefficienza dovuta alla comparsa di orfani di seconda generazione generati da chiamate RPC emesse da orfani di prima generazione. Reincarnazione: in questo caso, tutti i problemi vengono risolti senza l'uso della scrittura su disco. Il metodo consiste nel dividere il tempo in periodi numerati consecutivamente. Quando il client si riavvia, invia un messaggio di trasmissione a tutte le macchine all'inizio di un nuovo periodo.

Dopo aver ricevuto questo messaggio, tutti i calcoli eliminati vengono eliminati. Naturalmente, se la rete è segmentata, alcuni orfani potrebbero sopravvivere. La trasformazione software è simile al caso precedente, tranne per il fatto che non tutti i calcoli eliminati vengono cercati e distrutti, ma solo i calcoli del client di riavvio. Scadenza: ad ogni richiesta viene assegnato un periodo di tempo standard T, durante il quale deve essere completato.

Se la richiesta non viene completata nel tempo assegnato, viene assegnato un quantum aggiuntivo. Sebbene ciò richieda ulteriore lavoro, ma se, dopo un incidente del cliente, il server attende un intervallo T prima che il client si riavvii, tutti gli orfani vengono necessariamente distrutti. In pratica, nessuno di questi approcci è auspicabile, inoltre, la distruzione degli orfani può aggravare la situazione. Ad esempio, lasciare che un orfano blocchi uno o più file di database.

Se l'orfano viene improvvisamente distrutto, questi blocchi rimarranno, inoltre, gli orfani distrutti possono rimanere in varie code di sistema, in futuro possono causare l'esecuzione di nuovi processi, ecc.

Cosa faremo con il materiale ricevuto:

Se questo materiale ti è utile, puoi salvarlo sulla tua pagina nei social network:

Conferenza 4

4.1 Il concetto di chiamata di procedura remota

L'idea di chiamare procedure remote (Chiamata di procedura remota - RPC) consiste nell'ampliare il meccanismo ben noto e comprensibile per il trasferimento di controllo e dati all'interno di un programma in esecuzione su una macchina al trasferimento di controllo e dati attraverso la rete. Gli strumenti di chiamata di procedura remota sono progettati per facilitare l'organizzazione del calcolo distribuito. La massima efficienza dell'uso di RPC si ottiene in quelle applicazioni in cui esiste una connessione interattiva tra componenti remoti con un tempo di risposta breve e una quantità relativamente piccola di dati trasmessi. Tali applicazioni sono chiamate orientate RPC.

Le caratteristiche della chiamata delle procedure locali sono: asimmetria, ovvero una delle parti interagenti è l'iniziatore; la sincronizzazione, ovvero l'esecuzione della procedura di chiamata quando si interrompe dal momento in cui la richiesta è stata emessa e riprende solo dopo il ritorno dalla procedura chiamata.

L'implementazione delle chiamate remote è molto più complicata rispetto all'implementazione delle chiamate di procedure locali. Innanzitutto, poiché le procedure di chiamata e chiamata vengono eseguite su macchine diverse, hanno spazi di indirizzi diversi e ciò crea problemi quando si passano parametri e risultati, soprattutto se le macchine non sono identiche. Poiché RPC non può contare sulla memoria condivisa, ciò significa che i parametri RPC non devono contenere puntatori a celle di memoria non stack e che i valori dei parametri devono essere copiati da un computer a un altro. La prossima differenza tra l'RPC e la chiamata locale è che utilizza necessariamente il sistema di comunicazione sottostante, ma ciò non dovrebbe essere chiaramente visibile né nella definizione delle procedure né nelle procedure stesse. La lontananza introduce ulteriori problemi. L'esecuzione del programma chiamante e la procedura locale chiamata in una macchina sono implementate come parte di un singolo processo. Ma almeno due processi sono coinvolti nell'implementazione di RPC - uno in ogni macchina. Se uno di questi si arresta in modo anomalo, possono verificarsi le seguenti situazioni: in caso di una procedura di chiamata accidentale, le procedure di chiamata remota diventeranno "orfane" e quando le procedure remote falliranno, le procedure di chiamata diventeranno "private dei genitori", che aspetteranno invano una risposta dalle procedure remote.

Inoltre, esistono numerosi problemi associati all'eterogeneità dei linguaggi di programmazione e degli ambienti operativi: le strutture dati e le strutture di chiamata delle procedure supportate in un qualsiasi linguaggio di programmazione non sono supportate esattamente allo stesso modo in tutti gli altri linguaggi.

La diffusa tecnologia RPC che sta alla base di molti sistemi operativi distribuiti risolve questi e alcuni altri problemi.

Operazioni RPC di base

Per comprendere il funzionamento di RPC, consideriamo innanzitutto l'esecuzione di una chiamata di procedura locale in una macchina normale che funziona in modo autonomo. Lascia che questo, ad esempio, sia una chiamata di sistema

count \u003d read (fd, buf, nbytes);

dove fd è un numero intero;

buf: una matrice di personaggi;

nbytes è un numero intero.

Per effettuare una chiamata, la procedura di chiamata inserisce i parametri nello stack nell'ordine inverso. Una volta completata la chiamata in lettura, inserisce il valore di ritorno nel registro, sposta l'indirizzo di ritorno e restituisce il controllo alla procedura di chiamata, che seleziona i parametri dallo stack, riportandolo al suo stato originale. Si noti che in C, i parametri possono essere chiamati per riferimento (per nome) o per valore (per valore). In relazione alla procedura chiamata, i valori dei parametri sono variabili locali inizializzabili. La procedura chiamata può modificarli e ciò non influirà sul valore degli originali di queste variabili nella procedura di chiamata.

Se un puntatore a una variabile viene passato alla procedura chiamata, quindi una modifica del valore di questa variabile mediante la procedura chiamata comporta una modifica del valore di questa variabile per la procedura chiamante. Questo fatto è molto significativo per RPC.

Esiste anche un altro meccanismo di passaggio dei parametri che non viene utilizzato in C. Si chiama call-by-copy / restore e consiste nella necessità per il chiamante di copiare le variabili nello stack come valori, quindi di copiarle dopo che la chiamata è stata effettuata sui valori originali della procedura di chiamata.

La decisione sul meccanismo di trasferimento dei parametri da utilizzare viene presa dagli sviluppatori del linguaggio. A volte dipende dal tipo di dati trasferiti. In C, ad esempio, i dati interi e altri dati scalari vengono sempre passati per valore e le matrici per riferimento.

L'idea alla base di RPC è di rendere la chiamata alla procedura remota il più possibile simile alla chiamata alla procedura locale. In altre parole, rendere RPC trasparente: la procedura di chiamata non ha bisogno di sapere che la procedura chiamata è su un altro computer e viceversa.

RPC raggiunge la trasparenza nel modo seguente. Quando la procedura chiamata è davvero remota, un'altra versione della procedura, chiamata stub client (stub, è uno stub) viene inserita nella libreria anziché nella procedura locale. Come la procedura originale, lo stub viene chiamato usando la sequenza di chiamata e si verifica un interrupt quando si accede al kernel. Solo, a differenza della procedura originale, non inserisce i parametri nei registri e non richiede i dati dal kernel, ma genera un messaggio da inviare al kernel della macchina remota.

Fasi RPC

L'interazione dei componenti software durante l'esecuzione di una chiamata di procedura remota è illustrata nella Figura 2.

Figura 2. Chiamata di procedura remota

Dopo che lo stub client è stato chiamato dal programma client, la sua prima attività è riempire il buffer con il messaggio inviato. In alcuni sistemi, lo stub client ha un singolo buffer di lunghezza fissa che viene riempito ogni volta dall'inizio quando arriva ogni nuova richiesta. Su altri sistemi, un buffer di messaggi è un pool di buffer per singoli campi di messaggi, alcuni dei quali sono già pieni. Questo metodo è particolarmente adatto per i casi in cui il pacchetto ha un formato costituito da un gran numero di campi, ma i valori di molti di questi campi non cambiano da chiamata a chiamata.

Quindi i parametri devono essere convertiti nel formato appropriato e inseriti nel buffer dei messaggi. A questo punto, il messaggio è pronto per essere trasmesso, quindi un interrupt viene eseguito su una chiamata del kernel.

Quando il kernel riceve il controllo, cambia contesto, salva i registri del processore e una scheda di memoria (descrittori di pagina), installa una nuova scheda di memoria, che verrà utilizzata per funzionare in modalità kernel. Poiché i contesti del kernel e dell'utente sono diversi, il kernel deve copiare accuratamente il messaggio nel proprio spazio di indirizzi, in modo da avere accesso ad esso, ricordare l'indirizzo di destinazione (e, possibilmente, altri campi di intestazione), e deve anche passarlo all'interfaccia di rete. Questo conclude il lavoro sul lato client. Il timer di trasferimento è attivato e il kernel può scorrere la disponibilità della risposta oppure trasferire il controllo allo scheduler, che sceglierà qualche altro processo da eseguire. Nel primo caso, la query viene accelerata, ma non è presente la multiprogrammazione.

Sul lato server, i bit in arrivo vengono posizionati dall'apparecchiatura ricevente nel buffer incorporato o nella RAM. Quando vengono ricevute tutte le informazioni, viene generato un interrupt. Il gestore di interrupt verifica la correttezza dei dati del pacchetto e determina a quale stub deve essere trasmesso. Se nessuno degli stub prevede questo pacchetto, il gestore deve inserirlo nel buffer o rifiutarlo del tutto. Se è presente uno stub in sospeso, il messaggio gli viene copiato. Infine, viene eseguito il cambio di contesto, a seguito del quale vengono ripristinati i registri e la scheda di memoria, prendendo quei valori che avevano nel momento in cui lo stub ha effettuato una chiamata di ricezione.

Ora lo stub del server inizia a funzionare. Disimballa i parametri e li spinge di conseguenza sullo stack. Quando tutto è pronto, viene effettuata una chiamata al server. Al termine della procedura, il server passa i risultati al client. Per fare ciò, tutti i passaggi sopra descritti vengono eseguiti, solo nell'ordine inverso.

La Figura 3 mostra la sequenza di comandi che devono essere eseguiti per ogni chiamata RPC.

Figura 3. Fasi del processo RPC

La struttura del sistema operativo Windows di qualsiasi modifica, a partire dalla versione XP, include un componente di servizio, denominato RPC. Per la maggior parte, gli utenti ordinari non sanno di cosa si tratta, inoltre, non sanno a cosa serve questo servizio e come funziona. A questo proposito, si propone di prendere in considerazione alcuni aspetti di base relativi al componente stesso, i principi del suo funzionamento e il campo di applicazione senza descrivere termini tecnici non necessari e complessi. Ci soffermeremo separatamente su possibili errori e metodi di servizio per la loro rapida eliminazione.

Procedure remote (chiamata di procedure remote): che cos'è?

Apparentemente, molti utenti, in base al nome di questo componente del servizio, hanno già concluso che lo è. In effetti, le procedure remote (chiamata procedure remote) implicano alcune azioni quando vengono eseguite non sul computer locale, ma sul telecomando (molto spesso sul server).

Cioè, la richiesta viene formata su un terminale, quindi trasmessa a un altro, dove viene eseguita, dopo di che la risposta (report) sull'esecuzione viene restituita al primo computer. Ma questa è solo una spiegazione primitiva. In effetti, tutto è molto più complicato, perché qui è necessario considerare i protocolli di trasferimento dei dati (UDP, TCP, HTTP) e molti altri meccanismi.

A cosa serve questo servizio?

Nonostante il suo scopo principale, la chiamata remota delle procedure RPC può essere applicata non su computer diversi, ma su uno. Come esempio più semplice, si può chiamare una funzione di un programma da un'altra applicazione. Molti musicisti che lavorano con studi virtuali e sequencer sanno che ciascuna di queste applicazioni ha il proprio modulo di elaborazione o elaborazione audio, che non sempre soddisfa i requisiti stabiliti dall'utente. E qualsiasi studio ti consente invece di connettere qualsiasi altro programma esterno.

Ad esempio, nelle impostazioni del sequencer di FL Studio, è possibile specificare un'altra applicazione (ad esempio Adobe Audition), che verrà utilizzata per impostazione predefinita per la modifica dei file audio (campioni) nell'ambiente principale del programma. Allo stesso tempo, la connessione di Adobe Audition a FL Studio non avverrà tramite host virtuali come VST, RTAS o DX, ma direttamente tramite l'uso del servizio di chiamata di procedura remota. Inutile dire che questo esempio non è l'unico, poiché l'ambito del componente descritto è molto più ampio.

Molto spesso questo servizio è anche associato alla distribuzione del carico di calcolo sui terminali tra i quali viene stabilita una connessione interattiva. Allo stesso tempo, se il carico viene distribuito uniformemente sulle risorse di elaborazione di più computer, le massime prestazioni possono essere raggiunte solo se si scambiano piccole quantità di dati e si ottiene una risposta rapida tra i componenti.

Chiamata di procedura remota non riuscita: qual è la ragione?

Sfortunatamente, a causa di questa richiesta, la comparsa di guasti ed errori associati a questo servizio è un evento abbastanza comune.

Di conseguenza, diventa impossibile non solo utilizzare il componente stesso. A volte non è nemmeno possibile accedere ad alcune impostazioni di sistema e Windows XP "vola", dopodiché può essere abbastanza problematico ripristinarlo al suo normale stato di funzionamento. Un altro problema è lo strumento di recupero online DISM, che fa parte del sistema operativo.

È con le violazioni delle sue opere che è associata la comparsa dell'errore 1726, che influisce direttamente sul funzionamento dei componenti del servizio RPC.

I motivi principali di tali guasti sono chiamati mezzi per controllare o ripristinare il sistema quando il processo DISM è attivo o non può completare correttamente il lavoro (ad esempio, quando gli strumenti DISM e SFC iniziano da due console di comando contemporaneamente); quando un servizio viene eseguito in parallelo con la manutenzione dei componenti RPC; quando il servizio è bloccato da un software antivirus.

Pertanto, se si verifica un errore durante una chiamata di procedura remota in Windows 7 e versioni successive, la prima cosa da fare è spegnere DISM, riavviare il computer e riavviare il servizio. Se questo non aiuta, puoi provare a passare alla modalità provvisoria e disabilitare completamente la protezione antivirus per la durata del recupero. Ci soffermeremo su ulteriori misure che aiutano a correggere eventuali errori durante una chiamata di procedura remota e in qualsiasi modifica di Windows. Nel frattempo, esaminiamo i problemi relativi alla disabilitazione di questo componente di sistema (ahimè, ma molti utenti che non conoscono l'essenza del problema stanno provando a fare proprio queste cose).

Posso disabilitare il servizio RPC?

Vediamo quindi quanto sia realistico disattivare una chiamata a procedure remote. Le procedure remote, basate sulle raccomandazioni degli sviluppatori, non possono essere disattivate in ogni caso. Questo è importante! In linea di principio, lei stessa non lo permetterà. Esistono, naturalmente, alcune soluzioni alternative che implicano l'uso di software aggiuntivo, ma per ovvi motivi, i nomi di tali applicazioni non vengono indicati, perché se utilizzati in modo errato, l'intero sistema potrebbe diventare inutilizzabile.

Le conseguenze della disabilitazione dei processi RPC

Anche se l'utente riesce a disabilitare in qualche modo le procedure remote (chiamando procedure remote), le conseguenze, sfortunatamente, possono essere le più imprevedibili. Come già accennato, Windows XP potrebbe smettere di funzionare del tutto e, in un sistema operativo di livello superiore, di conseguenza, potrebbe apparire un numero enorme di guasti del sistema che non possono essere risolti almeno a causa della mancanza di accesso alle impostazioni e ai parametri di Windows critici e anche in modalità provvisoria modalità o quando si inizia da un supporto rimovibile. Tuttavia, è possibile correggere un errore nel chiamare procedure remote in Windows 10 o versioni precedenti del sistema operativo. Il metodo non è il più semplice, quindi quando lo usi devi stare molto attento.

Disabilitazione del Localizzatore di accesso remoto

Pertanto, il servizio RPC principale non può essere disabilitato. Ma forse ha senso disattivare alcuni dei suoi componenti correlati? Sì, infatti, se vai alla sezione dei servizi di sistema e dei loro componenti (services.msc), puoi trovare il cosiddetto localizzatore RPC in esso.

Ma può essere disattivato senza paura per la comparsa di conseguenze catastrofiche. Dopo aver inserito la modifica dei suoi parametri, è necessario arrestare il componente e impostare il tipo di avvio su disabilitato. I programmi che possono utilizzare procedure remote chiameranno anche procedure remote (senza il suo aiuto).

Se, per qualche motivo, i parametri impostati non funzionano, è possibile utilizzare il disco di installazione di Windows, quando si avvia da esso, chiamare la riga di comando e immettere quanto segue:

cd X: \\ i386 (X è la lettera dell'unità);
espandere explorer.ex_% TEMP% \\ explorer.exe;
espandi svchost.ex_% TEMP% \\ svchost.exe.

Dopo il riavvio, viene chiamato "Task Manager", quindi la combinazione copia% TEMP% \\ explorer.exe% SYSTEMROOT% / y viene immessa nella riga di comando, dopodiché tutti i processi svchost vengono terminati in "Task Manager". Ora dovresti stare particolarmente attento, perché alla fine del processo, in soli sessanta secondi devi registrare il comando copia% TEMP% \\ svchost.exe% systemroot% \\ system32 / y nella console di comando.

Se l'utente, ad esempio, in modalità normale o sicura ha accesso al registro di sistema, nell'editor (regedit) nel ramo HKCC, è necessario trovare il parametro CSConfigFlags e assegnargli un valore pari a zero.

Risolvi i problemi 1726

Infine, la correzione dell'errore 1726 viene eseguita anche tramite il registro. Ma in questo caso, nel ramo HKLM, è necessario trovare la directory RpcSs e sulla destra modificare il valore del parametro Start.

Deve essere modificato da quattro, di solito installato per impostazione predefinita, a due, quindi riavviare il sistema.

postfazione

Questo, in realtà, si tratta solo di chiamare procedure remote. Le procedure remote, i principi di funzionamento di questo componente nella versione avanzata possono essere descritti per molto tempo, ma l'enfasi nel materiale presentato è stata fatta su una familiarizzazione generale con il servizio e alcuni metodi per eliminare errori e guasti che può causare in un sistema informatico. Gli utenti ordinari dovranno essere pazienti e fare molta attenzione, poiché un'azione errata nel registro può portare a un arresto anomalo completo del sistema operativo.

Si noti che guasti di questo tipo in qualsiasi altro modo, come programmi di ottimizzazione e regolatori di parametri dei sistemi operativi Windows, non vengono risolti. Con tutto il desiderio, non viene fornita né la riga di comando, né, inoltre, l'intervento nel registro a livello di modifica delle chiavi in \u200b\u200btali pacchetti software.

Chiamata di procedura remota (o Chiamata di procedura remota) (dall'inglese Chiamata di procedura remota (RPC)) è una classe di tecnologie che consentono ai programmi per computer di chiamare funzioni o procedure in un altro spazio di indirizzi (in genere su computer remoti). Di solito, l'implementazione della tecnologia RPC include due componenti: un protocollo di rete per lo scambio client-server e un linguaggio per serializzare oggetti (o strutture per RPC non oggetto). Le diverse implementazioni RPC hanno un'architettura molto diversa e differiscono nelle loro capacità: alcune implementano l'architettura SOA, altre CORBA o DCOM. A livello di trasporto, gli RPC utilizzano principalmente i protocolli TCP e UDP, tuttavia alcuni sono costruiti sulla base di HTTP (che viola l'architettura ISO / OSI, poiché HTTP non è inizialmente un protocollo di trasporto).

implementazione

Esistono molte tecnologie che forniscono RPC:

Sun RPC (protocollo binario basato su TCP e UDP e XDR) RFC-1831 secondo nome ONC RPC RFC-1833
.Net Remoting (protocollo binario basato su TCP, UDP, HTTP)
SOAP - Simple Object Access Protocol (protocollo di testo basato su HTTP) vedere la scheda tecnica: RFC-4227
XML RPC (HTTP Based Text Protocol) vedere la scheda tecnica: RFC-3529
RMI Java - Invocazione metodo remoto Java - vedere le specifiche: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
Chiamate di procedura remota di notazione oggetto JavaScript JSON-RPC (protocollo di testo basato su HTTP) vedere la scheda tecnica: RFC-4627
DCE / RPC - Ambiente di elaborazione distribuito / Chiamate di procedure remote (un protocollo binario basato su vari protocolli di trasporto, inclusi TCP / IP e Named Pipes dal protocollo SMB / CIFS)
DCOM - Distributed Component Object Model noto come MSRPC Microsoft Remote Procedure Call o "Network OLE" (un'estensione orientata agli oggetti di DCE RPC che consente di trasferire riferimenti a oggetti e chiamare metodi di oggetti attraverso tali collegamenti)

principio

L'idea alla base di Remote Procedure Call (RPC) è quella di estendere il meccanismo ben noto e comprensibile per il trasferimento di controllo e dati all'interno di un programma in esecuzione su una macchina al trasferimento di controllo e dati sulla rete. Gli strumenti di chiamata di procedura remota sono progettati per facilitare l'organizzazione del calcolo distribuito e la creazione di sistemi informativi client-server distribuiti. La massima efficienza dell'uso di RPC si ottiene in quelle applicazioni in cui esiste una connessione interattiva tra componenti remoti con un tempo di risposta breve e una quantità relativamente piccola di dati trasmessi. Tali applicazioni sono chiamate orientate RPC.

L'implementazione delle chiamate remote è molto più complicata rispetto all'implementazione delle chiamate di procedure locali. È possibile identificare i seguenti problemi e attività che devono essere risolti durante l'implementazione di RPC:

Poiché le procedure di chiamata e chiamata vengono eseguite su macchine diverse, hanno spazi di indirizzi diversi e ciò crea problemi durante il passaggio di parametri e risultati, soprattutto se le macchine eseguono sistemi operativi diversi o hanno un'architettura diversa (ad esempio, utilizzando l'ordine dei byte diretto o inverso ). Poiché RPC non può contare sulla memoria condivisa, ciò significa che i parametri RPC non devono contenere puntatori a celle di memoria non stack e che i valori dei parametri devono essere copiati da un computer a un altro. Per copiare i parametri della procedura e il risultato dell'esecuzione attraverso la rete, vengono serializzati.
A differenza di una chiamata locale, una chiamata di procedura remota utilizza necessariamente il livello di trasporto dell'architettura di rete (ad esempio TCP), tuttavia questo rimane nascosto allo sviluppatore.
L'esecuzione del programma chiamante e la procedura locale chiamata in una macchina sono implementate come parte di un singolo processo. Ma almeno due processi sono coinvolti nell'implementazione di RPC - uno in ogni macchina. Nel caso in cui uno di essi si arresti in modo anomalo, possono verificarsi le seguenti situazioni: in caso di una procedura di chiamata accidentale, le procedure di chiamata remota diventeranno "orfane" e, se le procedure remote falliscono, le procedure di chiamata diventeranno "private dei genitori", che aspetteranno invano una risposta dalle procedure remote.
Esistono numerosi problemi associati all'eterogeneità dei linguaggi di programmazione e degli ambienti operativi: le strutture di dati e le strutture di chiamata delle procedure supportate in un qualsiasi linguaggio di programmazione non sono supportate esattamente allo stesso modo in tutti gli altri linguaggi. Pertanto, esiste un problema di compatibilità che non è stato ancora risolto introducendo uno standard generalmente accettato o implementando diversi standard concorrenti in tutte le architetture e in tutte le lingue.

sottosistemi

Sottosistema di trasporto

Gestire le connessioni in uscita e in entrata. - Supporto per il concetto di "bordo del messaggio" per i protocolli di trasporto che non lo supportano direttamente (TCP). - Supporto per la consegna garantita per i protocolli di trasporto che non lo supportano direttamente (UDP).

Thread pool (chiamato solo party). Fornisce un contesto di esecuzione per il codice invocato dalla rete.

Marshaling (chiamato anche "serializzazione"). Comprimere i parametri di chiamata in un flusso di byte in modo standard, indipendentemente dall'architettura (in particolare, l'ordine dei byte in una parola). In particolare, matrici, stringhe e strutture puntate da parametri del puntatore possono essere esposti ad esso.

Crittografia dei pacchetti e firma digitale su di essi.

Autenticazione e autorizzazione. Trasmissione in rete di informazioni che identificano l'oggetto che effettua la chiamata.

In alcune implementazioni RPC (.NET Remoting), i confini dei sottosistemi sono interfacce polimorfiche aperte ed è possibile scrivere la propria implementazione di quasi tutti i sottosistemi elencati. In altre implementazioni (DCE RPC su Windows) non è così.

Vedi anche

Concetto di chiamata di procedura remota (RPC)

L'idea alla base di Remote Procedure Call (RPC) è quella di estendere il meccanismo ben noto e comprensibile per il trasferimento di controllo e dati all'interno di un programma in esecuzione su una macchina al trasferimento di controllo e dati sulla rete. Gli strumenti di chiamata di procedura remota sono progettati per facilitare l'organizzazione del calcolo distribuito. La massima efficienza dell'uso di RPC si ottiene in quelle applicazioni in cui esiste una connessione interattiva tra componenti remoti con un tempo di risposta breve e una quantità relativamente piccola di dati trasmessi. Tali applicazioni sono chiamate orientate RPC.

Le caratteristiche della chiamata delle procedure locali sono:

L'asimmetria, cioè una delle parti interagenti è l'iniziatore;
Il sincronismo, ovvero l'esecuzione della procedura di chiamata è sospesa dal momento in cui la richiesta viene emessa e riprende solo dopo il ritorno dalla procedura chiamata.

L'implementazione delle chiamate remote è molto più complicata rispetto all'implementazione delle chiamate di procedure locali. Innanzitutto, poiché le procedure di chiamata e chiamata vengono eseguite su macchine diverse, hanno spazi di indirizzi diversi e ciò crea problemi quando si passano parametri e risultati, soprattutto se le macchine non sono identiche. Poiché RPC non può contare sulla memoria condivisa, ciò significa che i parametri RPC non devono contenere puntatori a celle di memoria non stack e che i valori dei parametri devono essere copiati da un computer a un altro. La differenza successiva tra RPC e la chiamata locale è che utilizza necessariamente il sistema di comunicazione sottostante, ma ciò non dovrebbe essere chiaramente visibile né nella definizione delle procedure né nelle procedure stesse. La lontananza introduce ulteriori problemi. L'esecuzione del programma chiamante e la procedura locale chiamata in una macchina sono implementate come parte di un singolo processo. Ma almeno due processi sono coinvolti nell'implementazione di RPC - uno in ogni macchina. Se uno di questi si arresta in modo anomalo, possono verificarsi le seguenti situazioni: in caso di una procedura di chiamata accidentale, le procedure di chiamata remota diventeranno "orfane" e, se le procedure remote falliscono, le procedure di chiamata diventeranno "private dei genitori", che aspetteranno invano una risposta dalle procedure remote.

La diffusa tecnologia RPC che sta alla base di molti sistemi operativi distribuiti risolve questi e alcuni altri problemi. Operazioni RPC di base

count \u003d read (fd, buf, nbytes);

dove fd è un numero intero, buf è un array di caratteri, nbytes è un numero intero.

Per effettuare una chiamata, la procedura di chiamata inserisce i parametri nello stack nell'ordine inverso (Figura 3.1). Una volta completata la chiamata in lettura, inserisce il valore di ritorno nel registro, sposta l'indirizzo di ritorno e restituisce il controllo alla procedura di chiamata, che seleziona i parametri dallo stack, riportandolo al suo stato originale. Si noti che in C, i parametri possono essere chiamati per riferimento (per nome) o per valore (per valore). In relazione alla procedura chiamata, i valori dei parametri sono variabili locali inizializzabili. La procedura chiamata può modificarli e ciò non influirà sul valore degli originali di queste variabili nella procedura di chiamata.

applicazione

Una parte significativa degli strumenti per la gestione remota del sistema operativo Windows (Visualizzatore eventi, Server Manager, gestione stampa, elenchi utenti) utilizza DCE RPC come mezzo di comunicazione di rete tra il servizio gestito e l'applicazione di gestione dell'interfaccia utente. Il supporto DCE RPC è presente su Windows NT sin dalla prima versione 3.1. I client DCE RPC erano inoltre supportati nella linea leggera dei sistemi operativi Windows 3.x / 95/98 / Me.

Le librerie di sistema di Windows che forniscono tali capacità di gestione e fungono da livello base per le applicazioni di interfaccia utente gestite (netapi32.dll e parzialmente advapi32.dll) contengono effettivamente il codice client per le interfacce DCE RPC che forniscono questo controllo.

Questa decisione architettonica è stata oggetto di intense critiche nei confronti di Microsoft. Le procedure di smistamento universale presenti in DCE RPC sono molto complesse e hanno l'enorme potenziale di sfruttamento dei difetti sulla rete inviando un pacchetto DCE RPC deliberatamente distorto. Una parte significativa dei difetti di sicurezza di Windows rilevati tra la fine degli anni '90 e la metà degli anni 2000 erano errori nel codice di marshalling RPC DCE.

Oltre a DCE RPC, Windows utilizza attivamente la tecnologia DCOM. Ad esempio, viene utilizzato come mezzo di comunicazione tra gli strumenti di gestione del server Web IIS e il server gestito stesso. Un'interfaccia completa per la comunicazione con il sistema di posta di MS Exchange Server - MAPI - si basa anche su DCOM.

I programmi che comunicano attraverso la rete necessitano di un meccanismo di comunicazione. Al livello inferiore, al ricevimento dei pacchetti, un programma viene elaborato dal programma di elaborazione del segnale di rete. Al livello superiore, il meccanismo rendezvous (rendezvous), adottato nella lingua di Ada, funziona. NFS utilizza un meccanismo di chiamata di procedura remota (RPC) in cui il client interagisce con il server (vedere la Figura 1). In conformità con questo processo, il client accede innanzitutto alla procedura che invia la richiesta al server. All'arrivo del pacchetto con la richiesta, il server chiama la procedura per aprirlo, esegue il servizio richiesto, invia una risposta e il controllo viene restituito al client.

L'interfaccia RPC può essere rappresentata come composta da tre livelli:

Il livello superiore è completamente trasparente. Un programma di questo livello può, ad esempio, contenere una chiamata alla procedura rnusers (), che restituisce il numero di utenti sul computer remoto. Non è necessario conoscere l'utilizzo del meccanismo RPC, poiché si sta effettuando una chiamata nel programma.
Il livello intermedio è per le applicazioni più comuni. Le chiamate RPC a questo livello sono gestite dalle routine registerrpc () e callrpc (): registerrpc () riceve il codice a livello di sistema e callrpc () esegue una chiamata di procedura remota. La chiamata rnusers () viene implementata usando queste due routine.
Il livello inferiore viene utilizzato per attività più complesse che modificano i valori predefiniti con i valori dei parametri della procedura. A questo livello, è possibile manipolare esplicitamente i socket utilizzati per trasmettere i messaggi RPC.

Di norma, è necessario utilizzare il livello superiore ed evitare l'uso di livelli inferiori senza necessità particolari.

Nonostante il fatto che in questa guida consideriamo l'interfaccia solo in C, l'accesso alle procedure remote può essere fatto da qualsiasi lingua. Il lavoro del meccanismo RPC per organizzare l'interazione tra processi su macchine diverse non differisce dal suo lavoro su una macchina.

RPC (Remote Procedure Call) è un'interfaccia tra utenti remoti e determinati programmi host eseguiti su richiesta di questi utenti. Un servizio RPC di un host, di regola, fornisce ai client una gamma di programmi. Ciascuno di questi programmi, a sua volta, consiste in una o più procedure remote. Ad esempio, un servizio di file system remoto NFS basato su chiamate RPC può consistere in solo due programmi: ad esempio, un programma interagisce con interfacce utente di alto livello e l'altro con funzioni I / O di basso livello.

Due parti sono coinvolte in ciascuna chiamata alla procedura remota: il client attivo, che invia la richiesta alla chiamata di procedura al server, e il server, che invia la risposta al client.

Nota. Va tenuto presente che i termini "client" e "server" in questo caso si riferiscono a una particolare transazione: un determinato host o software (processo o programma) può funzionare sia come client che come server. Ad esempio, un programma che fornisce il funzionamento di un servizio di procedura remota, allo stesso tempo, può essere un client che lavora con un file system di rete.

Il protocollo RPC è basato su un modello di chiamata di procedura remota, simile al meccanismo di chiamata di procedura locale. Quando si chiama una procedura locale, si inseriscono gli argomenti in una posizione di memoria specifica, nello stack o nelle variabili di ambiente e si trasferisce il controllo del processo a un indirizzo specifico. Dopo aver completato il lavoro, leggi i risultati a un indirizzo specifico e prosegui il processo.

Nel caso di lavorare con una procedura remota, la differenza principale è che due processi servono la chiamata alla funzione remota: il processo client e il processo server.

Il processo client invia un messaggio al server che include i parametri della procedura chiamata e si aspetta un messaggio di risposta con i risultati della sua operazione. Quando viene ricevuta una risposta, il risultato viene letto e il processo continua. Sul lato server, il processo del gestore chiamate si trova in uno stato di attesa e, quando arriva un messaggio, legge i parametri della procedura, lo esegue, invia una risposta e diventa lo stato di attesa della chiamata successiva.

Il protocollo RPC non impone alcun requisito sulle comunicazioni aggiuntive tra i processi e non richiede la sincronizzazione delle funzioni eseguite, ovvero le chiamate possono essere asincrone e non indipendenti, quindi il client può eseguire altre procedure in attesa di una risposta. Il server RPC può allocare un processo separato o una macchina virtuale per ciascuna funzione, pertanto, senza attendere il completamento delle richieste precedenti, può immediatamente accettare quanto segue.

Tuttavia, ci sono diverse differenze importanti tra le chiamate alle procedure locali e remote:

Gestione degli errori. In ogni caso, il client deve essere informato degli errori che si verificano durante la chiamata di procedure remote sul server o sulla rete.
Variabili globali. Poiché il server non ha accesso allo spazio degli indirizzi del client, quando si chiamano le procedure remote, non è possibile utilizzare parametri nascosti sotto forma di variabili globali.
Prestazioni. La velocità di esecuzione delle procedure remote è generalmente inferiore di uno o due ordini di grandezza rispetto alla velocità di esecuzione di procedure locali simili.
Autenticazione. Poiché le chiamate di procedura remota sono in rete, è necessario utilizzare i meccanismi di autenticazione client.

Principi di costruzione del protocollo.

Il protocollo RPC può utilizzare diversi protocolli di trasporto. Le responsabilità del protocollo RPC comprendono solo la fornitura di standard e l'interpretazione della messaggistica. L'affidabilità e l'affidabilità della trasmissione dei messaggi è interamente fornita dal livello di trasporto.

Tuttavia, l'RPC può controllare la selezione e alcune funzioni del protocollo di trasporto. Come esempio dell'interazione tra RPC e il protocollo di trasporto, considerare la procedura per assegnare la porta RPC del processo dell'applicazione tramite RPC - Portmapper.

Questa funzione in modo dinamico (su richiesta) assegna una porta specifica a una connessione RPC. La funzione Portmapper viene utilizzata abbastanza spesso, poiché l'insieme delle porte di trasporto riservate a RPC è limitato e il numero di processi che possono potenzialmente funzionare contemporaneamente è molto elevato. Portmapper, ad esempio, viene chiamato quando vengono selezionate le porte di interazione tra il client e il server di sistema NFS.

Il servizio Portmapper utilizza il meccanismo di trasmissione RPC su una porta specifica - III. Su questa porta, il client invia un messaggio broadcast di richiesta porta per un servizio RPC specifico. Il servizio Portmapper elabora il messaggio fiscale, determina l'indirizzo del servizio RPC locale e invia una risposta al client. Il servizio RPC Portmapper può funzionare con i protocolli TCP e UDP.

RPC può funzionare con vari protocolli di trasporto, ma non duplica mai le loro funzioni, vale a dire, se RPC funziona su TCP, tutta l'affidabilità e l'affidabilità della connessione RPC si basa su TCP. Tuttavia, se il protocollo RPC è installato su UDP, può fornire funzioni native aggiuntive per garantire la consegna garantita dei messaggi.

Nota.

Le attività dell'applicazione possono considerare il protocollo RPC come una procedura specifica per chiamare una funzione su una rete JSR (Jump Subroutine Instruction).

Perché il protocollo RPC funzioni, devono essere soddisfatte le seguenti condizioni:

Identificazione univoca di tutte le procedure chiamate in remoto su questo host. Le richieste RPC contengono tre campi identificativi: il numero del programma remoto (servizio), il numero di versione del programma remoto e il numero della procedura remota del programma specificato. Il numero di programma è assegnato dal produttore del servizio, il numero di procedura indica la funzione specifica del servizio
Identificazione della versione del protocollo RPC. I messaggi RPC contengono un campo versione del protocollo RPC. Viene utilizzato per coordinare i formati dei parametri trasmessi quando il client funziona con diverse versioni di RPC.
Fornire meccanismi di autenticazione client sul server. Il protocollo RPC fornisce la procedura di autenticazione per il client nel servizio e, se necessario, ogni volta che una richiesta viene inviata o una risposta viene inviata al client. Inoltre, RPC consente l'utilizzo di vari meccanismi di sicurezza aggiuntivi.

RPC può utilizzare quattro tipi di meccanismi di autenticazione:

AUTH_NULL - senza utilizzare l'autenticazione
AUTH_UNIX - Autenticazione UNIX
AUTH_SHORT - Autenticazione UNIX con una propria struttura di codifica
AUTH_DES - Autenticazione DES

Individuazione di messaggi di risposta a richieste pertinenti. I messaggi di risposta RPC contengono l'identificatore di richiesta in base al quale sono stati creati. Questo identificatore può essere chiamato identificatore di transazione di chiamata RPC. Questo meccanismo è particolarmente necessario quando si lavora in modalità asincrona e quando si esegue una sequenza di più chiamate RPC.
Identificazione degli errori di funzionamento del protocollo. Tutti gli errori di rete o del server hanno identificatori univoci, mediante i quali ciascun partecipante alla connessione può determinare la causa dell'errore.

Strutture dei messaggi di protocollo

Quando si trasmettono messaggi RPC su un protocollo di trasporto, diversi messaggi RPC possono risiedere nello stesso pacchetto di trasporto. Per separare un messaggio da un altro, viene utilizzato un marker di registrazione (RM - Record Marker). Ogni messaggio RPC è "taggato" con esattamente un RM.

Un messaggio RPC può essere costituito da diversi frammenti. Ogni frammento è composto da quattro byte di intestazione e (da 0 a 2 ** 31-1) dati. Il primo bit dell'intestazione indica se questo frammento è l'ultimo e i restanti 31 bit indicano la lunghezza del pacchetto di dati.

La struttura dell'RPC è formalmente descritta nella lingua della descrizione e della presentazione dei formati di dati - XDR con aggiunte relative alla descrizione delle procedure. Si potrebbe anche dire che il linguaggio di descrizione RPC è un'estensione XDR, integrata dal lavoro con le procedure.

La struttura del pacchetto RPC è la seguente:

La struttura di risposta (reply_body) può contenere la struttura trasmessa in caso di errore (quindi contiene il codice di errore) o la struttura dell'elaborazione della richiesta riuscita (quindi contiene i dati restituiti).

Interfaccia software di alto livello.

L'uso delle routine in un programma è un modo tradizionale di strutturare un'attività e renderla più chiara. Le routine più comunemente utilizzate sono raccolte in librerie, dove possono essere utilizzate da vari programmi. In questo caso, stiamo parlando di una chiamata locale (locale), ovvero, sia il chiamante che l'oggetto chiamato operano all'interno dello stesso programma su un computer.

Nel caso di una chiamata remota, un processo in esecuzione su un computer avvia il processo sul computer remoto (ovvero, in realtà esegue il codice di procedura sul computer remoto). Ovviamente, la chiamata di procedura remota è significativamente diversa da quella locale tradizionale, tuttavia, dal punto di vista del programmatore, tali differenze sono praticamente assenti, ovvero l'architettura della chiamata di procedura remota consente di simulare una chiamata locale.

Tuttavia, se nel caso di una chiamata locale, il programma trasferisce i parametri alla procedura chiamata e riceve il risultato del lavoro attraverso lo stack o le aree di memoria condivisa, quindi nel caso di una chiamata remota, il trasferimento dei parametri si trasforma in una trasmissione di richiesta sulla rete e il risultato del lavoro è nella risposta ricevuta.

Questo approccio è una possibile base per la creazione di applicazioni distribuite e sebbene molti sistemi moderni non utilizzino questo meccanismo, i concetti e i termini di base vengono conservati in molti casi. Nel descrivere il meccanismo RPC, chiameremo tradizionalmente il processo di chiamata client e il processo remoto che implementa la procedura server.

Una chiamata di procedura remota include i seguenti passaggi:

Il programma client effettua una chiamata locale a una procedura chiamata stub. Allo stesso tempo, sembra al client che, chiamando lo stub, effettui l'effettiva chiamata procedura-server. In effetti, il client passa i parametri necessari allo stub e restituisce il risultato. Tuttavia, non è esattamente così come immagina il cliente. Il compito dello stub è accettare gli argomenti previsti per la procedura remota, eventualmente convertirli in un formato standard e formare una richiesta di rete. La compressione degli argomenti e la creazione di una richiesta di rete si chiama marshalling.
Una richiesta di rete viene inviata tramite la rete al sistema remoto. Per fare ciò, lo stub utilizza le chiamate appropriate, ad esempio quelle discusse nelle sezioni precedenti. Si noti che in questo caso è possibile utilizzare vari protocolli di trasporto e non solo la famiglia TCP / IP.
Sull'host remoto, tutto accade in ordine inverso. Lo stub del server attende la richiesta e, al momento della ricezione, recupera i parametri: gli argomenti alla chiamata della procedura. Unmarshalling può includere le conversioni necessarie (ad esempio, cambiando l'ordine dei byte).
Lo stub effettua una chiamata alla procedura del server reale a cui viene indirizzata la richiesta del client, passando ad essa gli argomenti ricevuti sulla rete.
Al termine della procedura, il controllo ritorna allo stub del server, passandogli i parametri richiesti. Come uno stub client; lo stub del server converte i valori restituiti dalla procedura, formando un messaggio di risposta di rete, che viene trasmesso sulla rete al sistema da cui proviene la richiesta.
Il sistema operativo passa il messaggio ricevuto allo stub client, che, dopo la conversione necessaria, passa i valori (che sono i valori restituiti dalla procedura remota) al client, che vede questo come un normale ritorno dalla procedura.

Pertanto, dal punto di vista del cliente, effettua una chiamata a una procedura remota, come farebbe per una locale. Lo stesso si può dire del server: una chiamata di procedura si verifica in modo standard, un determinato oggetto (server stub) effettua una chiamata a una procedura locale e riceve i valori restituiti da esso. Il client percepisce lo stub come chiamato procedure-server e il server prende il proprio stub per il client.

Pertanto, gli stub costituiscono il nucleo del sistema RPC, responsabile di tutti gli aspetti della formazione e della trasmissione dei messaggi tra il client e il server remoto (procedura), sebbene sia il client che il server credano che le chiamate avvengano localmente. Questo è il concetto di base di RPC per nascondere completamente la natura distribuita (di rete) dell'interazione nel codice stub. I vantaggi di questo approccio sono evidenti: sia il client che il server sono indipendenti dall'implementazione della rete, entrambi funzionano all'interno di una determinata macchina virtuale distribuita e le chiamate di procedura hanno un'interfaccia standard.

Passando i parametri

Passare i valori dei parametri non causa molte difficoltà. In questo caso, lo stub client inserisce il valore del parametro nella richiesta di rete, eseguendo eventualmente conversioni nel modulo standard (ad esempio, modificando l'ordine dei byte). Molto più complicata è la situazione con il passaggio di puntatori quando il parametro è l'indirizzo dei dati, non il suo valore. Il passaggio di un indirizzo in una richiesta non ha senso, poiché la procedura remota viene eseguita in uno spazio di indirizzi completamente diverso. La soluzione più semplice utilizzata in RPC è proibire ai client di passare parametri in altro modo che per valore, anche se questo, ovviamente, impone gravi restrizioni.

Il legame (binding)

Prima che un client possa chiamare una procedura remota, deve essere associato a un sistema remoto con il server richiesto. Pertanto, il problema vincolante si divide in due:

Trovare un host remoto con il server desiderato
Trovare il processo server richiesto su questo host

È possibile utilizzare vari approcci per trovare l'host. Un'opzione possibile è quella di creare una directory centralizzata in cui gli host annunciano i loro server e in cui il client può scegliere l'host e l'indirizzo appropriati per la procedura.

Ogni procedura RPC è determinata in modo univoco dal programma e dal numero della procedura. Il numero del programma definisce un gruppo di procedure remote, ognuna delle quali ha il proprio numero. A ciascun programma viene inoltre assegnato un numero di versione, quindi quando si apportano modifiche minori al programma (ad esempio, quando si aggiunge una procedura), non è necessario modificarne il numero. Solitamente, in un modulo software sono implementate diverse procedure funzionalmente simili, che all'avvio diventa il server di queste procedure e che è identificato dal numero di programma.

Pertanto, quando un cliente desidera chiamare una procedura remota, deve conoscere i numeri di programma, le versioni e le procedure che forniscono il servizio richiesto.

Per inviare la richiesta al client, è anche necessario conoscere l'indirizzo di rete dell'host e il numero di porta associato al programma del server che fornisce le procedure richieste. Il demone portmap (IM) è usato per questo (su alcuni sistemi è chiamato rpcbind (IM)). Il daemon viene eseguito su un host che fornisce servizi di procedura remota e utilizza un numero di porta noto. Quando il processo del server viene inizializzato, registra le sue procedure e i numeri di porta in portmap (IM). Ora, quando il client deve conoscere il numero di porta per chiamare una procedura specifica, invia una richiesta al server portmap (IM) che, a sua volta, restituisce il numero di porta o reindirizza la richiesta direttamente al server della procedura remota e, dopo la sua esecuzione, restituisce una risposta al client. In ogni caso, se esiste la procedura richiesta, il client riceve il numero di porta della procedura dal server portmap (IM) e può fare ulteriori richieste direttamente a questa porta.

Gestione delle eccezioni

Gestire situazioni speciali quando si chiamano le procedure locali non presenta un problema particolare. UNIX fornisce la gestione degli errori per processi come la divisione per zero, l'accesso a un'area di memoria non valida, ecc. Se viene chiamata una procedura remota, la probabilità di situazioni di errore aumenta. Gli errori relativi, ad esempio, alla ricezione di un messaggio di errore nella rete vengono aggiunti agli errori del server e dello stub.

Ad esempio, quando si utilizza UDP come protocollo di trasporto, i messaggi vengono ritrasmessi dopo un determinato timeout. Viene restituito un errore al client se, dopo un certo numero di tentativi, non è mai stata ricevuta una risposta dal server. Nel caso in cui venga utilizzato il protocollo TCP, viene restituito un errore al client se il server ha disconnesso la connessione TCP.

Chiama la semantica

Una chiamata a una procedura locale porta inequivocabilmente alla sua esecuzione, dopodiché il controllo ritorna al programma host. La situazione è diversa quando si chiama una procedura remota. È impossibile stabilire quando verrà specificamente eseguita la procedura, verrà eseguita affatto e, in caso affermativo, quante volte? Ad esempio, se una richiesta viene ricevuta da un sistema remoto dopo l'arresto anomalo del programma server, la procedura non verrà eseguita affatto. Se il client, dopo non aver ricevuto una risposta dopo un certo periodo di tempo (timeout), invia nuovamente la richiesta, potrebbe verificarsi una situazione in cui la risposta è già trasmessa sulla rete e la richiesta ripetuta viene nuovamente accettata per l'elaborazione dalla procedura remota. In questo caso, la procedura verrà eseguita più volte.

Pertanto, l'esecuzione di una procedura remota può essere caratterizzata dalla seguente semantica:

Una sola volta. Questo comportamento (in alcuni casi il più desiderabile) è difficile da richiedere a causa di possibili arresti anomali del server.
Nella maggior parte dei casi. Ciò significa che la procedura non è stata eseguita affatto o è stata eseguita una sola volta. Un'affermazione simile può essere fatta quando si riceve un errore invece di una risposta normale.
Almeno una volta La procedura è stata probabilmente eseguita una volta, ma probabilmente di più. Per il normale funzionamento in tale situazione, la procedura remota deve avere la proprietà di idempotenza (dall'inglese idemponent). Questa proprietà ha una procedura, la cui esecuzione ripetuta non provoca modifiche cumulative. Ad esempio, la lettura di un file è idempotente, mentre l'aggiunta di testo a un file non lo è.

Presentazione dei dati

Quando il client e il server sono in esecuzione sullo stesso sistema sullo stesso computer, non vi sono problemi di incompatibilità dei dati. Sia per il client che per il server, i dati binari sono presentati in modo identico. Nel caso di una chiamata remota, la questione è complicata dal fatto che il client e il server possono essere eseguiti su sistemi con architetture diverse che hanno diverse rappresentazioni dei dati (ad esempio, la rappresentazione di un valore in virgola mobile, l'ordine dei byte, ecc.)

La maggior parte delle implementazioni del sistema RPC definisce alcuni tipi standard di rappresentazione dei dati, in cui devono essere convertiti tutti i valori trasmessi nelle richieste e nelle risposte.

Ad esempio, il formato di presentazione dei dati RPC di Sun Microsystems è il seguente:

Ordine byte - Senior - Ultimo
Rappresentazione in virgola mobile - IEEE
Rappresentazione del personaggio - ASCII

rete

Per la sua funzionalità, il sistema RPC occupa un posto intermedio tra il livello dell'applicazione e il livello di trasporto. Secondo il modello OSI, i livelli di presentazione e sessione corrispondono a questa posizione. Pertanto, RPC è teoricamente indipendente dall'implementazione della rete, in particolare, dai protocolli di rete del livello di trasporto.

Le implementazioni software del sistema, di norma, supportano uno o due protocolli. Ad esempio, il sistema RPC di Sun Microsystems supporta la messaggistica tramite TCP e UDP. La scelta di un protocollo dipende dai requisiti dell'applicazione. La scelta di UDP è giustificata per le applicazioni con le seguenti caratteristiche:

Le procedure chiamate sono idempotenti
La dimensione degli argomenti passati e il risultato restituito è inferiore alla dimensione del pacchetto UDP - 8 Kbyte.
Il server fornisce lavoro con diverse centinaia di client. Dal momento che quando si lavora con i protocolli TCP, il server è costretto a mantenere una connessione con ciascuno dei client attivi, questo occupa una parte significativa delle sue risorse. UDP ha meno risorse in questo senso.

D'altro canto, TCP fornisce un funzionamento efficiente delle applicazioni con le seguenti caratteristiche:

Un'applicazione richiede un protocollo di trasmissione affidabile
Le procedure chiamate sono non componenti
La dimensione degli argomenti o del ritorno è maggiore di 8 KB

La scelta del protocollo di solito rimane con il cliente e il sistema organizza la formazione e la trasmissione di messaggi in diversi modi. Pertanto, quando si utilizza il protocollo TCP, per il quale i dati trasmessi sono un flusso di byte, è necessario separare i messaggi l'uno dall'altro. Per questo, ad esempio, viene utilizzato il protocollo di etichettatura dei record descritto in RFC1057 "RPC: versione 2 della specifica del protocollo di chiamata di procedura remota", in corrispondenza del quale viene inserito un numero intero a 32 bit che definisce la dimensione del messaggio in byte all'inizio di ciascun messaggio.

La situazione con la semantica della chiamata è diversa. Ad esempio, se RPC viene eseguito utilizzando un protocollo di trasporto non affidabile (UDP), il sistema ritrasmette il messaggio a brevi intervalli (timeout). Se l'applicazione client non riceve una risposta, possiamo affermare con certezza che la procedura è stata eseguita zero o più volte. Se è stata ricevuta una risposta, l'applicazione può concludere che la procedura è stata eseguita almeno una volta. Quando si utilizza un protocollo di trasporto affidabile (TCP) in caso di ricezione di una risposta, si può dire che la procedura è stata eseguita una volta. Se la risposta non viene ricevuta, è sicuramente impossibile affermare che la procedura non è stata completata3.

Come funziona

In sostanza, il sistema RPC stesso è incorporato nel programma client e nel programma server. È gratificante che quando si sviluppano applicazioni distribuite, non è necessario approfondire i dettagli del protocollo RPC o l'elaborazione dei messaggi di programma. Il sistema presuppone l'esistenza di un ambiente di sviluppo adeguato, che facilita notevolmente la vita dei creatori di software applicativo. Uno dei punti chiave in RPC è che lo sviluppo di un'applicazione distribuita inizia con la definizione dell'interfaccia di un oggetto: una descrizione formale delle funzioni del server realizzate in un linguaggio speciale. Sulla base di questa interfaccia, vengono quindi creati automaticamente gli stub client e server. L'unica cosa che deve essere fatta dopo questo è scrivere il codice di procedura effettivo.

Ad esempio, prendere in considerazione l'RPC di Sun Microsystems. Il sistema è composto da tre parti principali:

rpcgen (1) è un compilatore RPC che, in base alla descrizione dell'interfaccia di procedura remota, genera stub client e server sotto forma di programmi C.
La libreria XDR (eXternal Data Representation), che contiene funzioni per convertire vari tipi di dati in una forma indipendente dalla macchina, consentendo lo scambio di informazioni tra sistemi eterogenei.
Una libreria di moduli che garantiscono il funzionamento del sistema nel suo insieme.

Si consideri un esempio di una semplice applicazione di registrazione eventi distribuita. Il client, all'avvio, richiama una procedura remota per scrivere un messaggio nel file di registro del computer remoto.

Per fare ciò, dovrai creare almeno tre file: la specifica delle interfacce delle procedure remote log.x (nel linguaggio di descrizione dell'interfaccia), il testo effettivo delle procedure remote log.c e il testo del programma client principale main () - client.c (in C).

Il compilatore rpcgen (l) crea tre file in base alla specifica log.x: il testo degli stub client e server in C (log clnt.c e log svc.c) e il file di descrizione log.h utilizzato da entrambi gli stub.

Quindi, considereremo i codici sorgente dei programmi.

Questo file specifica i parametri di registrazione della procedura remota - numeri di programma, versioni e procedure e definisce anche l'interfaccia di chiamata - argomenti di input e valori di ritorno. Pertanto, viene definita la procedura RLOG, che accetta una stringa come argomento (che verrà scritto nel registro) e il valore restituito indica in modo standard l'esecuzione corretta o non riuscita dell'operazione ordinata.

programma LOG_PROG ( versione LOG_VER ( int RLOG (stringa) \u003d 1; ) \u003d 1; ) \u003d 0x31234567;

Il compilatore rpcgen (l) crea il file di intestazione log.h, dove, in particolare, sono definite le procedure:

Valuta attentamente questo file. Il compilatore traduce il nome RLOG definito nel file di descrizione dell'interfaccia in rlog_1, sostituendo i caratteri maiuscoli con minuscoli e aggiungendo il numero di versione del programma con un carattere di sottolineatura. Il tipo del valore restituito è cambiato da int a int *. Questa è la regola: RPC consente di inviare e ricevere solo gli indirizzi dichiarati nella descrizione dei parametri dell'interfaccia. La stessa regola si applica alla stringa passata come argomento. Anche se ciò non segue dal file print.h, in realtà, l'indirizzo della riga viene anche passato come argomento alla funzione rlog_l ().

Oltre al file di intestazione, il compilatore rpcgen (l) crea moduli stub client e stub server. In sostanza, il testo di questi file contiene tutto il codice per la chiamata remota.

Lo stub del server è il programma principale che elabora tutte le interazioni di rete con il client (più precisamente, con il suo stub). Per eseguire l'operazione, lo stub del server effettua una chiamata locale alla funzione, il cui testo deve essere scritto:

Lo stub client accetta l'argomento passato alla procedura remota, effettua le trasformazioni necessarie, genera una richiesta al server portmap (1M), scambia dati con il server della procedura remota e infine passa il valore restituito al client. Per un client, chiamare una procedura remota si riduce a chiamare uno stub e non è diverso da una normale chiamata locale.

client.c

#include #include "Log.h" principale(int argc, carbonizzare * argv) (CLIENTE * cl; carbonizzare * server, * mystring, * clnttime; time_t bintime int * risultato; se (argc! \u003d 2) (fprintf (stderr, "Formato chiamata:% s host_address \\ n", argv); exit (1);) server \u003d argv; / * Ottieni l'handle del client. In caso di errore, ti informeremo sull'impossibilità di stabilire una comunicazione con il server * / se ((c1 \u003d clnt_create (server, LOG_PROG, LOG_VER, "udp")) \u003d\u003d NULL) (clnt_pcreateerror (server); exit (2);) / * Seleziona il buffer per la stringa * / mystring \u003d ( carbonizzare *) malloc (100); / * Definire l'ora dell'evento * / bintime \u003d time ((time_t *) NULL); clnttime \u003d ctime (& bintime); sprintf (mystring, "% s - Client in esecuzione", clnttime); / * Passiamo un messaggio per il registro - l'ora in cui il client ha iniziato a funzionare. In caso di errore - segnala un errore * / se ((risultato \u003d rlog_l (& mystring, cl)) \u003d\u003d NULL) (fprintf (stderr, "error2 \\ n"); clnt_perror (cl, server); exit (3);) / * In caso di errore sul computer remoto, segnaleremo un errore * / se (* risultato! \u003d 0) fprintf (stderr, "Registrazione errori \\ n"); / * 0 maniglia libera * / cint destroy (cl); uscita (0); )

Lo stub client log_clnt.c viene compilato con il modulo client.c per ottenere l'eseguibile client.

Ora su alcuni host server.nowhere.ru devi avviare il processo del server:

$ logger

Quindi, quando il client rlog si avvia su un altro computer, il server aggiungerà la voce corrispondente al file di registro.

Lo schema operativo RPC in questo caso è mostrato in Fig. 1. I moduli interagiscono come segue:

All'avvio del processo del server, crea un socket UDP e associa qualsiasi porta locale a questo socket. Successivamente, il server chiama la funzione di libreria svc_register (3N) per registrare i numeri di programma e la sua versione. Per fare ciò, la funzione chiama il processo portmap (IM) e passa i valori richiesti. Il server portmap (IM) di solito si avvia quando il sistema viene inizializzato e comunica con una porta nota. Ora portmap (3N) conosce il numero di porta per il nostro programma e versione. Il server è in attesa di una richiesta. Si noti che tutte le azioni descritte vengono eseguite dallo stub del server creato dal compilatore rpcgen (IM).
All'avvio del programma rlog, la prima cosa da fare è chiamare la funzione di libreria clnt_create (3N), indicando l'indirizzo del sistema remoto, i numeri di programma e versione e il protocollo di trasporto. La funzione invia una richiesta al server portmap (IM) del sistema server.nowhere.m remoto e ottiene il numero di porta remota per il server di registro.
Il client chiama la procedura rlog_1 () definita nello stub client e trasferisce il controllo allo stub. Ciò, a sua volta, forma una richiesta (conversione degli argomenti in formato XDR) sotto forma di un pacchetto UDP e lo invia alla porta remota ricevuta dal server portmap (IM). Quindi aspetta qualche istante per una risposta e, se non ricevuta, invia nuovamente la richiesta. In circostanze favorevoli, la richiesta viene accettata dal server logger (modulo stub server). Lo stub determina quale funzione è stata chiamata (dal numero di procedura) e chiama la funzione rlog_1 () del modulo log.c. Dopo aver restituito il controllo allo stub, quest'ultimo converte il valore restituito dalla funzione rlog_1 () nel formato XDR e forma una risposta anche sotto forma di pacchetto UDP. Dopo aver ricevuto la risposta, lo stub del client recupera il valore restituito, lo converte e lo restituisce al programma principale del client