/* Uchwyt rpc klienta.
* Tworzony przez poszczególne implementacje.
* Za zainicjowanie jest odpowiedzialny klient */
typedef struct (
AUTH *cl auth; /* autentykator */
•enum clnt_stat |
(*cl cali) 0; |
/* |
wywołanie procedury zdalnej */ |
void |
(*cl_abort) 0 ; |
/* |
anulowanie wywołania */ |
void |
(*cl_geterr) 0; |
/* |
pobranie kodu błęu */ |
boolt |
(*cl_freeres)(); |
/* |
zwolnienie wyników */ |
void |
(*cl_destroy)(); |
/* |
zniszczenie tej structury */ |
booł t |
<*cl control)(); |
/* |
ioctlO dla rpc */ |
> *cl_ops;
caddr_t cl_private ; /* prywatne */
char *cl_netid; /* identyfikator sieci */
char *cl_tp; /* nazwa urządzenia */
) CLIENT;
stract clnt_ops (
Definicja struktury CLIENT (instrukcja typedef) znajduje się w pliku nagłówkowym <rpc/ clnt. h>.Wskaźnik do tej struktury będzie używany podczas generowania identyfikatora (uchwytu) klienta. Po deklaracjach w programie 9.3 znajduje się fragment kodu uzyskujący nazwę hosta, w którym będzie działał serwer. W poprzednim uruchomieniu nie miało to znaczenia, ponieważ i tak kod był wykonywany lokalnie. Jednakże w tym nowym środowisku proces-klient musi znać nazwę hosta, w którym działa serwer. Nazwa ta jest przekazywana poprzez linię poleceń jako pierwszy argument procesu hello_client. Nie ma żadnego sprawdzania poprawności, umożliwiającego na przykład stwierdzenie, czy host jest w ogóle dostępny. W dalszej kolejności tworzony jest uchwyt klienta. Odbywa się to za pomocą funkcji bibliotecznej dnt_create. Należy ona do garnituru funkcji obsługujących zdalne procedury. Jej definicję przedstawiono w tabeli 9.3.
Funkcja dnt_create wymaga podania czterech argumentów. Pierwszym jest host—wskaźnik na ciąg znaków. Za jego pomocą podaje się nazwę hosta, w którym będzie działał proces-serwer. Następne dwa argumenty, prognum i versnum, określają odpowiednio numer programu oraz jego wersji. Parametr nettype służy do określania klasy protokołu transportowego. Argumentem tym jest z reguły jedną ze stałych z tabeli 9.4.
Pliki włączane |
<rpc/rpc.h> |
Rozdział podręcznika |
3N | |
Prototyp |
CLIENT *clnt_create( const char *host, const u_long prognum, const u_long versum, const char *nettype ); | |||
Zwracana wartość |
Sukces |
Niepowodzenie |
Czy zmienia errno | |
Poprawny identyfikator (uchwyt) klienta |
NULL |
Tak |
Tabela 9.4. Ciąg znaków |
Typy sieci Onis (nodeimowana rbiałanie) |
netpath lub NULL |
Sprawdzenie zmiennej środowiskowej NETPATH, zawierającej listę identyfikatorów sieci, oddzielonych dwukropkami. Zostaną wypróbowane podane protokoły transportowe (patrz tabela 9.5). jeden po drugim, od lewej do prawej, aż znaleziony będzie ten właściwy. Jeżeli zmienna NETPATH nie jest zainicjowana albo ma wartość NULL, widoczny będzie domyślny typ sieci (nettype) |
visible |
Przeglądanie sekwencyjne pliku /etc/netconfig i wybranie protokołów transportowych z ustawionym znacznikiem " v" tvisible). Operacja zostanie zakończona w chwili odnalezienia protokołu transportowego |
circuit_v |
Podobnie jak dla ciągu visible, ale wybieranie tylko protokołów transportowych zorientowanych na połączenia (tpi cots lub tpi_cots ord) |
datagram_v |
Podobnie jak dla ciągu visible, ale wybieranie tylko protokołów transportowych bezpołącze-niowych (tpi cits) |
circult_n |
Podobnie jak dla ciągu netpath, ale wybieranie tylko protokołów transportowych datagramo-wych zorientowanych na połączenia (tpi cots lub tpi cots ord) |
datagram_n |
Podobnie jak dla ciągu netpath, ale wybieranie tylko protokołów transportowych datagramo-wych bezpotączeniowych (tpi_clts) |
udp |
Protokół UDP |
tcp |
Protokół TCP |
Przykładowy plik /etc/netconf ig z hosta autora pokazano w tabeli 9.5
259