02

Komunikacja między procesami w Unixie_

■    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

Rozdział 9: Zdalne wywoływanie procedur (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.

9.2. Wykonywanie zdalnych poleceń z poziomu systemu operacyjnego

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