wykład 7

Składowe
Co robi serwer
1. Rejestracja interfejsu –
rejestracja pozwala systemowi
RPC na mapowanie wywołań
klienta do właściwej funkcji
serwera.
2. Informacja dowiązania wskazuje
RPC jakich protokołów serwer
będzie nasłuchiwał (mają one
czasami różne możliwości)
3. Rejestracja w mapie punktów
końcowych umożliwia klientom
uzyskanie informacji na jakim
punkcie serwer nasłuchuje (na
ogół tcp/ip lub named pipe).
4. Oczekiwanie na żądania
Co robi klient
1. Tworzenie uchwytu dowiązania
(binding handle): jaki serwer w
jaki sposób (różnew poziomy
kontroli)
2. Wywołanie RPC przez stub w
sposób identyczny z lokalnym
3. Znalezienie procesu serwera za
pomocą endpoint map
4. Przepakowanie argumentów i
wysłanie
IDL
• IDL służy do uzgadniania interfejsów pomiędzy
stronami. Tworzy kontrakt
• Samo IDL jest niezależne od systemu
• Kompilator IDL pozwala na mapowanie na języki
programowania
• Konfigurację specyficzną dla systemu zawierają ACF
(można ew. połączyć z IDL)
• ODL – do definiowania obiektów będzie o tym później
Przykładowy IDL
[
uuid (906B0CE0-C70B-1067-B317-00DD010662DA),
implicit_handle(handle_t hExample1Binding)
]
interface r1test
{
void HelloProc([in, string] unsigned char * pszString);
void Shutdown(void);
}
•IDL zawiera informacje niezależne od platformy
•Plik IDL zawiera kilka definicji interfejsów. Każda definicja składa się z
nagłówka w [] i ciała {}
•Nagłówek zawiera atrybuty odnoszące się do interfejsu jako całości (w
szczególności GUID)
•Ciało zawiera deklaracje funkcji (podobne do C) i atrybuty opisujące
poszczególne elementy deklaracji
•Istnieją także pliki ACF zawierajace atrybuty zależne od platformy (czyli nie
wpływające na samą komunikację). Można je dołączyć do IDL (np.
implicit_handle)
Wiązanie
• Klient musi wiedzieć do jakiego serwera się
połączyć. Ustalamy to za pomocą wiązania i
pliku ACF
– [auto_handle]
– [implicit_handle]
– [explicit_handle]
• Kolejne poziomy dowiązania pozwalają ustalić
coraz bardziej szczegółowe definicje dowiązania
użyte przez RPC RTL do wykonywania wywołań
(od użycia lokatora aż po pełną kontrolę)
Wywołania
• Po ustaleniu dowiązania funkcje z klienta
wywołujemy tak jak lokalne
• Należy zadbać o odpowiednie ustawienia
zabezpieczeń dla używanego protokołu (firewall)
• Należy pamiętać o dużym koszcie czasowym
uzdalniania wywołań, fasada wywołań zdalnych
• Wywołania mogą się nie powieść z różnych
powodów nie występujących w rozwiązaniach
lokalnych. Należy obsłużyć wyjątki.
Konteksty
•
•
•
•
•
•
Czasami konieczne jest zachowanie stanu sesji pomiędzy klientem i
serwerem. Nie zawsze (bezpieczeństwo, wygoda, efektywność) można
wykorzystać wzorzec Client Session State dla całych danych (a tylko dla
uchwytu kontekstu) i stosujemy Server Session State (ew. Database
Session State). Wzorce stanu sesji
W pliku IDL definiujemy uchwyt z atrybutem [context_handle] i standardowo
void*
Z punktu widzenia serwera uchwyt kontekstu jest wskaźnikiem void* którym
możemy wskazać dane sesji. Do klienta przesyłany jest uchwyt a nie adres!
Klient jedynie przekazuje uchwyt w celu identyfikacji sesji. W jego
kontekscie (przestrzenii adresowej) jest on bez znaczenia.
W przypadku utraty łączności serwer wywołuje funkcje run-down (o ile
atrybut [context_handle] jest w typedef). Klient zaś resetuje kontekst po
swojej stronie wywołaniem odpowiedniej funkcji
(RpcSsDestroyClientContext)
Context_handle może prowadzić do problemów z wątkowaniem przy
jednoczesnych wywołaniach. Zazwyczaj dostęp do instancji uchwytu jest
serializowany w środowisku wielowątkowym.