Remote Procedure Call (RPC): comunicazione efficiente in architetture client-server
La redazione di IONOS7 mins
Il Remote Procedure Call (it. “chiamata di procedura remota”) è uno strumento centrale per realizzare strutture operative e basate sulla ripartizione del lavoro in reti e architetture client-server. Di seguito viene spiegato come avviene la cooperazione tra computer separati fisicamente tramite chiamate RPC, a quali livelli si svolge e dove viene utilizzata.
Che cos’è il Remote Procedure Call (RPC)?
Il termine Remote Procedure Call, in italiano “chiamata di procedura remota”, descrive un concetto che regola la comunicazione tra processi, cioè lo scambio di informazioni tra i processi del sistema.
Nel 1984, gli informatici Andrew Birrell e Bruce Nelson definirono il concetto di RPC come un meccanismo sincrono “che trasferisce il flusso di controllo e i dati attraverso una chiamata di procedura tra due spazi di indirizzo su una rete a banda stretta”. Attraversando uno spazio d’indirizzo, si possono avviare processi su un computer remoto e coinvolgere operativamente istanze esterne nei processi di calcolo e di elaborazione dati. Il processo di comunicazione tramite RPC comprende il trasferimento dei parametri e la restituzione di un valore di funzione. Spesso non si limita a una sola chiamata, poiché nella pratica vengono elaborate più richieste in parallelo.
In definitiva, il concetto di RPC mira ad allineare i livelli di elaborazione: idealmente, i programmatori e gli utenti non dovrebbero preoccuparsi della procedura di chiamata. Le chiamate da remoto dovrebbero quindi essere, in linea di principio, di facile attuazione come le chiamate di procedura locale (principio di trasparenza). Nelle reti e nelle architetture client-server, le chiamate RPC sono sinonimo di comunicazione bidirezionale orientata ai compiti. Esse completano la comunicazione puramente orientata al messaggio, che segue il paradigma d’ingresso e uscita (uso delle funzioni I/O).
L’area di competenza delle chiamate RPC è la comunicazione tra diversi computer, ma esse possono contribuire anche alla comunicazione tra diversi processi all’interno di un sistema coerente.
Client-Stub meets Server-Stub: come funziona RPC
Le chiamate RPC seguono sempre un preciso schema: ad esempio, un client contatta un server banca dati quando cerca un pezzo di ricambio. Il server remoto controlla il database e invia il risultato al client. Quest’ultimo elabora i dati ricevuti e visualizza, ad esempio, un elenco dei dati di stock nel software di gestione.
L’implementazione di una chiamata di procedura remota comporta lato mittente e destinatario delle istanze particolari, chiamate stubs (it. “matrice”.) Lo stub del client funge lato client da sostituto della procedura remota del server. Lo stub del server è il sostituto lato server del codice client che effettua la chiamata. Gli stubs simulano operativamente un’unità locale funzionale, nascondendo la “presenza remota” del codice da una parte e dall’altra. Allo stesso tempo fungono da interfacce della procedura. La procedura tipica di una chiamata RPC è caratterizzata dai seguenti passaggi:
- Il codice client chiama una procedura stub (stub del client locale).
- Lo stub del client genera un messaggio inviabile dai parametri inviati nella chiamata di procedura, che aderisce al protocollo RPC. Durante il trasferimento avviene una serializzazione in cui i dati strutturati vengono convertiti in un formato di visualizzazione sequenziale. Questo processo di traduzione è noto anche come Marshalling (dall’ingl. “to marshal”, in italiano “sistemare”, “ordinare”.)
- La stub del client contatta quindi il sistema di comunicazione del computer locale, che per il successivo scambio di messaggi tra client e server utilizza TCP/IP o UDP/IP.
- Dopo l’arrivo del messaggio inviato al destinatario, la stub del server esegue il cosiddetto de- o unmarshalling, andando a scompattare i parametri contenuti nel messaggio (in base al protocollo RPC).
- Lo stub del server trasmette i parametri decodificati e garantisce così la chiamata locale di un server di procedura.
- Il valore della funzione risultante viene comunicato allo stub del server.
- A questo punto il processo si svolge nella direzione opposta: generazione di un messaggio inviabile secondo il protocollo RPC, scambio di messaggi tra server e client, infine trasferimento del valore di ritorno al codice client in attesa. L’applicazione sul computer d’origine prosegue.
Cloud Computing e computercluster: ambiti di applicazione delle chiamate RPC
Le chiamate RPC sono oggi utilizzate in molte aree. Esse sono un elemento fondamentale nei servizi web (ad es. sotto forma di protocollo XML-RPC per le chiamate di funzioni remote via HTTP) e consentono la realizzazione di applicazioni distribuite (Distributed Applications) in cui diversi computer condividono risorse e compiti. Tra queste rientrano servizi di cloud computing, sistemi bancari e di prenotazione nel settore viaggi e database. Altri campi di applicazione sono i cluster (High Availability Cluster), reti peer-to-peer decentralizzate, così come blockchains (ad esempio di criptovalute), che spesso sfruttano anche la tecnologia RPC.
Le chiamate di procedura remota sono essenziali anche per i sistemi operativi odierni. Windows, ad esempio, le usa per eseguire molte routine che sono costantemente in esecuzione. Ad esempio, il servizio fax, la coda di stampa o le connessioni di rete stabilite utilizzano un servizio di sistema che, nelle versioni di sistema di lingua italiana, viene definito “chiamata di procedura remota”.
Nel mondo Unix e Linux il Network File System (NFS), sviluppato da Sun Microsystems, gioca un ruolo importante. Utilizza le chiamate RPC tra client e server ad esempio per montare, cioè rendere disponibile, in parte o interamente, il file system di un computer remoto su un computer locale. Questo metodo permette all’utente di gestire i singoli file di un computer remoto come se fossero sul proprio computer. I permessi definiti per i file stabiliscono i diritti di lettura e scrittura. Anche il Network Information System (NIS) utilizza RPC e quindi gestisce a livello centralizzato i sistemi UNIX e Linux.
Quali sono i vantaggi di RPC?
Il protocollo RPC gestisce la comunicazione tra processi in modo affidabile e richiede tempi di elaborazione relativamente brevi. La programmazione dei processi di comunicazione dei computer remoti è molto semplice, poiché, ad esempio, non è necessario prestare attenzione ai dettagli complessi della rete utilizzata. Inoltre, il concetto di RPC consente una modularizzazione coerente. I processi possono essere esternalizzati, alleggerendo così i singoli computer. Le reti e i sistemi distribuiti possono lavorare in modo più efficiente grazie alla ripartizione del lavoro, utilizzando piattaforme specializzate per compiti particolari (ad esempio server banca dati). I protagonisti coinvolti possono essere collegati in rete in qualsiasi parte del mondo. Ulteriori vantaggi sono la scalabilità eccellente delle architetture client-server realizzate e la possibilità di un lavoro meno complicato basato sul cloud.
Quali sono gli svantaggi di RPC?
Uno degli svantaggi della tecnologia RPC è il fatto che non esiste uno standard uniforme per le chiamate RPC. Le varie implementazioni, per lo più specifiche per l’azienda, (ad es. ONC-RPC di Sun) di solito non sono compatibili tra loro. Inoltre, i livelli di trasferimento e di trasmissione dei sistemi basati su RPC comportano una certa perdita di velocità, cosa che non avviene per le chiamate di procedura puramente locali. Poiché client e server utilizzano ambienti di esecuzione diversi per le rispettive routine, l’utilizzo delle risorse (come i file) diventa più complicato. Ne deriva che i sistemi RPC non sono così adatti per il trasferimento di grandi quantità di dati.
Inoltre, la distribuzione dei dati su diverse istanze di elaborazione aumenta la possibilità di errori. I messaggi possono perdersi nella comunicazione (errore di rete, guasto di un nodo nella rete), possono verificarsi ritardi e interruzioni. Problemi di tempistica, doppie esecuzioni ridondanti (ad esempio chiamate di processo) o asincronie indesiderate nella comunicazione della macchina sono altri possibili effetti indesiderati. Nel RPC sincrono, un problema del server (come un crash) può influenzare il client se il processo di chiamata attende invano il valore di ritorno. D’altra parte, il server viene rallentato se la risposta del client viene ritardata o non raggiunge il server. Questi possibili errori possono avere effetti di vasta portata, soprattutto in architetture con un elevato grado di condivisione del lavoro.
A causa di possibili fonti di errore, è necessario tenere conto della speciale semantica degli errori RPC, il che rende la programmazione relativamente complessa. I programmatori e gli sviluppatori di sistemi devono considerare gli aspetti di sicurezza che i sistemi distribuiti e la comunicazione tramite RPC e UDP/IP o TCP/IP comportano (sicurezza della rete, hacking, attacco denial-of-service, ecc.)
Alcuni problemi derivanti da una sincronicità generale di client e server possono essere risolti con concetti di RPC asincroni, tramite i quali il client non deve necessariamente attendere una risposta dal server. Il flusso del programma può andare avanti ed eseguire altre operazioni dopo una chiamata. La risposta dal server viene elaborata dal client in un secondo momento. Tuttavia, la speciale programmazione delle chiamate RPC asincrone è molto complessa e costosa.
