Protokół RPC. Mechanizm zdalnego wywoływania procedur to RPC. Wypełnij pole tytułu

Wywoływanie zdalnych procedur RPC Koncepcja wywoływania zdalnych procedur Idea wywoływania zdalnych procedur Zdalne wywoływanie procedur - RPC polega na rozszerzeniu dobrze znanego i zrozumiałego mechanizmu przekazywania kontroli i danych w programie działającym na jednym komputerze na przekazywanie kontroli i danych przez sieć. Narzędzia do zdalnego wywoływania procedur zostały zaprojektowane w celu ułatwienia organizacji przetwarzania rozproszonego.Najwyższą efektywność korzystania z RPC uzyskuje się w tych aplikacjach, w których istnieje interaktywne połączenie między zdalnymi komponentami o krótkim czasie odpowiedzi i stosunkowo niewielkiej ilości przesyłanych danych.

Takie aplikacje nazywane są RPC. Charakterystycznymi cechami wywoływania procedur lokalnych są Asymetria, tzn. Jedna ze stron współpracujących jest inicjatorem Synchronizmu, to znaczy wykonywanie procedury wywoływania zatrzymuje się po wydaniu żądania i wznawia dopiero po powrocie z wywoływanej procedury.

Na początek, ponieważ procedury wywołujące i wywoływane są wykonywane na różnych komputerach, mają one różne przestrzenie adresowe, co stwarza problemy przy przekazywaniu parametrów i wyników, szczególnie jeśli maszyny nie są identyczne. Ponieważ RPC nie może liczyć na pamięć współdzieloną, oznacza, że \u200b\u200bparametry RPC nie powinny zawierać wskaźników do komórek pamięci bez stosu, a wartości parametrów powinny być kopiowane z jednego komputera na drugi.

Kolejna różnica między RPC a połączeniem lokalnym polega na tym, że koniecznie wykorzystuje on podstawowy system komunikacyjny, ale nie powinno to być wyraźnie widoczne ani w definicji procedur, ani w samych procedurach. Oddalenie wprowadza dodatkowe problemy. Wykonanie programu wywołującego i wywoływanej procedury lokalnej na jednej maszynie jest realizowane jako część jednego procesu, ale w implementację RPC zaangażowane są co najmniej dwa procesy - po jednym na każdej maszynie.

W przypadku awarii jednego z nich mogą wystąpić następujące sytuacje, w których procedura wywoływania przypadkowo powoduje osierocenie procedur zdalnych, aw przypadku awaryjnego zakończenia procedur zdalnych procedury wywoływania, które się nie powiodą, będą czekać na odpowiedź z procedur zdalnych bezskutecznie. Ponadto istnieje pewna liczba problemy związane z heterogenicznością języków programowania i środowisk operacyjnych struktur danych i procedur struktur wywołań obsługiwanych w dowolnym języku dla programistów Wsparcie nie jest obsługiwane w ten sam sposób we wszystkich innych językach.

Rozpowszechniona technologia RPC, która leży u podstaw wielu rozproszonych systemów operacyjnych, rozwiązuje te i niektóre inne problemy. Podstawowe operacje RPC Aby zrozumieć działanie RPC, najpierw rozważymy wykonanie lokalnego wywołania procedury w normalnej maszynie działającej autonomicznie. Niech na przykład będzie liczbą wywołań systemowych odczytanych fd, buf, nbytes, gdzie fd jest liczbą całkowitą, buf jest tablicą znaków, nbytes jest liczbą całkowitą .

Aby wykonać wywołanie, procedura wywołania wypycha parametry na stos w odwrotnej kolejności na rysunku 3.1. Po zakończeniu wywołania odczytu umieszcza wartość zwracaną w rejestrze, przenosi adres zwrotny i zwraca kontrolę do procedury wywoływania, która wybiera parametry ze stosu, przywracając go do pierwotnego stanu. Zauważ, że w C parametry można wywoływać albo przez odniesienie według nazwy lub według wartości. W odniesieniu do wywoływanej procedury wartości parametrów są zmiennymi lokalnymi inicjalizowanymi.

Wywołana procedura może je zmienić, a to nie wpłynie na wartość oryginałów tych zmiennych w procedurze wywołującej. Jeśli wskaźnik do zmiennej jest przekazywany do wywoływanej procedury, wówczas zmiana wartości tej zmiennej przez wywoływaną procedurę pociąga za sobą zmianę wartości tej zmiennej dla procedury wywołującej. Jest to bardzo istotne dla RPC. Istnieje również inny mechanizm przekazywania parametrów, który nie jest używany w C. Nazywa się to przywracaniem metodą call-by-copy i polega na tym, że wywołujący musi kopiować zmienne na stos jako wartości, a następnie kopiować je z powrotem po wykonaniu wywołania ponad oryginalne wartości procedury wywoływania.

Decyzję o tym, którego mechanizmu transferu parametrów użyć, podejmują twórcy języka. Czasami zależy to od rodzaju przesyłanych danych, na przykład w C liczby całkowite i inne dane skalarne są zawsze przekazywane przez wartość, a tablice przez odniesienie.

Ryc. 3.1 a stos przed wykonaniem wywołania odczytu b stos podczas wykonywania procedury na stosie po powrocie do programu wywołującego Ideą leżącą u podstaw RPC jest sprawienie, aby zdalne wywołanie procedury wyglądało jak możliwe jak lokalne wywołanie procedury. Innymi słowy, uczynienie RPC transparentnym dla procedury wywołującej nie musi wiedzieć, że wywoływana procedura znajduje się na innym komputerze i odwrotnie: RPC osiąga przejrzystość w następujący sposób.

Gdy wywoływana procedura jest naprawdę zdalna, inna wersja procedury, zwana kodem pośredniczącym klienta, jest umieszczana w bibliotece zamiast procedury lokalnej - kod pośredniczący. Podobnie jak w oryginalnej procedurze, kod pośredniczący jest wywoływany przy użyciu sekwencji wywołującej, jak pokazano na rysunku 3.1, i występuje przerwanie podczas uzyskiwania dostępu do jądra. Tylko, w przeciwieństwie do oryginalnej procedury, nie umieszcza parametrów w rejestrach i nie żąda danych z jądra; zamiast tego generuje komunikat do wysłania do jądra zdalnego komputera. Kroki wykonania RPC Interakcja komponentów oprogramowania podczas wykonywania zdalnego wywołania procedury została zilustrowana na rysunku 3.2. Po wywołaniu kodu pośredniczącego klienta przez program kliencki, jego pierwszym zadaniem jest wypełnienie bufora wysyłaną wiadomością.

W niektórych systemach odcinek klienta ma pojedynczy bufor o stałej długości, który jest wypełniany za każdym razem od samego początku, gdy nadejdzie każde nowe żądanie. W innych systemach bufor komunikatów jest pulą buforów dla poszczególnych pól komunikatów, z których niektóre są już pełne.

Ta metoda jest szczególnie przydatna w przypadkach, gdy pakiet ma format składający się z dużej liczby pól, ale wartości wielu z tych pól nie zmieniają się w zależności od połączenia. Następnie parametry należy przekonwertować do odpowiedniego formatu i wstawić do bufora komunikatów W tym momencie komunikat jest gotowy do przesłania, dlatego w momencie wywołania jądra wykonywane jest przerwanie. Ryc. 3.2 Zdalne wywołanie procedury Gdy jądro zyskuje kontrolę, przełącza konteksty, zapisuje rejestry procesora i kartę pamięci, deskryptory stron, instaluje nową kartę pamięci, która będzie używana do pracy w trybie jądra. Ponieważ konteksty jądra i użytkownika są różne, jądro musi dokładnie skopiować wiadomość do własnej przestrzeni adresowej, aby mieć do niej dostęp, zapamiętać adres docelowy i ewentualnie inne pola nagłówka oraz musi przekazać ją do interfejsu sieciowego.

To kończy pracę po stronie klienta.

Timer transferu jest aktywowany, a jądro może albo przełączać się między dostępnością odpowiedzi, albo przekazywać kontrolę do harmonogramu, który wybierze inny proces do wykonania. W pierwszym przypadku zapytanie jest przyspieszane, ale nie ma programowania wieloprogramowego. Po stronie serwera przychodzące bity są umieszczane przez urządzenie odbierające we wbudowanym buforze lub w pamięci RAM Po otrzymaniu wszystkich informacji generowane jest przerwanie.

Procedura obsługi przerwań sprawdza poprawność danych pakietu i określa, który kod pośredniczący powinien przekazać. Jeśli żaden kod pośredniczący nie oczekuje tego pakietu, moduł obsługi musi albo umieścić go w buforze, albo całkowicie go odrzucić. Jeśli czeka na Ciebie skrót, wiadomość zostanie do niego skopiowana. Na koniec następuje przełączanie kontekstu, w wyniku czego przywracane są rejestry i karta pamięci, przyjmując te wartości, które miały w momencie, gdy kod pośredniczący wykonał połączenie odbierające.

Teraz kod pośredniczący serwera zaczyna działać. Rozpakowuje parametry i wypycha je odpowiednio na stos. Gdy wszystko jest gotowe, następuje połączenie z serwerem. Po zakończeniu procedury serwer przekazuje wyniki do klienta, aby to zrobić, wszystkie opisane powyżej kroki są wykonywane tylko w odwrotnej kolejności. Rysunek 3.3 pokazuje sekwencję poleceń, które muszą być wykonane dla każdego wywołania RPC, a Rysunek 3.4 pokazuje, ile całkowitego czasu wykonania RPC spędza na każdym z 14 kroków opisanych powyżej.

Badania przeprowadzono na wieloprocesorowej stacji roboczej DEC Firefly i chociaż obecność pięciu procesorów koniecznie wpłynęła na wyniki pomiaru, histogram pokazany na rysunku daje ogólne wyobrażenie o procesie wykonywania RPC. Ryc. 3.3 Kroki procedury RPC 3.4 Dystrybucja czasu między 14 etapami wykonania RPC 1. Wywołanie kodu pośredniczącego 2. Przygotuj bufor 3. Spakuj parametry 4. Wypełnij pole nagłówka 5. Oblicz sumę kontrolną w wiadomości 6. Przerwij do jądra 7. Kolejka do wykonania 8. Prześlij wiadomość do kontrolera przez QBUS 9. Czas transmisji Ethernet 10. Odbierz pakiet od kontrolera 11. Procedura przetwarzania przerwań 12. Obliczenie sumy kontrolnej 13. Przełączanie kontekstu do przestrzeni użytkownika 14. Wykonanie kodu pośredniczącego serwera Łączenie dynamiczne Zastanów się, jak kliknąć nt ustawia lokalizację serwera.

Jedną z metod rozwiązania tego problemu jest bezpośrednie użycie adresu sieciowego serwera w programie klienckim.

Wadą tego podejścia jest jego ekstremalna nieelastyczność podczas przenoszenia serwera, zwiększania liczby serwerów lub zmiany interfejsu we wszystkich tych i wielu innych przypadkach, konieczna jest ponowna kompilacja wszystkich programów, które używały twardego ustawienia adresu serwera. Aby uniknąć tych wszystkich problemów, Niektóre systemy rozproszone używają tak zwanego dynamicznego łączenia.

Punktem wyjścia dla dynamicznego łączenia jest formalna definicja specyfikacji serwera. Specyfikacja zawiera nazwę serwera plików, numer wersji oraz listę procedur serwisowych udostępnianych klientom przez ten serwer. Dla każdej procedury podany jest opis jego parametrów, wskazujący, czy parametr ten jest wejściowy czy wyjściowy względem serwera. Niektóre parametry mogą być zarówno wejściowe, jak i wyjściowe, na przykład zmodyfikowana jest tam pewna tablica wysyłana przez klienta do serwera, a następnie operacja jest zwracana z powrotem do klienta przywróć kopię. Ryc. 3.5 Specyfikacja serwera RPC Formalna specyfikacja serwera jest używana jako dane wejściowe do programu generatora kodów pośredniczących, który tworzy kody pośredniczące klienta i serwera.

Następnie są umieszczane w odpowiednich bibliotekach. Gdy program kliencki użytkownika wywołuje dowolną procedurę zdefiniowaną w specyfikacji serwera, odpowiednia procedura pośrednicząca jest powiązana z kodem binarnym programu.

Podobnie, gdy serwer jest kompilowany, kody pośredniczące serwera są z nim powiązane. Po uruchomieniu serwera jego pierwszą czynnością jest przeniesienie interfejsu serwera do specjalnego programu o nazwie binder. Proces ten, znany jako proces rejestracji serwera, polega na przesłaniu przez serwer nazwy, numeru wersji, unikalnego identyfikatora i deskryptora lokalizacji serwera. Deskryptor jest niezależny od systemu i może mieć adres IP, Ethernet, X.500 lub inny adres.

Ponadto może zawierać inne informacje, na przykład związane z uwierzytelnianiem. Gdy klient wywołuje jedną ze zdalnych procedur po raz pierwszy, na przykład czytając, kod pośredniczący klienta widzi, że nie jest jeszcze podłączony do serwera, i wysyła komunikat do programu wiążącego z prośbą o zaimportowanie interfejsu żądanej wersji pożądanego serwera. Jeśli taki serwer istnieje, to segregator przechodzi deskryptor i unikalny identyfikator kodu pośredniczącego klienta.

Kod klienta używa deskryptora jako adresu podczas wysyłania wiadomości żądania. Wiadomość zawiera parametry i unikalny identyfikator, którego rdzeń serwera używa do przekierowania wiadomości przychodzącej na żądany serwer, jeśli jest ich kilka na tym komputerze. Ta metoda importowania interfejsów eksportu jest bardzo elastyczna, na przykład może istnieć kilka serwerów obsługujących ten sam interfejs, a klienci są losowo rozdzielani między serwery.

W ramach tej metody można okresowo przesłuchiwać serwery, analizować ich wydajność, aw przypadku awarii automatycznie wyłączać się, co zwiększa ogólną odporność na awarie systemu. Ta metoda może również obsługiwać uwierzytelnianie klienta. Na przykład serwer może ustalić, że mogą go używać tylko klienci z określonej listy, jednak łączenie dynamiczne ma wady, takie jak dodatkowe obciążenie, czas spędzony na eksportowaniu i importowaniu interfejsów.

Wielkość tych kosztów może być znaczna, ponieważ wiele procesów klienckich istnieje przez krótki czas i na każdym początku procesu procedura importowania interfejsu musi zostać wykonana ponownie. Ponadto w dużych systemach rozproszonych program wiążący może stać się wąskim gardłem, a tworzenie kilku programów o podobnym celu również zwiększa obciążenie związane z tworzeniem i synchronizacją procesów. Semantyka RPC w przypadku awarii Idealnie RPC powinien działać poprawnie w przypadku awarii.

Rozważ następujące klasy awarii: 1. Klient nie może określić lokalizacji serwera, na przykład w przypadku awarii żądanego serwera lub ponieważ program klienta został skompilowany dawno temu i użył starej wersji interfejsu serwera. W takim przypadku w odpowiedzi na żądanie klienta zostaje odebrany komunikat zawierający kod błędu. 2. Zgłoszenie klienta do serwera zostało utracone Najprostszym rozwiązaniem jest powtórzenie żądania po pewnym czasie. 3. Utracono komunikat odpowiedzi z serwera do klienta.

Ta opcja jest bardziej skomplikowana niż poprzednia, ponieważ niektóre procedury nie są idempotentne. Wywoływana jest idempotentna procedura, której żądanie wykonania można powtórzyć kilka razy, a wynik nie ulegnie zmianie. Przykładem takiej procedury jest odczytanie pliku, ale procedura wypłaty określonej kwoty z konta bankowego nie jest idempotentna, aw przypadku utraty odpowiedzi drugie żądanie może znacznie zmienić stan konta klienta.

Jednym z możliwych rozwiązań jest doprowadzenie wszystkich procedur do idempotentnej formy. Jednak w praktyce nie zawsze jest to możliwe, dlatego można zastosować inną metodę - sekwencyjne numerowanie wszystkich żądań przez rdzeń klienta. Rdzeń serwera zapamiętuje liczbę ostatniego żądania od każdego klienta, a po otrzymaniu każdego żądania analizuje, czy to żądanie jest pierwotne, czy powtórzone. 4. Serwer zawiesił się po otrzymaniu żądania Właściwość idempotency jest tutaj również ważna, ale niestety nie można zastosować podejścia z żądaniami numeracji.

W takim przypadku ma to znaczenie, kiedy wystąpiła awaria - przed lub po operacji. Ale rdzeń klienta nie może rozpoznać tych sytuacji, ponieważ wie tylko, że upłynął czas odpowiedzi. Istnieją trzy podejścia do tego problemu: Poczekaj, aż serwer uruchomi się ponownie i spróbuj wykonać operację ponownie. Takie podejście gwarantuje, że RPC zostało zakończone co najmniej raz, a może nawet więcej. Natychmiast poinformuj aplikację o błędzie.

Takie podejście zapewnia, że \u200b\u200bRPC zostało zakończone nie więcej niż raz. Trzecie podejście niczego nie gwarantuje. Gdy serwer zawiedzie, nie ma obsługi klienta. RPC może, ale nie musi, być wykonywane w ogóle lub wykonywane wielokrotnie. W każdym razie ta metoda jest bardzo łatwa do wdrożenia. Żadne z tych podejść nie jest bardzo atrakcyjne, a idealna opcja, która gwarantowałaby dokładnie jedną implementację RPC, w ogólnym przypadku nie może być wdrożona z podstawowych powodów.

Załóżmy na przykład, że operacja zdalna polega na wydrukowaniu tekstu, który obejmuje załadowanie bufora drukarki i ustawienie jednego bitu w określonym rejestrze sterującym drukarki, w wyniku czego drukarka się uruchomi. Awaria serwera może wystąpić zarówno w mikrosekundie przed, jak i w mikrosekundie po ustawieniu bitu kontrolnego. Moment awarii całkowicie determinuje procedurę odzyskiwania, ale klient nie może dowiedzieć się o momencie awarii.

Krótko mówiąc, możliwość awarii serwera radykalnie zmienia naturę RPC i wyraźnie odzwierciedla różnicę między systemem scentralizowanym a rozproszonym. W pierwszym przypadku awaria serwera prowadzi do awarii klienta i odzyskanie nie jest możliwe. W drugim przypadku działania mające na celu przywrócenie systemu są możliwe i konieczne. 1. Klient zawiesił się po wysłaniu żądania. W takim przypadku obliczenia są wykonywane w sposób, którego nikt się nie spodziewa. Takie obliczenia nazywane są sierotami. Obecność sierot może powodować różne problemy związane z czasem procesora, blokując zasoby, zastępując odpowiedź na bieżące żądanie odpowiedzią na żądanie wysłane przez komputer kliencki przed zrestartowaniem systemu.

Co zrobić z sierotami? Rozważ 4 możliwe rozwiązania. Zniszczenie Zanim odcinek klienta wyśle \u200b\u200bkomunikat RPC, zapisuje w dzienniku informację, co teraz zrobi: dziennik jest przechowywany na dysku lub w innej odpornej na uszkodzenia pamięci.

Po wypadku system uruchamia się ponownie, dziennik jest analizowany, a sieroty likwidowane. Wady tego podejścia obejmują, po pierwsze, zwiększone koszty związane z pisaniem o każdym RPC na dysk, a po drugie, możliwą nieefektywność z powodu pojawienia się sierot drugiej generacji generowanych przez wywołania RPC generowane przez sieroty pierwszej generacji. Reinkarnacja: w tym przypadku wszystkie problemy są rozwiązywane bez użycia zapisu na dysk. Metoda polega na dzieleniu czasu na kolejno ponumerowane okresy. Gdy klient uruchomi się ponownie, wysyła wiadomość rozgłoszeniową na wszystkie maszyny o początku nowego okresu.

Po otrzymaniu tej wiadomości wszystkie usunięte obliczenia są usuwane. Oczywiście, jeśli sieć jest podzielona na segmenty, niektóre sieroty mogą przeżyć. Miękka transformacja jest podobna do poprzedniej, z tym wyjątkiem, że nie wszystkie usunięte obliczenia są przeszukiwane i niszczone, a jedynie obliczenia klienta restartującego się. Wygaśnięcie ważności Każde żądanie ma standardowy czas T, w którym musi zostać wypełniony.

Jeśli żądanie nie zostanie zakończone w wyznaczonym czasie, przydzielana jest dodatkowa kwantowa. Chociaż wymaga to dodatkowej pracy, ale jeśli po wypadku klienta serwer czeka na przerwę T przed ponownym uruchomieniem klienta, wszystkie sieroty są koniecznie niszczone. W praktyce żadne z tych podejść nie jest pożądane, ponadto zniszczenie sierot może pogorszyć sytuację. Na przykład pozwól sierocie zablokować jeden lub więcej plików bazy danych.

Jeśli sierota zostanie nagle zniszczona, wówczas te blokady pozostaną, ponadto zniszczone sieroty mogą pozostać w różnych kolejkach systemowych, w przyszłości mogą powodować wykonywanie nowych procesów itp.

Co zrobimy z otrzymanym materiałem:

Jeśli ten materiał jest dla Ciebie przydatny, możesz zapisać go na swojej stronie w sieciach społecznościowych:

Wykład 4

4.1 Pojęcie zdalnego wywołania procedury

Pomysł wywołania procedur zdalnych (Zdalne wywołanie procedury - RPC) polega na rozszerzeniu dobrze znanego i zrozumiałego mechanizmu przesyłania kontroli i danych w programie uruchomionym na jednej maszynie na transfer kontroli i danych przez sieć. Narzędzia do zdalnego wywoływania procedur zostały zaprojektowane w celu ułatwienia organizacji przetwarzania rozproszonego. Największą efektywność korzystania z RPC osiąga się w tych aplikacjach, w których istnieje interaktywne połączenie między zdalnymi komponentami o krótkim czasie odpowiedzi i stosunkowo niewielkiej ilości przesyłanych danych. Takie aplikacje nazywane są RPC.

Cechami charakterystycznymi wywoływania procedur lokalnych są: asymetria, to znaczy inicjator; synchronizacja, czyli wykonanie procedury wywołującej, gdy zatrzymuje się od momentu wydania żądania i wznawia dopiero po powrocie z wywoływanej procedury.

Wdrażanie zdalnych wywołań jest znacznie bardziej skomplikowane niż wdrażanie lokalnych wywołań procedur. Na początek, ponieważ procedury wywołujące i wywoływane są wykonywane na różnych komputerach, mają one różne przestrzenie adresowe, co stwarza problemy przy przekazywaniu parametrów i wyników, zwłaszcza jeśli maszyny nie są identyczne. Ponieważ RPC nie może liczyć na pamięć współdzieloną, oznacza to, że parametry RPC nie powinny zawierać wskaźników do komórek pamięci bez stosu, a wartości parametrów powinny być kopiowane z jednego komputera na drugi. Kolejna różnica między RPC a połączeniem lokalnym polega na tym, że koniecznie wykorzystuje on podstawowy system komunikacyjny, ale nie powinno to być wyraźnie widoczne ani w definicji procedur, ani w samych procedurach. Oddalenie wprowadza dodatkowe problemy. Wykonanie programu wywołującego i wywoływanej procedury lokalnej na jednym komputerze jest realizowane jako część jednego procesu. Ale w implementację RPC zaangażowane są co najmniej dwa procesy - po jednym na każdej maszynie. W przypadku awarii jednego z nich mogą wystąpić następujące sytuacje: w przypadku wypadku procedury wywoływania procedury wywoływane zdalnie zostaną „osierocone”, a jeśli procedury zdalne zakończą się niepowodzeniem, procedury wywołujące zostaną „pozbawione rodziców”, co na próżno będzie czekać na odpowiedź z procedur zdalnych.

Ponadto istnieje wiele problemów związanych z heterogenicznością języków programowania i środowisk operacyjnych: struktury danych i struktury wywołań procedur obsługiwane w jednym języku programowania nie są obsługiwane w ten sam sposób we wszystkich innych językach.

Rozpowszechniona technologia RPC, która leży u podstaw wielu rozproszonych systemów operacyjnych, rozwiązuje te i niektóre inne problemy.

Podstawowe operacje RPC

Aby zrozumieć działanie RPC, najpierw rozważamy wykonanie lokalnego wywołania procedury na zwykłej maszynie, która działa autonomicznie. Niech to będzie na przykład wywołanie systemowe

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

gdzie fd jest liczbą całkowitą;

buf - tablica znaków;

nbytes jest liczbą całkowitą.

Aby wykonać połączenie, procedura wywołania wypycha parametry na stos w odwrotnej kolejności. Po zakończeniu wywołania odczytu umieszcza wartość zwracaną w rejestrze, przenosi adres zwrotny i zwraca kontrolę do procedury wywoływania, która wybiera parametry ze stosu, przywracając go do pierwotnego stanu. Zauważ, że w C parametry mogą być wywoływane albo przez odwołanie (według nazwy) albo przez wartość (według wartości). W odniesieniu do wywoływanej procedury wartości parametrów są zmiennymi lokalnymi inicjalizowanymi. Wywołana procedura może je zmienić, a to nie wpłynie na wartość oryginałów tych zmiennych w procedurze wywołującej.

Jeżeli wskaźnik do zmiennej jest przekazywany do wywoływanej procedury, wówczas zmiana wartości tej zmiennej przez wywoływaną procedurę pociąga za sobą zmianę wartości tej zmiennej dla procedury wywołującej. Ten fakt jest bardzo istotny dla RPC.

Istnieje również inny mechanizm przekazywania parametrów, który nie jest używany w C. Nazywa się to call-by-copy / restore i polega na tym, że osoba wywołująca musi skopiować zmienne na stos jako wartości, a następnie skopiować je z powrotem po wykonaniu wywołania ponad oryginalne wartości procedury wywoływania.

Decyzję o tym, którego mechanizmu transferu parametrów użyć, podejmują twórcy języka. Czasami zależy to od rodzaju przesyłanych danych. Na przykład w C liczby całkowite i inne dane skalarne są zawsze przekazywane przez wartość, a tablice przez odniesienie.

Idea RPC polega na tym, aby wywołanie procedury zdalnej wyglądało tak, jak to możliwe, jak wywołanie procedury lokalnej. Innymi słowy, uczyń RPC przejrzystym: procedura wywołująca nie musi wiedzieć, że wywoływana procedura znajduje się na innym komputerze i odwrotnie.

RPC osiąga przejrzystość w następujący sposób. Gdy wywoływana procedura jest naprawdę zdalna, inna wersja procedury, zwana skrótem klienta (skrót, to skrót), jest umieszczana w bibliotece zamiast procedury lokalnej. Podobnie jak w oryginalnej procedurze, kod pośredniczący jest wywoływany przy użyciu sekwencji wywołującej i podczas uzyskiwania dostępu do jądra występuje przerwanie. Tylko, w przeciwieństwie do oryginalnej procedury, nie umieszcza parametrów w rejestrach i nie żąda danych z jądra; zamiast tego generuje komunikat do wysłania do jądra zdalnego komputera.

Etapy RPC

Interakcja komponentów oprogramowania podczas wykonywania zdalnego wywołania procedury została zilustrowana na rysunku 2.

Rysunek 2. Zdalne wywołanie procedury

Po wywołaniu kodu pośredniczącego klienta przez program kliencki, jego pierwszym zadaniem jest wypełnienie bufora wysyłaną wiadomością. W niektórych systemach odcinek klienta ma pojedynczy bufor o stałej długości, który jest wypełniany za każdym razem od samego początku, gdy nadejdzie każde nowe żądanie. W innych systemach bufor komunikatów jest pulą buforów dla poszczególnych pól komunikatów, z których niektóre są już pełne. Ta metoda jest szczególnie przydatna w przypadkach, gdy pakiet ma format składający się z dużej liczby pól, ale wartości wielu z tych pól nie zmieniają się w zależności od połączenia.

Następnie parametry należy przekonwertować do odpowiedniego formatu i wstawić do bufora komunikatów. W tym momencie wiadomość jest gotowa do przesłania, dlatego w wywołaniu jądra wykonywane jest przerwanie.

Kiedy jądro otrzymuje kontrolę, przełącza konteksty, zapisuje rejestry procesora i kartę pamięci (deskryptory stron), instaluje nową kartę pamięci, która będzie używana do pracy w trybie jądra. Ponieważ konteksty jądra i użytkownika są różne, jądro musi dokładnie skopiować wiadomość do własnej przestrzeni adresowej, aby mieć do niej dostęp, zapamiętać adres docelowy (i ewentualnie inne pola nagłówka), a także musi przekazać go do interfejsu sieciowego. To kończy pracę po stronie klienta. Timer transferu jest aktywowany, a jądro może albo przełączać się między dostępnością odpowiedzi, albo przekazywać kontrolę do harmonogramu, który wybierze inny proces do wykonania. W pierwszym przypadku zapytanie jest przyspieszane, ale nie ma programowania wieloprogramowego.

Po stronie serwera przychodzące bity są umieszczane przez sprzęt odbiorczy we wbudowanym buforze lub w pamięci RAM. Po otrzymaniu wszystkich informacji generowane jest przerwanie. Procedura obsługi przerwań sprawdza poprawność danych pakietu i określa, do którego kodu pośredniego powinien zostać przesłany. Jeśli żaden kod pośredniczący nie spodziewa się tego pakietu, moduł obsługi musi albo umieścić go w buforze, albo całkowicie go odrzucić. Jeśli czeka na Ciebie skrót, wiadomość zostanie do niego skopiowana. Na koniec następuje przełączanie kontekstu, w wyniku czego przywracane są rejestry i karta pamięci, przyjmując te wartości, które miały w momencie, gdy kod pośredniczący wykonał połączenie odbierające.

Rysunek 3 pokazuje sekwencję poleceń, które należy wykonać dla każdego wywołania RPC.

Rysunek 3. Kroki procesu RPC

Struktura systemu operacyjnego Windows dowolnej modyfikacji, począwszy od wersji XP, zawiera komponent usługi, zwany RPC. Zwykle zwykli użytkownicy nie wiedzą, co to jest, a ponadto nie wiedzą, do czego służy ta usługa i jak działa. W związku z tym proponuje się rozważenie niektórych podstawowych aspektów związanych z samym komponentem, zasadami jego działania i zakresem użytkowania bez opisu niepotrzebnych i skomplikowanych terminów technicznych. Zastanowimy się osobno nad możliwymi błędami serwisowymi i metodami ich szybkiego usuwania.

Procedury zdalne (wywoływanie procedur zdalnych): co to jest?

Najwyraźniej wielu użytkowników, w oparciu o nazwę tego komponentu usługi, już doszło do wniosku, że tak jest. Rzeczywiście, procedury zdalne (wywoływanie procedur zdalnych) implikują pewne działania, gdy są wykonywane nie na komputerze lokalnym, ale na komputerze zdalnym (najczęściej na serwerze).

Oznacza to, że żądanie jest tworzone na jednym terminalu, a następnie przesyłane do drugiego, gdzie jest wykonywane, po czym odpowiedź (raport) z wykonania jest zwracana do pierwszego komputera. Ale to tylko prymitywne wyjaśnienie. W rzeczywistości wszystko jest znacznie bardziej skomplikowane, ponieważ tutaj należy wziąć pod uwagę protokoły przesyłania danych (UDP, TCP, HTTP) i wiele innych mechanizmów.

Do czego służy ta usługa?

Pomimo swojego głównego celu zdalne wywoływanie procedur RPC może być stosowane nie na różnych komputerach, ale na jednym. Jako najprostszy przykład można wywołać funkcję jednego programu z innej aplikacji. Wielu muzyków pracujących z wirtualnymi studiami nagrywającymi i sekwencerami wie, że każda taka aplikacja ma własny moduł edycji lub przetwarzania dźwięku, który nie zawsze spełnia wymagania określone przez użytkownika. Każde studio pozwala zamiast tego podłączyć dowolny inny program zewnętrzny.

Na przykład w ustawieniach sekwencera FL Studio możesz określić inną aplikację (np. Adobe Audition), która będzie domyślnie używana do edycji plików dźwiękowych (próbek) w głównym środowisku programu. Jednocześnie połączenie Adobe Audition ze FL Studio nie będzie odbywać się za pośrednictwem wirtualnych hostów, takich jak VST, RTAS lub DX, ale bezpośrednio za pomocą usługi zdalnego wywoływania procedur. Oczywistym jest, że ten przykład nie jest jedynym, ponieważ zakres opisywanego komponentu jest znacznie szerszy.

Bardzo często usługa ta jest również związana z rozkładem obciążenia obliczeniowego na terminalach, między którymi nawiązywane jest połączenie interaktywne. Jednocześnie, jeżeli obciążenie rozkłada się równomiernie na zasoby obliczeniowe kilku komputerów, maksymalną wydajność można osiągnąć tylko wtedy, gdy wymieniane są małe ilości danych i osiągana jest szybka reakcja między komponentami.

Zdalne wywołanie procedury nie powiodło się: jaki jest powód?

Niestety z powodu tego zapotrzebowania pojawienie się awarii i błędów związanych z tą usługą jest dość częstym zjawiskiem.

W rezultacie niemożliwe staje się nie tylko użycie samego komponentu. Czasami nie jest nawet możliwy dostęp do niektórych ustawień systemu, a Windows XP w ogóle „leci”, po czym przywrócenie go do normalnego stanu pracy może być dość problematyczne. Innym problemem jest narzędzie do odzyskiwania online DISM, które jest częścią systemu operacyjnego.

Z naruszeniami w jego pracy wiąże się pojawienie się błędu 1726, który bezpośrednio wpływa na funkcjonowanie komponentów usługi RPC.

Główne przyczyny takich awarii nazywane są środkami sprawdzania lub przywracania systemu, gdy proces DISM jest aktywny lub nie może poprawnie ukończyć zadania (na przykład, gdy narzędzia DISM i SFC uruchamiają się z dwóch konsol poleceń jednocześnie); gdy usługa działa równolegle z obsługą komponentów RPC; gdy usługa jest blokowana przez oprogramowanie antywirusowe.

Dlatego jeśli wystąpi błąd podczas zdalnego wywołania procedury w systemie Windows 7 i nowszych, pierwszą rzeczą do zrobienia jest zamknięcie DISM, ponowne uruchomienie komputera i ponowne uruchomienie usługi. Jeśli to nie pomoże, możesz spróbować przełączyć się w tryb awaryjny i całkowicie wyłączyć ochronę antywirusową na czas odzyskiwania. Zastanowimy się nad dodatkowymi środkami, które pomogą naprawić wszelkie awarie podczas zdalnego wywoływania procedur i wszelkich modyfikacji systemu Windows. Tymczasem przyjrzyjmy się problemom związanym z wyłączeniem tego komponentu systemu (niestety, ale wielu użytkowników, którzy nie znają istoty problemu, próbują właśnie takie rzeczy).

Czy mogę wyłączyć usługę RPC?

Zobaczmy więc, jak realistyczne jest wyłączenie połączenia z procedurami zdalnymi. W żadnym wypadku nie można wyłączyć zdalnych procedur opartych na zaleceniach programistów. To ważne! Zasadniczo ona sama na to nie pozwoli. Istnieją oczywiście pewne obejścia związane z korzystaniem z dodatkowego oprogramowania, ale z oczywistych powodów nazwy takich aplikacji nie są podawane, ponieważ jeśli są używane nieprawidłowo, cały system może stać się bezużyteczny.

Konsekwencje wyłączenia procesów RPC

Nawet jeśli użytkownikowi uda się w jakiś sposób wyłączyć procedury zdalne (wywoływanie procedur zdalnych), konsekwencje niestety mogą być najbardziej nieprzewidywalne. Jak już wspomniano, system Windows XP może całkowicie przestać działać, a w systemie operacyjnym wyższej rangi może pojawić się ogromna liczba awarii systemu, których nie można wyeliminować, nawet jeśli nie ma dostępu do kluczowych ustawień i parametrów systemu Windows, a nawet w trybie awaryjnym tryb lub przy uruchamianiu z nośników wymiennych. Nie można jednak wywołać zdalnego wywoływania procedur w systemie Windows 10 lub wcześniejszych wersjach systemu operacyjnego. Ta metoda nie jest najłatwiejsza, dlatego podczas jej używania musisz być bardzo ostrożny.

Wyłączanie Lokalizatora dostępu zdalnego

Tak więc głównej usługi RPC nie można wyłączyć. Ale może sens ma dezaktywować niektóre powiązane elementy? Tak, rzeczywiście, jeśli przejdziesz do sekcji usług systemowych i ich komponentów (services.msc), znajdziesz w niej tak zwany lokalizator RPC.

Ale można go dezaktywować bez obawy o pojawienie się katastrofalnych konsekwencji. Po wprowadzeniu edycji jego parametrów należy zatrzymać komponent i ustawić typ uruchamiania na wyłączony. Programy, które mogą używać procedur zdalnych, będą również wywoływać procedury zdalne (bez jego pomocy).

Jeśli z jakiegoś powodu ustawione parametry nie działają, możesz użyć dysku instalacyjnego systemu Windows, podczas uruchamiania z niego wywołaj wiersz poleceń i wprowadź następujące informacje:

cd X: \\ i386 (X to litera dysku);
rozwiń explorer.ex_% TEMP% \\ explorer.exe;
rozwiń svchost.ex_% TEMP% \\ svchost.exe.

Po ponownym uruchomieniu wywoływany jest „Menedżer zadań”, a następnie w wierszu poleceń zapisywana jest kopia kombinacji% TEMP% \\ explorer.exe% SYSTEMROOT% / y, po czym absolutnie wszystkie procesy svchost zostają zakończone w „Menedżerze zadań”. Teraz powinieneś być szczególnie ostrożny, ponieważ na końcu procesu, w zaledwie sześćdziesiąt sekund musisz zarejestrować kopię polecenia% TEMP% \\ svchost.exe% systemroot% \\ system32 / y w konsoli poleceń.

Jeśli użytkownik, na przykład, w trybie normalnym lub bezpiecznym ma dostęp do rejestru systemu, w edytorze (regedit) w gałęzi HKCC, należy znaleźć parametr CSConfigFlags i przypisać mu wartość zero.

Rozwiązywanie problemów 1726

Wreszcie, naprawienie błędu 1726 odbywa się również przez rejestr. Ale w tym przypadku w gałęzi HKLM musisz znaleźć katalog RpcSs, a po prawej stronie edytować wartość parametru Start.

Należy go zmienić z czterech, zwykle instalowanych domyślnie, na dwa, a następnie ponownie uruchomić system.

Posłowie

W rzeczywistości chodzi o wywoływanie zdalnych procedur. Procedury zdalne, zasady działania tego komponentu w wersji zaawansowanej można opisać bardzo długo, ale w prezentowanym materiale położono nacisk na ogólne zapoznanie się z serwisem oraz niektóre metody eliminacji błędów i awarii, które może powodować w systemie komputerowym. Zwykli użytkownicy będą musieli uzbroić się w cierpliwość i być bardzo ostrożnym, ponieważ jedno nieprawidłowe działanie w rejestrze może doprowadzić do całkowitej awarii systemu operacyjnego.

Należy pamiętać, że awarie tego typu w jakikolwiek inny sposób, takie jak programy optymalizujące i regulatory parametrów systemów operacyjnych Windows, nie są usuwane. Z całym pragnieniem nie jest zapewniona ani linia poleceń, ani ponadto interwencja w rejestrze na poziomie kluczy edycji w takich pakietach oprogramowania.

Zdalne wywołanie procedury (lub Zdalne wywołanie procedury) (z języka angielskiego Zdalne wywołanie procedury (RPC)) to klasa technologii, która umożliwia programom komputerowym wywoływanie funkcji lub procedur w innej przestrzeni adresowej (zwykle na komputerach zdalnych). Zazwyczaj implementacja technologii RPC obejmuje dwa komponenty: protokół sieciowy do wymiany klient-serwer oraz język do serializacji obiektów (lub struktur dla obiektowych RPC). Różne implementacje RPC mają bardzo różną architekturę i różnią się możliwościami: niektóre implementują architekturę SOA, inne CORBA lub DCOM. Na poziomie transportu RPC używają głównie protokołów TCP i UDP, jednak niektóre są zbudowane na podstawie HTTP (co narusza architekturę ISO / OSI, ponieważ HTTP początkowo nie jest protokołem transportowym).

Realizacje

Istnieje wiele technologii zapewniających RPC:

Sun RPC (protokół binarny oparty na TCP oraz UDP i XDR) RFC-1831 druga nazwa ONC RPC RFC-1833
.Net Remoting (protokół binarny oparty na TCP, UDP, HTTP)
SOAP - Simple Object Access Protocol (protokół tekstowy oparty na HTTP) patrz karta katalogowa: RFC-4227
XML RPC (HTTP Based Text Protocol) patrz karta katalogowa: RFC-3529
Java RMI - Java Remote Method Invocation - patrz specyfikacja: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
JSON-RPC JavaScript Object Notation Zdalne wywołania procedur (protokół tekstowy oparty na HTTP) patrz karta katalogowa: RFC-4627
DCE / RPC - rozproszone środowisko komputerowe / zdalne wywołania procedur (protokół binarny oparty na różnych protokołach transportowych, w tym TCP / IP i potokach nazwanych z protokołu SMB / CIFS)
DCOM - Distributed Object Component Model znany jako MSRPC Microsoft Remote Procedura Call lub „Network OLE” (zorientowane obiektowo rozszerzenie DCE RPC, które umożliwia przesyłanie referencji do obiektów i metod wywoływania obiektów za pomocą takich łączy)

Zasada

Ideą zdalnego wywoływania procedur (RPC) jest rozszerzenie znanego i zrozumiałego mechanizmu przekazywania kontroli i danych w programie uruchomionym na jednym komputerze na transfer kontroli i danych przez sieć. Narzędzia do zdalnego wywoływania procedur zostały zaprojektowane w celu ułatwienia organizacji przetwarzania rozproszonego i tworzenia rozproszonych systemów informatycznych klient-serwer. Największą efektywność korzystania z RPC osiąga się w tych aplikacjach, w których istnieje interaktywne połączenie między zdalnymi komponentami o krótkim czasie odpowiedzi i stosunkowo małej ilości przesyłanych danych. Takie aplikacje nazywane są RPC.

Wdrażanie zdalnych wywołań jest znacznie bardziej skomplikowane niż wdrażanie lokalnych wywołań procedur. Możesz zidentyfikować następujące problemy i zadania, które należy rozwiązać podczas wdrażania RPC:

Ponieważ wywoływane i wywoływane procedury są wykonywane na różnych komputerach, mają one różne przestrzenie adresowe, co stwarza problemy przy przekazywaniu parametrów i wyników, szczególnie jeśli komputery działają w różnych systemach operacyjnych lub mają inną architekturę (na przykład przy użyciu bezpośredniego lub odwrotnego sortowania bajtów ) Ponieważ RPC nie może liczyć na pamięć współdzieloną, oznacza to, że parametry RPC nie powinny zawierać wskaźników do komórek pamięci bez stosu, a wartości parametrów powinny być kopiowane z jednego komputera na drugi. Aby skopiować parametry procedury i wynik wykonania przez sieć, są one serializowane.
W przeciwieństwie do wywołania lokalnego zdalne wywołanie procedury musi koniecznie wykorzystywać warstwę transportową architektury sieci (na przykład TCP), jednak pozostaje to ukryte przed deweloperem.
Wykonanie programu wywołującego i wywoływanej procedury lokalnej na jednym komputerze jest realizowane jako część jednego procesu. Ale w implementację RPC zaangażowane są co najmniej dwa procesy - po jednym na każdej maszynie. W przypadku awarii jednego z nich mogą wystąpić następujące sytuacje: w przypadku wypadku procedury wywoływania procedury wywoływane zdalnie zostaną „osierocone”, a jeśli procedury zdalne zakończą się niepowodzeniem, procedury wywoławcze zostaną „pozbawione rodziców”, co na próżno będzie czekać na odpowiedź z procedur zdalnych.
Istnieje wiele problemów związanych z heterogenicznością języków programowania i środowisk operacyjnych: struktury danych i struktury wywołań procedur obsługiwane w jednym języku programowania nie są obsługiwane w ten sam sposób we wszystkich innych językach. Tak więc istnieje problem kompatybilności, który nie został jeszcze rozwiązany ani przez wprowadzenie jednego ogólnie przyjętego standardu, ani przez wdrożenie kilku konkurencyjnych standardów we wszystkich architekturach i we wszystkich językach.

Podsystemy

Podsystem transportowy

Zarządzaj połączeniami wychodzącymi i przychodzącymi. - Wsparcie dla pojęcia „granicy wiadomości” dla protokołów transportowych, które go bezpośrednio nie obsługują (TCP). - Wsparcie dla gwarantowanej dostawy dla protokołów transportowych, które nie obsługują go bezpośrednio (UDP).

Pula wątków (nazywana tylko stroną). Zapewnia kontekst wykonania dla kodu wywoływanego przez sieć.

Marshaling (zwany także „serializacją”). Pakowanie parametrów wywołania do strumienia bajtów w standardowy sposób, niezależnie od architektury (w szczególności kolejność bajtów w słowie). W szczególności tablice, łańcuchy i struktury wskazywane przez parametry wskaźnika mogą być na nią narażone.

Szyfrowanie paczek i podpis cyfrowy na nich.

Uwierzytelnianie i autoryzacja. Transmisja sieciowa informacji identyfikujących podmiot wykonujący połączenie.

W niektórych implementacjach RPC (.NET Remoting) granicami podsystemów są otwarte interfejsy polimorficzne i możliwe jest napisanie własnej implementacji prawie wszystkich wymienionych podsystemów. W innych implementacjach (DCE RPC w systemie Windows) tak nie jest.

Zobacz także

Zdalne wywołanie procedury (RPC) Koncepcja zdalnego wywołania procedury

Ideą zdalnego wywoływania procedur (RPC) jest rozszerzenie znanego i zrozumiałego mechanizmu przekazywania kontroli i danych w programie uruchomionym na jednym komputerze na transfer kontroli i danych przez sieć. Narzędzia do zdalnego wywoływania procedur zostały zaprojektowane w celu ułatwienia organizacji przetwarzania rozproszonego. Największą efektywność korzystania z RPC osiąga się w tych aplikacjach, w których istnieje interaktywne połączenie między zdalnymi komponentami o krótkim czasie odpowiedzi i stosunkowo niewielkiej ilości przesyłanych danych. Takie aplikacje nazywane są RPC.

Cechami charakterystycznymi wywoływania lokalnych procedur są:

Asymetria, to znaczy jedna z interakcyjnych stron jest inicjatorem;
Synchronizm, to znaczy wykonanie procedury wywołującej, zostaje zawieszone od momentu wydania żądania i wznawiane dopiero po powrocie z wywoływanej procedury.

Wdrażanie zdalnych wywołań jest znacznie bardziej skomplikowane niż wdrażanie lokalnych wywołań procedur. Na początek, ponieważ procedury wywołujące i wywoływane są wykonywane na różnych komputerach, mają one różne przestrzenie adresowe, co stwarza problemy przy przekazywaniu parametrów i wyników, zwłaszcza jeśli maszyny nie są identyczne. Ponieważ RPC nie może liczyć na pamięć współdzieloną, oznacza to, że parametry RPC nie powinny zawierać wskaźników do komórek pamięci bez stosu, a wartości parametrów powinny być kopiowane z jednego komputera na drugi. Kolejna różnica między RPC a połączeniem lokalnym polega na tym, że koniecznie wykorzystuje on podstawowy system komunikacyjny, ale nie powinno to być wyraźnie widoczne ani w definicji procedur, ani w samych procedurach. Oddalenie wprowadza dodatkowe problemy. Wykonanie programu wywołującego i wywoływanej procedury lokalnej na jednym komputerze jest realizowane jako część jednego procesu. Ale w implementację RPC zaangażowane są co najmniej dwa procesy - po jednym na każdej maszynie. Jeśli jedna z nich ulegnie awarii, mogą wystąpić następujące sytuacje: w przypadku przypadkowej procedury wywoływania procedury wywoływane zdalnie zostaną „osierocone”, a jeśli procedury zdalne zakończą się niepowodzeniem, procedury wywołań zostaną „pozbawione rodziców”, co na próżno będzie czekać na odpowiedź z procedur zdalnych.

Rozpowszechniona technologia RPC, która leży u podstaw wielu rozproszonych systemów operacyjnych, rozwiązuje te i niektóre inne problemy. Podstawowe operacje RPC

Aby zrozumieć działanie RPC, najpierw rozważamy wykonanie lokalnego wywołania procedury na zwykłej maszynie, która działa autonomicznie. Niech to będzie na przykład wywołanie systemowe

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

gdzie fd jest liczbą całkowitą, buf jest tablicą znaków, nbytes jest liczbą całkowitą.

Aby wykonać wywołanie, procedura wywoływania wypycha parametry na stos w odwrotnej kolejności (rysunek 3.1). Po zakończeniu wywołania odczytu umieszcza wartość zwracaną w rejestrze, przenosi adres zwrotny i zwraca kontrolę do procedury wywoływania, która wybiera parametry ze stosu, przywracając go do pierwotnego stanu. Zauważ, że w C parametry mogą być wywoływane albo przez odwołanie (według nazwy) albo przez wartość (według wartości). W odniesieniu do wywoływanej procedury wartości parametrów są zmiennymi lokalnymi inicjalizowanymi. Wywołana procedura może je zmienić, a to nie wpłynie na wartość oryginałów tych zmiennych w procedurze wywołującej.

Zastosowanie

Znaczna część narzędzi do zdalnego sterowania systemem operacyjnym Windows (Podgląd zdarzeń, Menedżer serwera, zarządzanie drukowaniem, listy użytkowników) wykorzystuje DCE RPC jako środek komunikacji sieciowej między usługą zarządzaną a aplikacją do zarządzania interfejsem użytkownika. Obsługa DCE RPC jest obecna w systemie Windows NT od pierwszej wersji 3.1. Klienci DCE RPC byli również obsługiwani w lekkiej linii systemów operacyjnych Windows 3.x / 95/98 / Me.

Biblioteki systemu Windows, które zapewniają takie możliwości zarządzania i służą jako podstawowy poziom dla zarządzanych aplikacji interfejsu użytkownika (netapi32.dll i częściowo advapi32.dll), faktycznie zawierają kod klienta dla interfejsów DCE RPC, które zapewniają tę kontrolę.

Ta decyzja architektoniczna była przedmiotem ostrej krytyki Microsoftu. Uniwersalne procedury zestawiania dostępne w DCE RPC są bardzo złożone i mają ogromny potencjał wykorzystania defektów w sieci poprzez wysłanie celowo zniekształconego pakietu DCE RPC. Znaczącą część wad bezpieczeństwa systemu Windows odkrytych od późnych lat 90. do połowy 2000 r. Stanowiły błędy w kodzie rozkazu DCE RPC.

Oprócz DCE RPC, Windows aktywnie wykorzystuje technologię DCOM. Na przykład jest używany jako środek komunikacji między narzędziami do zarządzania serwerem sieci Web IIS a samym serwerem zarządzanym. W pełni funkcjonalny interfejs do komunikacji z systemem pocztowym MS Exchange Server - MAPI - również oparty jest na DCOM.

Programy komunikujące się przez sieć wymagają mechanizmu komunikacji. Na niższym poziomie, po odebraniu pakietów, sygnał jest przetwarzany przez program do przetwarzania sygnałów sieciowych. Na wyższym poziomie działa mechanizm spotkania (przyjętego w języku Ady). NFS używa mechanizmu zdalnego wywoływania procedur (RPC), w którym klient wchodzi w interakcję z serwerem (patrz rysunek 1). Zgodnie z tym procesem klient najpierw uzyskuje dostęp do procedury, która wysyła żądanie do serwera. Po przybyciu pakietu z żądaniem serwer wywołuje procedurę otwierania go, wykonuje żądaną usługę, wysyła odpowiedź i kontrola jest zwracana do klienta.

Interfejs RPC można przedstawić jako składający się z trzech poziomów:

Górny poziom jest całkowicie przezroczysty. Program tego poziomu może na przykład zawierać wywołanie procedury rnusers (), która zwraca liczbę użytkowników na zdalnym komputerze. Nie musisz wiedzieć o korzystaniu z mechanizmu RPC, ponieważ wykonujesz wywołanie w programie.
Środkowa warstwa przeznaczona jest do najczęściej używanych aplikacji. Wywołania RPC na tym poziomie są obsługiwane przez procedury registererrpc () i callrpc (): registererrpc () otrzymuje kod systemowy, a callrpc () wykonuje zdalne wywołanie procedury. Wywołanie rnusers () jest realizowane za pomocą tych dwóch procedur.
Niższy poziom służy do bardziej złożonych zadań, które zmieniają wartości domyślne na wartości parametrów procedury. Na tym poziomie możesz jawnie manipulować gniazdami używanymi do przesyłania komunikatów RPC.

Z reguły powinieneś używać wyższego poziomu i unikać korzystania z niższych poziomów bez specjalnej potrzeby.

Pomimo tego, że w tym przewodniku rozważamy interfejs tylko w C, dostęp do procedur zdalnych można uzyskać z dowolnego języka. Działanie mechanizmu RPC do organizowania interakcji między procesami na różnych komputerach nie różni się od pracy na jednym komputerze.

RPC (Remote Procedura Call) to interfejs między zdalnymi użytkownikami a niektórymi programami hosta, które działają na żądanie tych użytkowników. Usługa RPC hosta z reguły zapewnia klientom szereg programów. Każdy z tych programów z kolei składa się z jednej lub więcej zdalnych procedur. Na przykład usługa zdalnego systemu plików NFS zbudowana na wywołaniach RPC może składać się tylko z dwóch programów: na przykład jeden program współpracuje z interfejsami użytkownika wysokiego poziomu, a drugi z funkcjami We / Wy niskiego poziomu.

W każde wywołanie procedury zdalnej uczestniczą dwie strony: aktywny klient, który wysyła żądanie do wywołania procedury do serwera oraz serwer, który wysyła odpowiedź do klienta.

Uwaga Należy pamiętać, że terminy „klient” i „serwer” w tym przypadku odnoszą się do konkretnej transakcji. Określony host lub oprogramowanie (proces lub program) może działać zarówno jako klient, jak i serwer. Na przykład program, który zapewnia działanie zdalnej usługi procedury, może jednocześnie być klientem pracującym z sieciowym systemem plików.

Protokół RPC jest oparty na modelu zdalnego wywoływania procedur, podobnym do mechanizmu lokalnego wywoływania procedur. Kiedy wywołujesz procedurę lokalną, umieszczasz argumenty w określonym miejscu pamięci, na stosie lub zmiennych środowiskowych i przekazujesz kontrolę nad procesem pod określony adres. Po zakończeniu pracy czytaj wyniki pod określonym adresem i kontynuuj proces.

W przypadku pracy ze zdalną procedurą główną różnicą jest to, że dwa procesy obsługują wywołanie funkcji zdalnej: proces klienta i proces serwera.

Proces klienta wysyła komunikat do serwera, który zawiera parametry wywoływanej procedury i oczekuje komunikatu odpowiedzi z wynikami jego działania. Po otrzymaniu odpowiedzi wynik jest odczytywany, a proces jest kontynuowany. Po stronie serwera proces obsługi połączeń znajduje się w stanie oczekiwania, a gdy nadejdzie komunikat, odczytuje parametry procedury, wykonuje go, wysyła odpowiedź i staje się stanem oczekiwania następnego połączenia.

Protokół RPC nie nakłada żadnych wymagań na dodatkową komunikację między procesami i nie wymaga synchronizacji wykonywanych funkcji, tj. Wywołania mogą być asynchroniczne i niezależne, dzięki czemu klient może wykonywać inne procedury podczas oczekiwania na odpowiedź. Serwer RPC może przydzielić osobny proces lub maszynę wirtualną dla każdej funkcji, dlatego bez oczekiwania na zakończenie wcześniejszych żądań może natychmiast zaakceptować następujące.

Istnieje jednak kilka ważnych różnic między połączeniami z procedurami lokalnymi i zdalnymi:

Obsługa błędów. W każdym przypadku klient powinien zostać powiadomiony o błędach, które występują podczas wywoływania procedur zdalnych na serwerze lub w sieci.
Zmienne globalne Ponieważ serwer nie ma dostępu do przestrzeni adresowej klienta, podczas wywoływania procedur zdalnych nie można używać ukrytych parametrów w postaci zmiennych globalnych.
Wydajność Szybkość wykonywania procedur zdalnych jest zwykle o jeden lub dwa rzędy wielkości mniejsza niż prędkość wykonywania podobnych procedur lokalnych.
Uwierzytelnianie Ponieważ zdalne wywołania procedur odbywają się przez sieć, należy użyć mechanizmów uwierzytelniania klienta.

Zasady konstrukcji protokołu.

Protokół RPC może wykorzystywać kilka różnych protokołów transportowych. Do obowiązków protokołu RPC należy jedynie zapewnienie standardów i interpretacja komunikatów. Niezawodność i niezawodność transmisji wiadomości w całości zapewnia warstwa transportowa.

RPC może jednak kontrolować wybór i niektóre funkcje protokołu transportowego. Jako przykład interakcji między RPC a protokołem transportowym, rozważ procedurę przypisywania portu RPC procesu aplikacji przez RPC - Portmapper.

Ta funkcja dynamicznie (na żądanie) przypisuje określony port do połączenia RPC. Funkcja Portmapper jest używana dość często, ponieważ zestaw portów transportowych zarezerwowanych dla RPC jest ograniczony, a liczba procesów, które mogą potencjalnie działać jednocześnie, jest bardzo wysoka. Na przykład Portmapper jest wywoływany, gdy zostaną wybrane porty interakcji między klientem a serwerem systemu NFS.

Usługa Portmapper używa mechanizmu rozgłoszeniowego RPC do określonego portu - III. Na tym porcie klient wysyła komunikat emisji żądania portu dla określonej usługi RPC. Usługa Portmapper przetwarza komunikat podatkowy, określa adres lokalnej usługi RPC i wysyła odpowiedź do klienta. Usługa RPC Portmapper może współpracować zarówno z protokołami TCP, jak i UDP.

RPC może współpracować z różnymi protokołami transportowymi, ale nigdy nie powiela ich funkcji, to znaczy, jeśli RPC działa na TCP, cała niezawodność i niezawodność połączenia RPC spoczywa na TCP. Jeśli jednak protokół RPC jest zainstalowany na UDP, może on zapewniać dodatkowe funkcje natywne w celu zagwarantowania dostarczenia wiadomości.

Uwaga

Zadania aplikacji mogą traktować protokół RPC jako specyficzną procedurę wywoływania funkcji w sieci JSR (instrukcja podprogramu skoku).

Aby protokół RPC działał, muszą być spełnione następujące warunki:

Unikalna identyfikacja wszystkich procedur wywoływanych zdalnie na tym hoście. Żądania RPC zawierają trzy pola identyfikatora - numer zdalnego programu (usługi), numer wersji zdalnego programu oraz numer zdalnej procedury określonego programu. Numer programu jest przypisywany przez producenta usługi, numer procedury wskazuje konkretną funkcję usługi
Identyfikacja wersji protokołu RPC. Wiadomości RPC zawierają pole wersji protokołu RPC. Służy do koordynowania formatów przesyłanych parametrów, gdy klient pracuje z różnymi wersjami RPC.
Zapewnienie mechanizmów uwierzytelniania klienta na serwerze. Protokół RPC zapewnia procedurę uwierzytelniania klienta w usłudze oraz, w razie potrzeby, za każdym razem, gdy wysyłane jest żądanie lub odpowiedź jest wysyłana do klienta. Ponadto RPC umożliwia korzystanie z różnych dodatkowych mechanizmów bezpieczeństwa.

RPC może korzystać z czterech rodzajów mechanizmów uwierzytelniania:

AUTH_NULL - bez użycia uwierzytelnienia
AUTH_UNIX - Uwierzytelnianie UNIX
AUTH_SHORT - Uwierzytelnianie UNIX z własną strukturą kodowania
AUTH_DES - uwierzytelnianie DES

Identyfikacja komunikatów odpowiedzi na odpowiednie żądania. Komunikaty odpowiedzi RPC zawierają identyfikator żądania, na podstawie którego zostały zbudowane. Ten identyfikator można nazwać identyfikatorem transakcji wywołania RPC. Ten mechanizm jest szczególnie potrzebny podczas pracy w trybie asynchronicznym i podczas wykonywania sekwencji kilku wywołań RPC.
Identyfikacja błędów działania protokołu. Wszystkie błędy sieci lub serwera mają unikalne identyfikatory, dzięki którym każdy uczestnik połączenia może określić przyczynę niepowodzenia.

Struktury komunikatów protokołu

Podczas przesyłania komunikatów RPC za pośrednictwem protokołu transportowego kilka komunikatów RPC może znajdować się w tym samym pakiecie transportowym. Aby oddzielić jedną wiadomość od drugiej, używany jest znacznik zapisu (RM - marker znacznika). Każda wiadomość RPC jest „otagowana” dokładnie jednym RM.

Komunikat RPC może składać się z kilku fragmentów. Każdy fragment składa się z czterech bajtów nagłówka i (od 0 do 2 ** 31-1) danych. Pierwszy bit nagłówka wskazuje, czy ten fragment jest ostatnim, a pozostałe 31 bitów wskazuje długość pakietu danych.

Struktura RPC jest formalnie opisana w języku opisu i prezentacji formatów danych - XDR z dodatkami związanymi z opisem procedur. Można nawet powiedzieć, że język opisu RPC jest rozszerzeniem XDR, uzupełnionym pracą z procedurami.

Struktura pakietu RPC jest następująca:

Struktura odpowiedzi (body_odpowiedzi) może zawierać strukturę przesyłaną w przypadku błędu (wtedy zawiera kod błędu) lub strukturę pomyślnego przetwarzania żądania (wtedy zawiera zwrócone dane).

Interfejs oprogramowania wysokiego poziomu.

Używanie procedur w programie to tradycyjny sposób na uporządkowanie zadania i uczynienie go bardziej zrozumiałym. Najczęściej używane procedury są gromadzone w bibliotekach, gdzie mogą być używane przez różne programy. W tym przypadku mówimy o wywołaniu lokalnym (lokalnym), to znaczy zarówno wywołujący, jak i wywoływany obiekt działają w tym samym programie na jednym komputerze.

W przypadku wywołania zdalnego proces działający na jednym komputerze uruchamia proces na komputerze zdalnym (tzn. Faktycznie uruchamia kod procedury na komputerze zdalnym). Oczywiście zdalne wywołanie procedury znacznie różni się od tradycyjnego lokalnego, jednak z punktu widzenia programisty takie różnice są praktycznie nieobecne, tj. Architektura zdalnego wywołania procedury pozwala na symulację wywołania lokalnego.

Jeśli jednak w przypadku wywołania lokalnego program przesyła parametry do wywoływanej procedury i odbiera wynik pracy przez obszar stosu lub obszarów pamięci współużytkowanej, wówczas w przypadku wywołania zdalnego transmisja parametrów staje się transmisją żądania przez sieć, a wynikiem jest otrzymana odpowiedź.

Takie podejście jest możliwą podstawą do tworzenia aplikacji rozproszonych i chociaż wiele nowoczesnych systemów nie korzysta z tego mechanizmu, podstawowe pojęcia i terminy są w wielu przypadkach zachowane. Opisując mechanizm RPC, tradycyjnie nazywamy proces wywoływania klientem, a proces zdalny realizujący procedurę serwer.

Zdalne wywołanie procedury obejmuje następujące kroki:

Program kliencki wykonuje lokalne wywołanie procedury zwanej kodem pośredniczącym. Jednocześnie klientowi wydaje się, że wywołując kod pośredniczący, wykonuje rzeczywiste wywołanie procedury-serwera. Rzeczywiście, klient przekazuje niezbędne parametry do kodu pośredniczącego i zwraca wynik. Nie jest to jednak tak, jak sobie wyobraża klient. Zadaniem kodu pośredniczącego jest zaakceptowanie argumentów przeznaczonych do zdalnej procedury, być może konwersja do standardowego formatu i utworzenie żądania sieciowego. Pakowanie argumentów i tworzenie żądania sieciowego nazywa się marshalling.
Żądanie sieciowe jest przesyłane przez sieć do zdalnego systemu. Aby to zrobić, kod pośredniczący używa odpowiednich wywołań, na przykład tych omówionych w poprzednich sekcjach. Należy pamiętać, że w takim przypadku można użyć różnych protokołów transportowych, a nie tylko rodziny TCP / IP.
Na zdalnym hoście wszystko dzieje się w odwrotnej kolejności. Kod pośredniczący serwera czeka na żądanie i po otrzymaniu pobiera parametry - argumenty do wywołania procedury. Wyrejestrowanie może obejmować niezbędne konwersje (na przykład zmianę kolejności bajtów).
Kod pośredniczący wywołuje procedurę prawdziwego serwera, do której kierowane jest żądanie klienta, przekazując mu argumenty otrzymane przez sieć.
Po zakończeniu procedury sterowanie powraca do kodu pośredniczącego serwera, przekazując mu wymagane parametry. Jak odcinek klienta; skrót serwera konwertuje wartości zwrócone przez procedurę, tworząc komunikat odpowiedzi sieci, który jest przesyłany przez sieć do systemu, z którego nadeszło żądanie.
System operacyjny przekazuje otrzymaną wiadomość do kodu pośredniczącego klienta, który po niezbędnej konwersji przekazuje wartości (które są wartościami zwracanymi przez procedurę zdalną) do klienta, który postrzega to jako normalny powrót z procedury.

Dlatego z punktu widzenia klienta wykonuje on zdalną procedurę, tak jak w przypadku procedury lokalnej. To samo można powiedzieć o serwerze: wywołanie procedury występuje w standardowy sposób, pewien obiekt (skrót serwera) wywołuje procedurę lokalną i odbiera zwracane przez nią wartości. Klient postrzega kod pośredniczący jako tak zwany serwer procedur, a serwer pobiera swój kod pośredniczący dla klienta.

W ten sposób kody pośredniczące stanowią rdzeń systemu RPC, odpowiedzialny za wszystkie aspekty tworzenia i przesyłania wiadomości między klientem a serwerem zdalnym (procedura), chociaż zarówno klient, jak i serwer uważają, że połączenia są wykonywane lokalnie. To właśnie podstawowa koncepcja RPC polega na całkowitym ukryciu rozproszonego (sieciowego) charakteru interakcji w kodzie pośredniczącym. Zalety tego podejścia są oczywiste: zarówno klient, jak i serwer są niezależne od implementacji sieci, oba działają na określonej rozproszonej maszynie wirtualnej, a wywołania procedur mają standardowy interfejs.

Przekazywanie parametrów

Przekazywanie wartości parametrów nie sprawia większych trudności. W takim przypadku kod klienta umieszcza wartość parametru w żądaniu sieci, prawdopodobnie wykonując konwersje do standardowego formularza (na przykład zmieniając kolejność bajtów). Znacznie bardziej skomplikowana jest sytuacja z przekazywaniem wskaźników, gdy parametrem jest adres danych, a nie jego wartość. Przekazywanie adresu w żądaniu jest bez znaczenia, ponieważ zdalna procedura jest wykonywana w zupełnie innej przestrzeni adresowej. Najprostszym rozwiązaniem stosowanym w RPC jest zabronienie klientom przekazywania parametrów w jakikolwiek inny sposób niż pod względem wartości, chociaż oczywiście nakłada to poważne ograniczenia.

Wiązanie

Zanim klient będzie mógł wywołać zdalną procedurę, musi być powiązany ze zdalnym systemem, który ma wymagany serwer. Tak więc problem wiązania dzieli się na dwa:

Znajdowanie zdalnego hosta z żądanym serwerem
Znalezienie wymaganego procesu serwera na tym hoście

Aby znaleźć hosta, można zastosować różne podejścia. Możliwą opcją jest utworzenie scentralizowanego katalogu, w którym hosty ogłaszają swoje serwery, i gdzie klient może wybrać odpowiedni host i adres dla procedury.

Każda procedura RPC jest jednoznacznie określona przez numer programu i procedury. Numer programu określa grupę zdalnych procedur, z których każda ma swój własny numer. Do każdego programu przypisany jest także numer wersji, więc kiedy wprowadzasz drobne zmiany w programie (na przykład podczas dodawania procedury), nie ma potrzeby zmiany jego numeru. Zwykle kilka funkcjonalnie podobnych procedur jest wdrażanych w jednym module oprogramowania, który przy uruchomieniu staje się serwerem tych procedur i jest identyfikowany przez numer programu.

Tak więc, gdy klient chce wywołać zdalną procedurę, musi znać numery programów, wersje i procedury zapewniające wymaganą usługę.

Aby wysłać żądanie do klienta, konieczna jest również znajomość adresu sieciowego hosta i numeru portu skojarzonego z programem serwera, który zapewnia wymagane procedury. W tym celu wykorzystywany jest demon portmap (IM) (w niektórych systemach nazywa się rpcbind (IM)). Demon działa na hoście, który zapewnia zdalne usługi procedur i używa dobrze znanego numeru portu. Po zainicjowaniu procesu serwerowego rejestruje swoje procedury i numery portów w portmap (IM). Teraz, gdy klient musi znać numer portu do wywołania określonej procedury, wysyła żądanie do serwera portmap (IM), który z kolei albo zwraca numer portu, albo przekierowuje żądanie bezpośrednio do zdalnego serwera procedur, a po jego wykonaniu zwraca odpowiedź do klienta. W każdym razie, jeśli istnieje wymagana procedura, klient otrzymuje numer portu procedury z serwera portmap (IM) i może wysyłać dalsze żądania bezpośrednio do tego portu.

Obsługa wyjątków

Postępowanie w szczególnych sytuacjach podczas wywoływania lokalnych procedur nie stanowi szczególnego problemu. UNIX zapewnia obsługę błędów w procesach takich jak dzielenie przez zero, dostęp do niepoprawnego obszaru pamięci itp. W przypadku wywołania procedury zdalnej zwiększa się prawdopodobieństwo wystąpienia błędów. Błędy związane na przykład z otrzymywaniem komunikatu o błędzie sieci są dodawane do błędów serwera i kodów pośredniczących.

Na przykład, gdy używasz UDP jako protokołu transportowego, wiadomości są ponownie przesyłane po pewnym czasie. Klient jest zwracany błąd, jeśli po określonej liczbie prób nigdy nie otrzymano odpowiedzi z serwera. W przypadku użycia protokołu TCP do klienta zwracany jest błąd, jeśli serwer rozłączył połączenie TCP.

Wywołaj semantykę

Wywołanie lokalnej procedury jednoznacznie prowadzi do jej wykonania, po czym kontrola powraca do programu hosta. Sytuacja wygląda inaczej w przypadku wywoływania procedury zdalnej. Nie można ustalić, kiedy procedura zostanie konkretnie wykonana, czy w ogóle zostanie wykonana, a jeśli tak, to ile razy? Na przykład, jeśli zdalny system otrzyma żądanie po awarii programu serwera, procedura w ogóle nie zostanie wykonana. Jeśli klient, po nieotrzymaniu odpowiedzi po upływie określonego czasu (przekroczenie limitu czasu), wielokrotnie wysyła żądanie, może wystąpić sytuacja, gdy odpowiedź zostanie już przesłana przez sieć, a powtarzane żądanie zostanie ponownie zaakceptowane do przetworzenia przez procedurę zdalną. W takim przypadku procedura zostanie wykonana kilka razy.

W ten sposób wykonanie zdalnej procedury można scharakteryzować następującą semantyką:

Raz i tylko raz. To zachowanie (w niektórych przypadkach najbardziej pożądane) jest trudne do spełnienia z powodu możliwych awarii serwera.
W większości przypadków Oznacza to, że procedura albo wcale nie została wykonana, albo została wykonana tylko raz. Podobne oświadczenie można sformułować, gdy otrzymany zostanie błąd zamiast normalnej odpowiedzi.
Przynajmniej raz Procedura została prawdopodobnie wykonana raz, ale prawdopodobnie więcej. Do normalnego działania w takiej sytuacji procedura zdalna musi mieć właściwość idempotency (z angielskiego idemponent). Ta właściwość ma procedurę, której powtórne wykonanie nie powoduje skumulowanych zmian. Na przykład czytanie pliku jest idempotentne, ale dodawanie tekstu do pliku nie jest.

Prezentacja danych

Gdy klient i serwer działają w tym samym systemie na tym samym komputerze, nie występują problemy z niezgodnością danych. Zarówno dla klienta, jak i serwera dane binarne są prezentowane identycznie. W przypadku zdalnego wywołania sprawę komplikuje fakt, że klient i serwer mogą działać w systemach o różnych architekturach, które mają różne reprezentacje danych (na przykład reprezentacja wartości zmiennoprzecinkowych, kolejności bajtów itp.)

Większość implementacji systemu RPC definiuje niektóre standardowe typy reprezentacji danych, na które muszą być konwertowane wszystkie wartości przesyłane w żądaniach i odpowiedziach.

Na przykład format prezentacji danych Sun Microsystems RPC jest następujący:

Kolejność bajtów - Senior - Last
Reprezentacja zmiennoprzecinkowa - IEEE
Reprezentacja znaków - ASCII

Sieć

Dzięki swojej funkcjonalności system RPC zajmuje pośrednie miejsce między warstwą aplikacyjną a warstwą transportową. Zgodnie z modelem OSI poziomy prezentacji i sesji odpowiadają tej pozycji. Zatem RPC jest teoretycznie niezależny od implementacji sieci, w szczególności protokołów sieciowych warstwy transportowej.

Implementacje oprogramowania systemu z reguły obsługują jeden lub dwa protokoły. Na przykład system RPC firmy Sun Microsystems obsługuje przesyłanie wiadomości przy użyciu protokołów TCP i UDP. Wybór protokołu zależy od wymagań aplikacji. Wybór UDP jest uzasadniony dla aplikacji o następujących cechach:

Wywoływane procedury są idempotentne
Rozmiar przekazywanych argumentów i zwracany wynik jest mniejszy niż rozmiar pakietu UDP - 8 kilobajtów.
Serwer zapewnia pracę kilkuset klientom. Ponieważ podczas pracy z protokołami TCP serwer jest zmuszony do utrzymywania połączenia z każdym z aktywnych klientów, zajmuje to znaczną część jego zasobów. Pod tym względem UDP wymaga mniej zasobów.

Z drugiej strony TCP zapewnia wydajne działanie aplikacji o następujących cechach:

Aplikacja wymaga niezawodnego protokołu transmisji
Wywoływane procedury są niekomponentowe
Rozmiar argumentów lub return jest większy niż 8 KB

Wybór protokołu zazwyczaj należy do klienta, a system organizuje formowanie i przesyłanie wiadomości na różne sposoby. Tak więc, używając protokołu TCP, dla którego przesyłane dane są strumieniem bajtów, konieczne jest oddzielenie wiadomości od siebie. W tym celu stosuje się na przykład protokół oznaczania rekordów opisany w RFC1057 „RPC: Specyfikacja protokołu zdalnego postępowania w wersji 2”, w którym 32-bitowa liczba całkowita określająca rozmiar wiadomości w bajtach jest umieszczana na początku każdej wiadomości.

Sytuacja z semantyką wywołania jest inna. Na przykład, jeśli RPC jest wykonywane przy użyciu nierzetelnego protokołu transportowego (UDP), system retransmituje komunikat w krótkich odstępach czasu (przekroczenia limitu czasu). Jeśli aplikacja kliencka nie otrzyma odpowiedzi, możemy śmiało powiedzieć, że procedura została wykonana zero lub więcej razy. Jeśli otrzymano odpowiedź, wniosek może stwierdzić, że procedura została wykonana co najmniej raz. Korzystając z niezawodnego protokołu transportowego (TCP) w przypadku otrzymania odpowiedzi, możemy powiedzieć, że procedura została wykonana raz. Jeśli odpowiedź nie zostanie odebrana, zdecydowanie nie można powiedzieć, że procedura nie została zakończona3.

Jak to działa

Zasadniczo sam system RPC jest osadzony w programie klienta i programie serwera. Cieszy fakt, że opracowując aplikacje rozproszone, nie musisz zagłębiać się w szczegóły protokołu RPC ani przetwarzania komunikatów programu. System zakłada istnienie odpowiedniego środowiska programistycznego, które znacznie ułatwia życie twórcom oprogramowania aplikacyjnego. Jednym z kluczowych punktów w RPC jest to, że tworzenie aplikacji rozproszonej rozpoczyna się od zdefiniowania interfejsu obiektu - formalnego opisu funkcji serwera wykonanego w specjalnym języku. W oparciu o ten interfejs kody pośredniczące klienta i serwera są następnie tworzone automatycznie. Jedyne, co należy zrobić po tym, to napisanie właściwego kodu procedury.

Jako przykład rozważmy Sun Microsystems RPC. System składa się z trzech głównych części:

rpcgen (1) to kompilator RPC, który na podstawie opisu interfejsu procedury zdalnej generuje kody pośredniczące klienta i serwera w postaci programów typu C.
Biblioteka XDR (eXternal Data Representation), która zawiera funkcje do konwersji różnych typów danych do postaci niezależnej od maszyny, umożliwiając wymianę informacji między systemami heterogenicznymi.
Biblioteka modułów zapewniających działanie systemu jako całości.

Rozważ przykład prostej aplikacji do rozproszonego rejestrowania zdarzeń. Klient podczas uruchamiania wywołuje zdalną procedurę zapisywania wiadomości w pliku dziennika komputera zdalnego.

Aby to zrobić, musisz utworzyć co najmniej trzy pliki: specyfikację interfejsów zdalnych procedur log.x (w języku opisu interfejsu), rzeczywisty tekst zdalnych procedur log.c oraz tekst głównego programu klienta main () - client.c (w C).

Kompilator rpcgen (l) tworzy trzy pliki na podstawie specyfikacji log.x: kody pośredniczące klienta i serwera w C (log clnt.c i log svc.c) oraz plik opisowy log.h używany przez oba kody pośredniczące.

Rozważymy więc kody źródłowe programów.

Ten plik określa parametry rejestracji procedury zdalnej - numery programów, wersje i procedury, a także definiuje interfejs wywołania - argumenty wejściowe i zwracane wartości. W ten sposób zdefiniowana jest procedura RLOG, która przyjmuje ciąg znaków jako argument (który zostanie zapisany w dzienniku), a zwracana wartość standardowo wskazuje pomyślne lub nieudane wykonanie zamówionej operacji.

program LOG_PROG ( wersja LOG_VER ( int RLOG (ciąg) \u003d 1; ) \u003d 1; ) \u003d 0x31234567;

Kompilator rpcgen (l) tworzy plik nagłówka log.h, w którym zdefiniowane są w szczególności procedury:

Rozważ dokładnie ten plik. Kompilator tłumaczy nazwę RLOG zdefiniowaną w pliku opisu interfejsu na rlog_1, zastępując wielkie litery małymi literami i dodając numer wersji programu podkreśleniem. Typ zwracanej wartości zmienił się z int na int *. Jest to reguła - RPC pozwala wysyłać i odbierać tylko adresy zadeklarowane w opisie parametrów interfejsu. Ta sama reguła dotyczy łańcucha przekazanego jako argument. Chociaż nie wynika to z pliku print.h, adres linii jest również przekazywany jako argument funkcji rlog_l ().

Oprócz pliku nagłówkowego kompilator rpcgen (l) tworzy moduły pośredniczące klienta i pośredniczące serwera. Zasadniczo tekst tych plików zawiera cały kod zdalnego wywołania.

Kod pośredniczący serwera to program nadrzędny, który przetwarza wszystkie interakcje sieciowe z klientem (a dokładniej za pomocą kodu pośredniczącego). Aby wykonać operację, skrót serwera wykonuje lokalne wywołanie funkcji, którego tekst musi zostać napisany:

Kod klienta przyjmuje argument przekazany do zdalnej procedury, dokonuje niezbędnych konwersji, generuje żądanie do serwera portmap (1M), wymienia dane ze zdalnym serwerem procedur, a na koniec przekazuje wartość zwracaną do klienta. W przypadku klienta wywołanie procedury zdalnej sprowadza się do wywołania kodu pośredniczącego i nie różni się niczym od zwykłego połączenia lokalnego.

klient.c

#include #include „log.h” główny(int argc char * argv) (KLIENT * cl; char * serwer, * mystring, * clnttime; czas btime int * wynik; jeśli (argc! \u003d 2) (fprintf (stderr, "Format wywołania:% s adres_hosta \\ n", argv); exit (1);) server \u003d argv; / * Uzyskaj obsługę klienta. W przypadku awarii poinformujemy Cię o niemożności nawiązania komunikacji z serwerem * / jeśli ((c1 \u003d clnt_create (serwer, LOG_PROG, LOG_VER, „udp”)) \u003d\u003d NULL) (clnt_pcreateerror (serwer); exit (2);) / * Wybierz bufor dla łańcucha * / tajemnica \u003d ( char *) malloc (100); / * Określ godzinę zdarzenia * / bintime \u003d czas ((time_t *) NULL); clnttime \u003d ctime (& bintime); sprintf (mystring, „% s - Klient działa”, clnttime); / * Przekażmy komunikat do dziennika - czas rozpoczęcia pracy przez klienta. W przypadku awarii - zgłoś błąd * / jeśli ((wynik \u003d rlog_l (& mystring, cl)) \u003d\u003d Zero) (fprintf (stderr, "error2 \\ n"); clnt_perror (cl, server); exit (3);) / * W przypadku awarii na komputerze zdalnym zgłosimy błąd * / jeśli (* wynik! \u003d 0) fprintf (stderr, „Błąd rejestrowania \\ n”); / * 0 wolny uchwyt * / cint destroy (cl); wyjście (0); )

Kod klienta log_clnt.c jest kompilowany z modułem client.c w celu uzyskania pliku wykonywalnego klienta.

Teraz na hoście server.nowhere.ru musisz rozpocząć proces serwera:

$ logger

Następnie, gdy klient rlog uruchomi się na innym komputerze, serwer doda odpowiedni wpis do pliku dziennika.

Schemat działania RPC w tym przypadku pokazano na ryc. 1. Moduły współdziałają w następujący sposób:

Kiedy proces serwera się rozpoczyna, tworzy gniazdo UDP i kojarzy dowolny port lokalny z tym gniazdem. Następnie serwer wywołuje funkcję biblioteczną svc_register (3N) w celu zarejestrowania numerów programów i ich wersji. Aby to zrobić, funkcja wywołuje proces portmap (IM) i przekazuje wymagane wartości. Serwer portmap (IM) zwykle uruchamia się podczas inicjalizacji systemu i komunikuje się z jakimś dobrze znanym portem. Teraz portmap (3N) zna numer portu dla naszego programu i wersji. Serwer czeka na żądanie. Zauważ, że wszystkie opisane akcje są wykonywane przez odgałęzienie serwera utworzone przez kompilator rpcgen (IM).
Po uruchomieniu programu rlog najpierw wywołuje funkcję biblioteczną clnt_create (3N), wskazując adres systemu zdalnego, numery programu i wersji oraz protokół transportowy. Funkcja wysyła żądanie do serwera portmap (IM) systemu zdalnego server.nowhere.m i uzyskuje numer zdalnego portu dla serwera dziennika.
Klient wywołuje procedurę rlog_1 () zdefiniowaną w kodzie pośredniczącym klienta i przekazuje kontrolę do kodu pośredniczącego. To z kolei tworzy żądanie (konwersję argumentów do formatu XDR) w postaci pakietu UDP i wysyła je do zdalnego portu otrzymanego z serwera portmap (IM). Następnie czeka chwilę na odpowiedź i, jeśli nie otrzyma, ponownie wysyła żądanie. W sprzyjających okolicznościach żądanie jest akceptowane przez serwer rejestrujący (moduł pośredniczący serwera). Kod pośredniczący określa, która funkcja została wywołana (według numeru procedury) i wywołuje funkcję rlog_1 () modułu log.c. Po zwróceniu kontroli z powrotem do kodu pośredniczącego konwertuje wartość zwróconą przez funkcję rlog_1 () na format XDR i tworzy odpowiedź również w postaci pakietu UDP. Po otrzymaniu odpowiedzi kod klienta pobiera zwróconą wartość, konwertuje ją i zwraca do głównego programu klienta