Remote Procedure Call (RPC): co­mu­ni­ca­zio­ne ef­fi­cien­te in ar­chi­tet­tu­re client-server

Il Remote Procedure Call (it. “chiamata di procedura remota”) è uno strumento centrale per rea­liz­za­re strutture operative e basate sulla ri­par­ti­zio­ne del lavoro in reti e ar­chi­tet­tu­re client-server. Di seguito viene spiegato come avviene la coo­pe­ra­zio­ne tra computer separati fi­si­ca­men­te tramite chiamate RPC, a quali livelli si svolge e dove viene uti­liz­za­ta.

Il termine Remote Procedure Call, in italiano “chiamata di procedura remota”, descrive un concetto che regola la co­mu­ni­ca­zio­ne tra processi, cioè lo scambio di in­for­ma­zio­ni tra i processi del sistema.

Nel 1984, gli in­for­ma­ti­ci Andrew Birrell e Bruce Nelson de­fi­ni­ro­no il concetto di RPC come un mec­ca­ni­smo sincrono “che tra­sfe­ri­sce il flusso di controllo e i dati at­tra­ver­so una chiamata di procedura tra due spazi di indirizzo su una rete a banda stretta”. At­tra­ver­san­do uno spazio d’indirizzo, si possono avviare processi su un computer remoto e coin­vol­ge­re ope­ra­ti­va­men­te istanze esterne nei processi di calcolo e di ela­bo­ra­zio­ne dati. Il processo di co­mu­ni­ca­zio­ne tramite RPC comprende il tra­sfe­ri­men­to dei parametri e la re­sti­tu­zio­ne di un valore di funzione. Spesso non si limita a una sola chiamata, poiché nella pratica vengono elaborate più richieste in parallelo.

In de­fi­ni­ti­va, il concetto di RPC mira ad allineare i livelli di ela­bo­ra­zio­ne: ideal­men­te, i pro­gram­ma­to­ri e gli utenti non do­vreb­be­ro pre­oc­cu­par­si della procedura di chiamata. Le chiamate da remoto do­vreb­be­ro quindi essere, in linea di principio, di facile at­tua­zio­ne come le chiamate di procedura locale (principio di tra­spa­ren­za). Nelle reti e nelle ar­chi­tet­tu­re client-server, le chiamate RPC sono sinonimo di co­mu­ni­ca­zio­ne bi­di­re­zio­na­le orientata ai compiti. Esse com­ple­ta­no la co­mu­ni­ca­zio­ne puramente orientata al messaggio, che segue il paradigma d’ingresso e uscita (uso delle funzioni I/O).

Le chiamate RPC sono oggi uti­liz­za­te in molte aree. Esse sono un elemento fon­da­men­ta­le nei servizi web (ad es. sotto forma di pro­to­col­lo XML-RPC per le chiamate di funzioni remote via HTTP) e con­sen­to­no la rea­liz­za­zio­ne di ap­pli­ca­zio­ni di­stri­bui­te (Di­stri­bu­ted Ap­pli­ca­tions) in cui diversi computer con­di­vi­do­no risorse e compiti. Tra queste rientrano servizi di cloud computing, sistemi bancari e di pre­no­ta­zio­ne nel settore viaggi e database. Altri campi di ap­pli­ca­zio­ne sono i cluster (High Avai­la­bi­li­ty Cluster), reti peer-to-peer de­cen­tra­liz­za­te, così come bloc­k­chains (ad esempio di crip­to­va­lu­te), che spesso sfruttano anche la tec­no­lo­gia RPC.

Le chiamate di procedura remota sono es­sen­zia­li anche per i sistemi operativi odierni. Windows, ad esempio, le usa per eseguire molte routine che sono co­stan­te­men­te in ese­cu­zio­ne. Ad esempio, il servizio fax, la coda di stampa o le con­nes­sio­ni di rete stabilite uti­liz­za­no 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), svi­lup­pa­to da Sun Mi­cro­sy­stems, gioca un ruolo im­por­tan­te. Utilizza le chiamate RPC tra client e server ad esempio per montare, cioè rendere di­spo­ni­bi­le, in parte o in­te­ra­men­te, 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 sta­bi­li­sco­no i diritti di lettura e scrittura. Anche il Network In­for­ma­tion System (NIS) utilizza RPC e quindi gestisce a livello cen­tra­liz­za­to i sistemi UNIX e Linux.

Il pro­to­col­lo RPC gestisce la co­mu­ni­ca­zio­ne tra processi in modo af­fi­da­bi­le e richiede tempi di ela­bo­ra­zio­ne re­la­ti­va­men­te brevi. La pro­gram­ma­zio­ne dei processi di co­mu­ni­ca­zio­ne dei computer remoti è molto semplice, poiché, ad esempio, non è ne­ces­sa­rio prestare at­ten­zio­ne ai dettagli complessi della rete uti­liz­za­ta. Inoltre, il concetto di RPC consente una mo­du­la­riz­za­zio­ne coerente. I processi possono essere ester­na­liz­za­ti, al­leg­ge­ren­do così i singoli computer. Le reti e i sistemi di­stri­bui­ti possono lavorare in modo più ef­fi­cien­te grazie alla ri­par­ti­zio­ne del lavoro, uti­liz­zan­do piat­ta­for­me spe­cia­liz­za­te per compiti par­ti­co­la­ri (ad esempio server banca dati). I pro­ta­go­ni­sti coinvolti possono essere collegati in rete in qualsiasi parte del mondo. Ulteriori vantaggi sono la sca­la­bi­li­tà ec­cel­len­te delle ar­chi­tet­tu­re client-server rea­liz­za­te e la pos­si­bi­li­tà di un lavoro meno com­pli­ca­to basato sul cloud.

Uno degli svantaggi della tec­no­lo­gia RPC è il fatto che non esiste uno standard uniforme per le chiamate RPC. Le varie im­ple­men­ta­zio­ni, per lo più spe­ci­fi­che per l’azienda, (ad es. ONC-RPC di Sun) di solito non sono com­pa­ti­bi­li tra loro. Inoltre, i livelli di tra­sfe­ri­men­to e di tra­smis­sio­ne dei sistemi basati su RPC com­por­ta­no una certa perdita di velocità, cosa che non avviene per le chiamate di procedura puramente locali. Poiché client e server uti­liz­za­no ambienti di ese­cu­zio­ne diversi per le ri­spet­ti­ve routine, l’utilizzo delle risorse (come i file) diventa più com­pli­ca­to. Ne deriva che i sistemi RPC non sono così adatti per il tra­sfe­ri­men­to di grandi quantità di dati.

Inoltre, la di­stri­bu­zio­ne dei dati su diverse istanze di ela­bo­ra­zio­ne aumenta la pos­si­bi­li­tà di errori. I messaggi possono perdersi nella co­mu­ni­ca­zio­ne (errore di rete, guasto di un nodo nella rete), possono ve­ri­fi­car­si ritardi e in­ter­ru­zio­ni. Problemi di tem­pi­sti­ca, doppie ese­cu­zio­ni ri­don­dan­ti (ad esempio chiamate di processo) o asin­cro­nie in­de­si­de­ra­te nella co­mu­ni­ca­zio­ne della macchina sono altri possibili effetti in­de­si­de­ra­ti. Nel RPC sincrono, un problema del server (come un crash) può in­fluen­za­re il client se il processo di chiamata attende invano il valore di ritorno. D’altra parte, il server viene ral­len­ta­to se la risposta del client viene ritardata o non raggiunge il server. Questi possibili errori possono avere effetti di vasta portata, so­prat­tut­to in ar­chi­tet­tu­re con un elevato grado di con­di­vi­sio­ne del lavoro.

A causa di possibili fonti di errore, è ne­ces­sa­rio tenere conto della speciale semantica degli errori RPC, il che rende la pro­gram­ma­zio­ne re­la­ti­va­men­te complessa. I pro­gram­ma­to­ri e gli svi­lup­pa­to­ri di sistemi devono con­si­de­ra­re gli aspetti di sicurezza che i sistemi di­stri­bui­ti e la co­mu­ni­ca­zio­ne tramite RPC e UDP/IP o TCP/IP com­por­ta­no (sicurezza della rete, hacking, attacco denial-of-service, ecc.)