Programowanie aplikacji klient - serwer

Zdalne wywoływanie procedur
(RPC)

Metody tworzenia aplikacji rozproszonych

• Dwa podejścia do projektowania aplikacji rozproszonych:

1. Projektowanie zorientowane na komunikację;

2. Projektowanie zorientowane na aplikacje.

• Projektowanie zorientowane na komunikację

1. Protokół komunikacyjny;

2. Format i składnia komunikatów;

3. Program klienta - reakcja na odbierane komunikaty i sposób tworzenia wysyłanych komunikatów;

4. Program serwera - reakcja na odbierane komunikaty i sposób tworzenia wysyłanych komunikatów;

Wady:

1. Skoncentrowanie uwagi na protokole komunikacyjnym, a sposób działania aplikacji schodzi na plan dalszy - potencjalne źródło błędów.

2. Protokoły mogą okazać się niepotrzebnie zawikłane i nieefektywne. Drobne przeoczenia mogą być przyczyną usterek ujawniających się dopiero przy dużym obciążeniu.

3. Kod realizujący komunikację stanowi centralną część każdego programu, co zmniejsza przejrzystość samej aplikacji.

• Projektowanie zorientowane na aplikację

1. Projekt aplikacji działającej na pojedynczej maszynie.

2. Implementacja i testowanie w środowisku lokalnym jego wersji roboczej.

3. Podział programu na części, które będą wykonywane na różnych maszynach;

4. Opracowanie protokołu komunikacyjnego.

• Model zdalnego wywoływania procedury - RPC

Model zdalnego wywoływania procedury - RPC (ang. Remote Procedure Call) nawiązuje do drugiego podejścia i powstał, aby:

• pomóc programistom zrozumieć interakcję klient-serwer ;

• ułatwić projektowanie aplikacji rozproszonych.

Klasyczny model wywołań procedur

• Program składa się z procedur zorganizowanych w hierarchię wywołań. Strzałka od procedury m do procedury n oznacza, że procedura n jest wywoływana z wnętrza procedury m.

main

proc₁ proc₂ proc₃ proc₄

proc₅ proc₆ proc₇ proc₈

Pojęciowy model wywołania procedur na przykładzie ścieżki:

main→ proc₄→ proc₈

• Nici sterowania pokazują przebieg wykonania procedur. Wykonanie procedury trwa aż do napotkania instrukcji powrotu.

Kod programu Kod Kod

głównego procedury 4 procedury 8

Początek

programu

głównego

Wywołanie 4

Wywołanie 8

Wyjście

z programu

głównego Powrót Powrót

Model proceduralny w systemach rozproszonych

W klasycznym modelu proceduralnym wszystkie procedury są umieszczone na jednym komputerze, w modelu RPC wywoływane procedury znajdują się na odległych komputerach. Aby program mógł korzystać ze zdalnych wywołań procedur zgodnie z modelem RPC, musi istnieć protokołu sieciowy realizujący komunikację z procedurą oddaloną. Protokół ten musi w szczególności zapewnić właściwe przekazanie parametrów do procedury oddalonej i zwrot wyników w niej wygenerowanych.

komputer 1 komputer 2

main

proc₁ proc₂ proc₃ proc₄

proc₅ proc₆ proc₇ proc₈

Przebieg nici sterowania wykonania w środowisku rozproszonym

Zamiast zajmować się wymianą komunikatów między klientem a serwerem, można potraktować serwer jako realizację pewnej procedury oddalonej. Interakcja między klientem a serwerem odpowiada wywołaniu procedury i zwróceniu wyników jej wykonania (powrotowi z procedury).

Program główny Procedura 4 Procedura 8

na komputerze 1 na komputerze 2 na komputerze 3

( klient ) ( serwer ) ( serwer )

Początek

programu

głównego

Wywołanie 4

Wywołanie odleg-

łej procedury 8

Wyjście Odpowiedź dla Odpowiedź dla

z programu procedury procedury

głównego wywołującej wywołującej

Wyobrażenie sobie aplikacji rozproszonej jako jednego programu, w którym sterowanie jest przekazywane przez sieć do procedury odległej i z powrotem, ułatwia programistom zdefiniowanie interakcji klient - serwer, ponieważ interakcje te są rozważane w kategoriach znanego pojęcia wywołania procedury i powrotu z niej.

Mechanizm zdalnego wywołania procedur

- Sun RPC

• Zdefiniowana przez firmę Sun Microsystems konkretna postać mechanizmu zdalnego wywołania procedur - Sun RPC - stała się standardem rozwiązania tego problemu. Została zastosowana w wielu aplikacjach - między innymi w systemie NFS - sieciowym systemie plików firmy Sun.

• Sun RPC określa:

1. format komunikatów wysyłanych przez program wywołujący (klienta)
   w celu wywołania odległej procedury realizowanej przez serwer;

2. format argumentów wywołania;

3. format wyników zwracanych przez wywołaną procedurę;

4. reprezentację argumentów i wyników, a także różnych elementów nagłówka komunikatów RPC - XDR;

5. protokół TCP lub UDP do przesyłania komunikatów;

Dla SUN RPC zdefiniowano system kompilacji umożliwiający automatyzację konstruowania programów rozproszonych.

Program odległy - (ang. remote program) - odpowiednik serwera. Zawiera jedną lub więcej procedur odległych oraz dane globalne, do których mają dostęp wszystkie procedury programu odległego.

• Agregacja argumentów wywołania procedury

• Sun RPC zakłada, że każdy program, który z niego korzysta zbiera wszystkie argumenty przekazywane odległej procedurze w jedną strukturę.

• Procedura wywołująca musi przypisać wartości każdemu polu struktury przed przekazaniem jej do procedury wywoływanej. Po powrocie do procedury wywołującej procedura ta wyodrębnia z tej samej struktury wartości wynikowe zwrócone przez procedurę wywoływaną.

Identyfikacja zdalnych programów i procedur

• Standard Sun RPC wymaga przypisania każdemu programowi pełniącemu rolę programu odległego, jednoznacznego, 32-bitowego identyfikatora zwanego numerem programu. Liczbę tę podaje program wywołujący, aby wskazać wywoływany program odległy.

• Z każdym programem związany jest ponadto numer wersji. Numery wersji są z kolejnymi liczbami całkowitymi począwszy od 1. Dzięki temu można przechowywać kilka wersji programu bez potrzeby przydziału nowego numeru programu.

• Każdej procedurze działającej w ramach programu odległego przydziela się liczbę całkowitą, która nazywana jest numerem procedury. Procedury są numerowane kolejno począwszy od 1. (Numer 0 jest zarezerwowany standardowo dla procedury realizującej echo, którą można wywołać, aby sprawdzić, czy dany program odległy jest dostępny.)

• Odwołanie do wskazanej procedury działającej w ramach danej wersji danego programu ma następującą postać:

(prog, wer, proc)

gdzie:

• prog - identyfikator programu odległego,

• wer - numer wersji tego programu,

• proc - identyfikator procedury w ramach danego programu.

Uwaga:

Mechanizm RPC nie pozwala na jednoczesne wywołanie więcej niż jednej procedury w ramach jednego zdalnie wykonywanego programu. Ma to na celu ochronę wspólnie wykorzystywanych przez różne procedury danych

. Identyfikacja zdalnych programów i procedur

• Aby zapobiec konfliktom numerów programów przydzielanych przez różne firmy i instytucje, firma Sun Microsystems wprowadziła podział całego zbioru numerów na 8 zakresów.

Od	Do	Numery przydzielane przez
0x00000000	0x1fffffff	Sun Microsystems, Inc.
0x20000000	0x3fffffff	Zarządca systemu w danym ośrodku
0x40000000	0x5fffffff	Numery przydzielane tymczasowo
0x60000000	0x7fffffff	Numery zarezerwowane
0x80000000	0x9fffffff	Numery zarezerwowane
0xa0000000	0xbfffffff	Numery zarezerwowane
0xc0000000	0xdfffffff	Numery zarezerwowane
0xe0000000	0xffffffff	Numery zarezerwowane

• Pierwszy zakres pozostaje w gestii firmy Sun Microsystems. Można wystąpić do niej o przydział standardowego numeru RPC z tego zakresu. Przedstawione przydziały używane są na wszystkich komputerach korzystających z Sun RPC.

• Przykłady:

100002 - rusers (użytkownicy odległego systemu);

100003 - nfs (sieciowy system plików);

100010 - etherstatd (ethernet statistics);

Semantyka wywołań

• W klasycznym modelu proceduralnym - pojedyncze wywołanie podprogramu spowoduje na pewno pojedyncze wykonanie podprogramu i otrzymanie dokładnie jednego wyniku lub efektu.

.

• W przypadku procedur wywoływanych zdalnie, zwłaszcza z użyciem protokołu UDP, takich gwarancji nie ma. Jeśli program korzysta
  z protokołu UDP, wywołanie procedury lub odpowiedź może zaginąć lub ulec powieleniu. Zatem z braku odpowiedzi oznaczającej powrót po wykonaniu procedury nie można wnioskować, że nie została ona wykonana. Podobnie z nadejścia pojedynczej odpowiedzi nie można wnosić, że została wykonana dokładnie raz.

• Standard RPC opisuje semantykę zdalnego wywołania procedury określeniem co najmniej raz w przypadku, gdy program wywołujący otrzyma odpowiedź, oraz określeniem zero lub więcej, jeśli odpowiedź nie nadejdzie.

• Zdalnie wywoływana procedura musi spełniać zatem warunek idempotencji; wielokrotne jej wykonanie daje taki sam efekt, jak jednorazowe.

Warunku idempotencji nie spełniają procedury:

• „dopisz rekord na końcu pliku”

• „usuń pierwszy rekord z pliku”

• „zmniejsz zawartość pola o 1”

Warunek idempotencji spełniają:

• „dopisz rekord na pozycji piątej”

• „usuń z pliku rekord o wskazanym kluczu unikalnym”

• Retransmisja komunikatów RPC

Biblioteka Sun RPC zawiera procedury realizujące prosty mechanizm odmierzania ograniczenia czasowego (ang. timeout) i retransmisji w przypadku braku odpowiedzi, ale nie zapewnia niezawodności. Limit czasu oczekiwania na odpowiedź i liczba powtórzeń są z góry ustalone (przez programistę) dla danej aplikacji.

Odwzorowanie numeru komunikatu na numer portu

• W komunikacji klient - serwer numer portu jest:

• 16 -bitowy;

• związany z konkretnym gniazdem biernym serwera;

• powszechnie znany tak, by klienci mogli z niego korzystać.

• W standardzie RPC numer portu dla zdalnego programu jest:

• 16 -bitowy;

• związany z konkretnym programem zdalnym;

• przydzielany tymczasowo; numer portu obowiązuje od momentu rozpoczęcia działania programu zdalnego do jego zakończenia.

• W standardzie RPC klient:

• zna adres komputera;

• zna numer program programu RPC;

• nie zna numeru portu przydzielonego serwerowi po rozpoczęciu przez niego działania i dlatego klient nie może nawiązać bezpośredniego kontaktu z serwerem.

• Konieczny jest mechanizm umożliwiający dynamiczne odwzorowanie numeru programu RPC na numer portu. Mechanizm ten realizuje specjalny serwer - zarządca bazy odwzorowań RPC (ang. RPC port mapper) - operujący na własnej małej bazie danych. Zarządca bazy odwzorowań to standardowy serwer, czyli jego numer portu jest powszechnie znany (port o numerze 111). Obsługuje on bazę par numerów:

(numer programu RPC, numer portu).

• Program RPC (serwer) zaczynając działanie:

• żąda od systemu operacyjnego przydziału wolnego numeru portu;

• wywołuje zarządcę bazy odwzorowań RPC (port 111) i rejestruje swój numer i numer portu;

• Program wywołujący procedurę odległą (klient):

• przesyła zarządcy bazy odwzorowań RPC numer programu odległego;

• otrzymuje od zarządcy bazy odwzorowań RPC numer portu;

• komunikuje się z programem odległym wykorzystując uzyskany numer portu.

Schemat zdalnego wywoływania procedur (RPC)

procedury procedury

klienta serwera

(1) (10) (6) (5)

łącznik łącznik

klienta serwera

(2) (9) (7) (4)

(8)

procedury procedury

sieciowe sieciowe

(3)

jądro lokalne jądro zdalne

Oprogramowanie pomocnicze

• Implementacja mechanizmu Sun RPC zawiera oprogramowanie pomocnicze. Są to:

1. Procedury biblioteczne XDR realizujące przekształcanie danych z postaci przyjętej na lokalnym komputerze na postać XDR i odwrotnie;

2. Procedury biblioteczne XDR służące do formatowania agregatów danych (tablic i struktur) używanych w definicjach komunikatów RPC;

3. Procedury RPC czasu wykonania do wywołania procedury odległej, rejestracji usługi u zarządcy odwzorowań czy przekazania otrzymanego od klienta wywołania właściwej procedurze w zdalnie wywoływanym programie;

4. Generator programów (inaczej generator procedur łącznikowych) produkujący wiele plików źródłowych (w języku C) potrzebnych do zbudowania aplikacji rozproszonej wykorzystującej mechanizm RPC.

• Przykłady funkcji bibliotecznych

1. Funkcja wysyłająca komunikat RPC do serwera.

callrpc(host, prog, progver, procnum, inproc, in,
outproc, out)

gdzie:

host - nazwa komputera odległego

prog - numer programu

progver - wersja programu

procnum - numer procedury

inproc - lokalna procedura dokonująca serializacji
argumentów wywołania RPC wpisywanych do
wysyłanego komunikatu

in - argumenty RPC

outproc - lokalna procedura dekodująca wyniki wywołania
RPC

out - wskaźnik do obszaru pamięci przeznaczonego
na przechowywanie zdekodowanych danych.

• Funkcja nawiązująca komunikację w podanym protokole z daną usługą identyfikowaną poprze numer programu i numer wersji

clnt_create (host, prog, progver, proto)

Zastosowanie narzędzia rpcgen do generowania aplikacji rozproszonych

Rpcgen w implementacjach Sun RPC generuje większość kodu potrzebnego do zrealizowania - po stronie klienta i po stronie serwera - zdalnych wywołań wskazanych procedur. Kod jest produkowany w postaci źródłowej w języku C.

• Wejściem do rpcgen jest plik specyfikacji zawierający deklaracje:

• stałych;

• globalnych typów danych;

• zmiennych globalnych;

• zdalnie wywoływanych procedur (w tym typów argumentów i
  wyników).

• Na wyjściu rpcgen otrzymuje SIĘ:

• komunikacyjne procedury łącznikowe (ang. communication stub)
  dla strony klienta;

• komunikacyjne procedury łącznikowe dla strony serwera;

• Wygenerowane procedury łącznikowe zawierają:

• kod wykonujący serializację argumentów;

• wysyłanie wywołań RPC;

• przekazywanie wywołań właściwej procedurze po stronie serwera;

• wysyłanie odpowiedzi;

• przekształcanie argumentów i wyników z postaci zgodnej
  z reprezentacją rodzimą do reprezentacji zewnętrznej i odwrotnie.

• Programista musi napisać:

• procedury sprzęgające (ang. interface stub) klienta;

• procedury sprzęgające serwera;

• Procedury sprzęgające tworzą interfejs między programem aplikacyjnym a procedurą komunikacyjną.

Pliki na wejściu i wyjściu rpcgen

• Wejście:

Q.x - definicja interfejsu w języku rpcgen.

• Wyjście:

Q.h - definicje stałych i typów danych używanych w kodzie
wygenerowanym dla klienta i dla serwera;

Q_xdr.c - wywołania procedur XDR używanych przez klienta i przez
program serwera w celu dokonania serializacji argumentów;

Q_clnt.c - procedura łącznikowa klienta;

Q_svc.c - procedura łącznikowa serwera

W pogrubionych ramkach zaznaczono pliki dostarczone przez programistę.

Budowanie aplikacji rozproszonej w ośmiu krokach

1. Skonstruuj i przetestuj zwykły, lokalny program użytkowy, rozwiązujący zadany problem.

2. Podziel program na część lokalną i część zdalnie wywoływaną, określając zbiór procedur, które mają być przeniesione do komputera odległego. Umieść te procedury w osobnym pliku.

3. Napisz specyfikację zdalnie wywoływanego programu przeznaczoną dla rpcgen. Specyfikacja musi zawierać:

• Numer zdalnie wywoływanego programu (unikatowy);

• Numer wersji (najczęściej 1);

• Nazwy, numery i deklaracje parametrów wywoływanych procedur;

4. Użyj generatora rpcgen do sprawdzenia specyfikacji, a po uzyskaniu poprawnej - do utworzenie kodu źródłowego dla klienta i serwera.

5. Napisz procedury sprzęgające dla strony klienta i serwera.

6. Wykonaj kompilację i konsolidację plików tworzących program kliencki, tj.:

• Pliku pierwotnie napisanego programu użytkowego (bez procedur przeniesionych na odległy komputer);

• Pliku procedury łącznikowej klienta (wygenerowanego przez rpcgen);

• Pliku procedury sprzęgającej dla klienta;

• Pliku procedur XDR (wygenerowanego przez rpcgen);

Utworzony plik wykonywalny może już być użyty jako klient.

7. W ten sam sposób utwórz program serwera.

8. Uruchom program serwera na komputerze odległym, a następnie wywołaj program klienta na komputerze lokalnym.

Q_svc.c

Q_xdr.c

Q.h

Q_clnt.c

rpcgen

Serwer

Klient

Kompilator
C

Kompilator
C

Q.x

Procedura sprzęgająca serwera

Zdalnie wywoływane procedury

Procedura sprzęgająca klienta

Program użytkowy klienta

---