9.2.1. RPC - Wstep

Spis tresci

• Wprowadzenie
  
  protokol TCP, protokol UDP
• XDR
  potoki XDR i filtry XDR, potok w pamieci, potok komunikatow, filtry
• Format komunikatow przesylanych przez siec
• Bibliografia

RPC w Linuxie nie jest jednak realizowane przez jadro systemu, a przez standardowa biblioteke LIBC (w jadrze jest zaimplementowany tylko fragment klienta RPC przy okazji systemu NFS). Jak sama nazwa wskazuje, RPC sluzy do zdalnego wywolywania procedur, a dziala w nastepujacy sposob:

1. Klient chcac wywolac procedure zdalna wywoluje procedure lacznika, ktora korzystajac z filtrow XDR (eXternal Data Representation) koduje parametry wywolania procedury (+wlasne dane dodatkowe) na format niezalezny od systemu.
2. Uzywajac protokolu TCP albo UDP klient komunikuje sie przez siec z komputerem serwera i wysyla zakodowana wiadomosc (polega to na wywolaniu odpowiednich funkcji systemowych).
3. Na komputerze serwera dziala proces, ktory oczekuje na zadania klientow (w petli). Po odebraniu wiadomosci przez siec rozkodowuje argumenty procedury do formatu wewnetrznego komputera serwera (przez analogiczny jak u klienta filtr XDR) i wywoluje procedure lokalna serwera.
4. Wyniki tej procedury sa kodowane kolejnym filtrem XDR i sa odsylane klientowi.
5. Klient odbiera wiadomosc i po rozkodowaniu (filtrem odpowiadajacym filtrowi, ktorym byly kodowane) jej wartosci sa zwracane jako rezultat wykonania procedury zdalnej.

Procedury zdalne sa identyfikowane przez trzy liczby: numer programu, numer wersji programu i numer procedury. Pierwsze dwa sluza do otrzymania od portmappera numeru portu (TCP albo UDP) na komputerze serwera. Portmapper jest procesem dzialajacym na komputerze serwera i sluzacym do informowania o numerach portow serwerow RPC; nie jest on odpowiedzialny za ich przydzielanie (patrz: portmapper). Numery procedur identyfikuja procedury w serwerze.
Jako ze RPC moze uzywac dwoch odmiennych protokolow: TCP albo UDP, istnieja dwa typy klientow i warstw transportowych serwera, dzialajacych na troche innych zasadach. Warstwa transportowa posredniczy miedzy pojedynczym gniazdem a serwerem. Serwer RPC moze obslugiwac w jednej chwili kilka warstw transportowych, po jednej na: kazde aktywne polaczenie TCP, na kazde oczekiwanie polaczenia TCP (gniazdo po wywolaniu listen()) oraz na kazde gniazdo UDP. Wiecej o serwerze: patrz serwer.

TCP

Potoki XDR i filtry XDR

Filtr XDR jest procedura kodujaca i dekodujaca pewien typ danych.

Potok XDR jest identyfikowany przez strukture XDR:

enum xdr_op {
        XDR_ENCODE=0,
        XDR_DECODE=1,
        XDR_FREE=2
};

typedef struct {
        enum xdr_op     x_op;
        struct xdr_ops {
                bool_t  (*x_getlong)();
                bool_t  (*x_putlong)(); 
                bool_t  (*x_getbytes)();
                bool_t  (*x_putbytes)();
                u_int   (*x_getpostn)();
                bool_t  (*x_setpostn)();
                long *  (*x_inline)();
                void    (*x_destroy)();
        } *x_ops;
        caddr_t         x_public;
        caddr_t         x_private;
        caddr_t         x_base;
        int             x_handy;
} XDR;

Pole x_op zawiera informacje jaka czynnosc jest w danej chwili wykonywana na potoku: kodowanie, dekodowanie, czy zwalnianie pamieci. Pole x_ops zawiera wskazniki na funkcje, ktore mozna wykonywac na potoku (z tych operacji korzystaja na najnizszym poziomie filtry). Funkcje te przekodowuja dane. Pozostale pola sa uzywane przez rozne potoki w rozny sposob do przechowywania danych pomocniczych (deskryptory plikow, adresy w pamieci, pozycje w potoku, itp.). Typy: bool_t to int, caddr_t to char*.

x_getlong()

- pobiera z potoku typu long

x_putlong()

- wysyla do potoku typu long

x_getbytes()

- pobiera potoku ciag bajtow

x_putbytes()

- wysyla do potoku ciag bajtow

x_getpostn()

- pobiera aktualna pozycje w potoku

x_setpostn()

- ustawia pozycje w potoku

x_inline()

- zwraca wskaznik na aktualna pozycje w buforze potoku

x_destroy()

- zwalnia zasoby zwiazane z tym potokiem

Dla danego potoku nie zawsze wszystkie operacje beda dzialac, np. x_inline() dla potoku zwiazanego z plikiem zawsze zwraca NULL.

Potok w pamieci

void xdrmem_create( XDR *xdrs, caddr_t addr, u_int size, enum xdr_op op)

Parametry:
addr - wskaznik na przygotowany bufor
size - jego rozmiar
op - operacja na potoku.

Dodatkowe dane:
x_private - wskaznik na aktualne polozenie w buforze,
x_base - poczatek bufora,
x_handy - rozmiar wolnej pamieci

Potok komunikatow (rekordow)

Tworzenie:

void xdrrec_create(XDR *xdrs, u_int sendsize, u_int recvsize, caddr_t tcp_handle, int (*readit)(), int (*writeit)())

sendsize, recvsize - rozmiary buforow we i wy
tcp_handle - dowolne parametry (niekoniecznie deskryptor gniazda), ktore beda przekazywane do:
readit, writeit - funkcje czytania z i pisania do jakiegos medium.

Funkcje przejscia do nastepnego, zakonczenia rekordu i sprawdzenia czy juz koniec rekordu:

bool_t xdrrec_skiprecord(XDR *xdrs)
bool_t xdrrec_endofrecord(XDR *xdrs, bool_t sendnow)
bool_t xdrrec_eof(XDR *xdrs)

sendnow oznacza, czy od razu wysylac rekord, czy tylko zapamietywac go w buforze (wyslanie wszystkich zgromadzonych komunikatow nastapi wtedy, gdy bufor sie przepelni lub gdy funkcja xdrrec_endofrecord bedzie wywolana z parametrem sendnow!=0).

Filtry XDR

Naglowek wiadomosci RPC:

struct rpc_msg {
        u_long                  rm_xid;
        enum msg_type           rm_direction;
        union {
                struct call_body RM_cmb;
                struct reply_body RM_rmb;
        } ru;
};

struct call_body {
        u_long cb_rpcvers;      
        u_long cb_prog;
        u_long cb_vers;
        u_long cb_proc;
        struct opaque_auth cb_cred;
        struct opaque_auth cb_verf;
};

struct reply_body {
        enum reply_stat rp_stat;
        union {
                struct accepted_reply RP_ar;
                struct rejected_reply RP_dr;
        } ru;
};

struct accepted_reply {
        struct opaque_auth ar_verf;
        enum accept_stat   ar_stat;
        union {
                [...]
                struct {
                        caddr_t where;
                        xdrproc_t proc;
                } AR_results;
        } ru;
};

struct rejected_reply {
        enum reject_stat rj_stat;
        union { [...] } RJ_versions;
                enum auth_stat RJ_why;
        } ru;
};

Dla wiadomosci od klienta poczatek naglowka jest taki sam (nie do konca, patrz opis klientow) dla wszystkich wywolan procedur, wiec jest kodowany tylko raz. Za tym fragmentem sa przesylane: dalsza czesc naglowka (zakodowany nr procedury, dane na temat autentycznosci i identyfikacji klienta) i zakodowane parametry procedury.
W przypadku wiadomosci od serwera rezultat jest juz zawarty w strukturze rpc_msg.

Mimo, ze struktury te sa bardzo rozbudowane, dzieki odpowiednim filtrom XDR (xdr_union) wysylane sa tylko pola uzywane a nie wszystkie.

1. Biblioteka LIBC, a raczej pliki: ./rpc/* - implementacja RPC
2. Pliki naglowkowe: /usr/include/rpc/*
3. M. Gabbasi, B. Dupouy: ,,Przetwarzanie rozproszone w systemie UNIX'' - opis uzytkowy RPC i XDR
4. RFC 1014 - XDR
5. RFC 1057 - RPC
6. Dokumentacja biblioteki LIBC: /usr/info/libc.info - opis funkcji dotyczacych gniazd
7. R. Stevens: ,,Programowanie zastosowan sieciowych'' - ogolne wiadomosci o RPC