Jaki jest sens LRPC? Dlaczego ktoś chciałby wykonywać zdalne wywołania procedur na tym samym komputerze?

Question

Z tego, co rozumiem na temat RPC (Remote Procedure Calls), jest to, że umożliwiają one wysyłanie wywołań funkcji, wywołań itp. Do komputerów zdalnych. Oczywistą zaletą tego jest to, że możesz mieć pojedynczy program, który działa na klastrze maszyn i może obsługiwać więcej żądań, więcej danych itd.

Ale jestem zaintrygowany przez LRPC - Lightweight RPC. Wygląda na to, że te rzeczy istnieją, aby przyspieszyć RPC na tym samym komputerze. Jak napisano w dokumencie I linked to:

Lightweight Remote Procedure Call (LRPC) jest zakład komunikacji zaprojektowany i zoptymalizowany pod kątem komunikacji między domenami ochrony na tej samej maszynie. We współczesnych systemach operacyjnych z małymi kernetami istniejące systemy RPC ponoszą niepotrzebnie wysoki koszt, gdy są używane dla rodzaju komunikacji, która przeważa - pomiędzy domenami ochrony na tej samej maszynie. Koszt ten sprawia, że ​​projektanci systemów łączą słabo powiązane podsystemy w tej samej domenie ochrony, handlując na poziomie w zakresie bezpieczeństwa. Zmniejszając obciążenie związane z tą samą maszyną, , LRPC zachęca zarówno do bezpieczeństwa, jak i wydajności.

Moje pytanie brzmi: jaki jest sens RPC, jeśli uruchamiasz wszystko na tym samym komputerze. R oznacza ZDALNIE. Jeśli nie będziesz zdalny, po prostu nazwij to LPC. czego mi brakuje?

Answer 1

Istnieje kilka przypadków użycia dla lokalnego wywołania RPC, ale bardzo prostym przykładem jest sytuacja, gdy serwer ma zarówno klientów zdalnych, jak i lokalnych.

Rozważmy na przykład serwer druku RPC oparte:

• może masz klientów znajdujących się na zdalnych hostach (np na sieciowym serwerze wydruku/Udostępnianie);
• Możesz także mieć również klientów znajdujących się na hoście serwera (tak, aby aplikacje lokalne również mogły drukować).

Oczywiście, nie chcesz pisać zarówno serwera wydruku dla klientów zdalnych, jak i osobnego serwera wydruku dla klientów lokalnych. Tak więc jest o wiele lepiej, jeśli architektura lub oprogramowanie pośredniczące umożliwia projektowanie serwera druku, który może być używany obojętnie przez klientów zdalnych (zdalny RPC) i klientów lokalnych (lokalny RPC).

W tym momencie architektura lub oprogramowanie pośredniczące zapewnia wspólny interfejs zarówno dla klientów lokalnych, jak i dla klientów zdalnych: sposób, w jaki komunikacja między procesami jest uzyskiwana w praktyce, musi być w pełni przejrzysty dla twórców aplikacji.

Jednak korzystanie z tej samej technologii komunikacji między procesami zarówno dla klientów zdalnych, jak i dla klientów lokalnych może być nieefektywne. W związku z tym dość powszechna jest architektura RPC, która implementuje jakąś optymalizację, aby zoptymalizować wydajność, gdy serwer i klient znajdują się na tym samym hoście. W duchu ta optymalizacja jest bardzo podobna do faktu, że lokalna komunikacja sieciowa wykorzystuje pętlę lokalną zamiast przechodzenia między hostem a kartą sieciową.

Lekkie RPC jest jednym z takich rozwiązań (nie jest jedynym) umożliwiającym optymalizację wydajności RPC dla lokalnych klientów. Kiedy ta optymalizacja jest realizowana w architekturze RPC:

• Ten sam interfejs RPC mogą być udostępniane zarówno dla lokalnych i zdalnych klientów:
• Twórcy aplikacji nie muszą obsługiwać ten problem, że niektórzy klienci mogą być lokalne gdy inni klienci mogą być zdalni;
• Architektura RPC optymalizuje się pod oknem połączenia z lokalnymi serwerami, dzięki czemu klienci lokalni nie są karani przez jakąś technikę zdalnego IPC, która byłaby nieoptymalna dla lokalnej komunikacji.