■ Jeżeli klient wysunie kilka identycznych żądań, jak powinien je rozpatrzyć serwer? Rozwiązanie tej kwestii pozostawiono konkretnym implementacjom programowym. Niektóre operacje (na przykład odczyt) mogą rzeczywiście być wykonywane wiele razy. W innych sytuacjach (na przykład w przetwarzaniu transakcyjnym) żądanie może być zgłoszone tylko raz. Dlatego implementacja programowa powinna uwzględniać specyfikę konfiguracji. Niemniej jednak definicja RPC z założenia ma być niezależna od protokołu transportowego. Jeżeli RPC działa opierając sie na niezawodnym systemie transportu (na przykład TCP), klient wysyłający żądanie ma pełne prawo zakładać, że zostanie ono wykonane.
■ Jak rozwiązać przekazywanie parametrów przez referencję (przekazywanie wskaź-, ników), jeżeli procesy funkcjonują w różnych komputerach? Co gorsza, całkiem
prawdopodobne jest to, że procesy serwera i klienta działają w ogóle na różnych platformach (Sun, VAX, IBM itd.). Aby rozwiązać ten problem i zapewnić procesom swobodę komunikacyjną niezależnie od platform, dane płzekazywane między serwerem a klientem muszą zostać przekształcone do postaci niezależnej od architektury systemu. Taki niezależny format danych proponowany przez firmę Sun nosi nazwę XDR (eXtemal Data Representation — zewnętrzna reprezentacja danych). Za translację i transmisję danych w formacie XDR odpowiedzialne są procedury wejścia klienta i serwera (procedury szeregujące i deszeregujące). Zależności między klientem a serwerem na wysokim poziomie podczas funkcjonowania systemu RPC przedstawiono na ilustracji 9.1.
proces-klient
procedura
wejścia
klienta
konwersja do formatu XDR
konwersja do postaci wewnętrznej klienta
żądanie
odpowiedź
proces-serwer
konwersja do postaci wewnętrznej
konwersja do formatu XDR
procedura
wejścia
serwera
Ilustracja 9.1. Zasady działania systemu klient-serwer opartego na RPC
Jak zobaczymy, choć jest to ukryte przed zwykłym użytkownikiem, system RPC został oparty na komunikacji gniazd. Wszelkie zagadnienia związane z gniazdami są szczegółowo opisane w rozdziale 10.
W linii poleceń systemu operacyjnego można wpisać polecenie rpcinfo. Umożliwia ono wyświetlenie wszystkich zarejestrowanych usług RPC. Jeżeli użyje się opcji -s, informacje pojawią się w postaci zwięzłej. W przypadku starszej wersji rpcinfo taką postać danych zapewnia skorzystanie z opcji -p (a nie -s). Niektóre wersje rpcinfo wymagają podania nazwy hosta. Jeśli nie jest ona znana, można ją wyświetlić za pomocą polecenia hostname.
Zanim poznamy tajniki posługiwania się systemem RPC od strony programowania, dobrze będzie, jeśli poznamy zagadnienie z punktu widzenia użytkownika wykonującego polecenia z poziomu systemu operacyjnego. Większość wersji systemu Unix wyposażono w kilka poleceń umożliwiających użytkownikowi wykonywanie operacji w trybie zdalnym. Najczęściej obsługiwane polecenie to rsh (remote shell — zdalna powłoka). Jego ogólna składnia jest następująca:
% rsh [opcje] nazwa_zdalnego_hosta polecenie
Polecenie rsh łączy się ze zdalnym hostem i wykonuje wskazane polecenie. Standardowe wejście z hosta lokalnego jest kopiowane na standardowe wejście hosta zdalnego, z kolei standardowe wyjście oraz standar dowe wyjście błędów zdalnego hosta trafiają do odpowiadających im plików hosta lokalnego. Na przykład w systemie autora polecenie:
morpheus% rsh obiwan whodo
spowodowało uruchomienie polecenia whodo na zdalnym hoście o nazwie obiwan. Wynik działania polecenia został wyświetlony na standardowym wyjściu lokalnego hosta o nazwie morpheus. Wynik zdalnego polecenia można przekierować. Przy okazji warto sobie uświadomić kilka niuansów z tym związanych. Poniższe sekwencje poleceń wydaj:, się bardzo podobne:
morpheus% rsh obiwan whodo > /tmp/whoosie
morpheus% rsh obiwan whodo ">" /tmp/whoosie
Jednak pierwsze z nich powoduje skierowanie wyniku polecenia whodo do pliku whc-osie w katalogu tmp hosta morpheus, a drugie do pliku whoosie w katalogu tmr hosta zdalnego obiwan! Dzieje się tak dlatego, że znak przekierowarua został ujęty w cudzysłów, a więc przekazany jako element składowy polecenia, przez co nie został obsłużony przez lokalnego hosta.
Czasem polecenia wykonywane zdalnie zawieszają się z niewiadomych powodów. Często problemów takich można uniknąć, dodając (przed nazwą hosta) opcję -n, która prze-kierowuje wejście rsh do pliku /dev/null. Jak się można spodziewać, polecenia rsh
247