Qual è il punto di LRPC? Perché qualcuno dovrebbe voler effettuare Remote Procedure Calls sulla stessa macchina?

Question

Da quello che ho capito su RPC (Remote Procedure Calls), è che forniscono un modo per inviare chiamate di funzioni, invocazioni, ecc. A macchine remote. L'ovvio vantaggio di questo è che puoi avere un singolo programma che gira su un cluster di macchine e può gestire più richieste, più dati, e così via.

Ma io sono perplesso LRPC - Lightweight RPC. Apparentemente questa roba esiste per accelerare RPC sulla stessa macchina. Come scritto nel documento I linked to:

Lightweight Remote Procedure Call (LRPC) è una struttura di comunicazione progettata e ottimizzata per la comunicazione tra domini di protezione sul stessa macchina. Nei sistemi operativi moderni a kernel ridotto, i sistemi RPC esistenti comportano un costo inutilmente elevato quando vengono utilizzati per il tipo di comunicazione che predomina tra domini di protezione sulla stessa macchina. Questo costo porta i progettisti di sistemi a unire i sottosistemi debolmente connessi con lo nello stesso dominio di protezione, scambiando la sicurezza per le prestazioni. Riducendo il sovraccarico della comunicazione della stessa macchina , LRPC incoraggia sia la sicurezza che le prestazioni.

La mia domanda è: qual è il punto di RPC se si sta eseguendo tutto sullo stesso computer. Il R sta per REMOTO. Se non vuoi essere remoto, chiamalo semplicemente LPC. Cosa mi manca?

Answer 1

Esistono diversi casi di utilizzo per RPC locale, ma un esempio molto semplice è quando un server ha client sia remoti che locali.

Consideriamo ad esempio un server di stampa basato su RPC:

• si possono avere clienti che si trovano su host remoti (ad esempio, per un server di stampa/condivisione in rete);
• È anche possibile che i client si trovino sull'host stesso del server (in modo che anche le applicazioni locali possano stampare).

Ovviamente, non si desidera scrivere sia un server di stampa per client remoti sia un server di stampa separato per client locali. Pertanto, è molto meglio se l'architettura o il middleware consente di progettare un server di stampa che può essere utilizzato indifferentemente da client remoti (remote RPC) e client locali (RPC locale).

A questo punto, l'architettura o il middleware garantisce un'interfaccia comune sia per i client locali che per i client remoti: in che modo la comunicazione tra processi viene realizzata nella pratica deve essere resa completamente trasparente allo sviluppatore dell'applicazione.

Tuttavia, l'utilizzo della stessa tecnologia di comunicazione tra processi sia per i client remoti che per i client locali può essere inefficiente. Pertanto, è abbastanza comune per l'architettura RPC implementare un tipo di ottimizzazione in modo da ottimizzare le prestazioni quando il server e il client si trovano sullo stesso host. In sostanza, questa ottimizzazione è molto simile al fatto che la comunicazione di rete locale utilizza il ciclo locale piuttosto che andare avanti e indietro tra l'host e la scheda di rete.

Leggero RPC è una soluzione di questo tipo (non è l'unica) che consente di ottimizzare le prestazioni RPC per i client locali. Quando questa ottimizzazione è implementato nell'architettura RPC:

• La stessa interfaccia RPC può essere reso disponibile sia per l per i client remoti:
• Gli sviluppatori di applicazioni non devono gestire il problema che alcuni clienti possono essere locali quando altri client possono essere remoti;
• L'architettura RPC ottimizza le chiamate ai server locali, in modo che i client locali non siano penalizzati da una tecnica IPC remota che non sarebbe ottimale per le comunicazioni locali.