1

Zdalne Wywołanie

Procedury

RPC

2

Wzorcem łączności stosowanym przez programy aplikacji
jest paradygmat żądanie/odpowiedź, zwany również
transakcja komunikatów. Protokół transportowy
obsługujący paradygmat żądanie/ odpowiedź to o wiele
więcej niż komunikat UDP przekazywany w jednym
kierunku, po którym następuje komunikat UDP
przekazywany w przeciwnym kierunku. TCP dostarcza za
pomocą strumienia bajtów odmiennej semantyki od
abstrakcji żądanie/odpowiedź.

W jaki sposób zrealizować taką abstrakcję?

Paradygmat żądanie/odpowiedź stanowi centrum
zdalnego wywołania procedury (Remote Procedure Call)
RPC.

3

Diagram czasowy RPC

Klien
t

Serwer

Żądanie

Odpow

iedź

Obliczanie

Blokada

Blokada

Blokada

RPC jest popularnym mechanizmem w strukturach
systemów rozproszonych. RPC wywodzi się z semantyki
lokalnego wywołania procedury - program aplikacji
dokonuje wywołania procedury, lokalnie lub zdalnie,
blokując się do momentu powrotu z procedury.

4

Mechanizm RPC składa się dwóch podstawowych
elementów.

1.Protokołu, który zarządza komunikatami przesyłanymi
między procesami klienta i serwera i pokonuje
niedoskonałości sieci.

2.Języka programowania i kompilatora, wspierających
umieszczanie argumentów w komunikacie żądania w
komputerze klienta i odtwarzanie tych argumentów w
komputerze serwera z odpowiednia wartością zwrotną.
Ta część nosi nazwę kompilatora przyczółka (stub
compiler).

Części składowe RPC

5

Caller

(klient)

Lokalny
Przyczółek
Klienta

Protokół
RPC

Zwracana
wartość

Argumenty

Odpowiedź

Żądanie

Called

(serwer)

Argumenty

Żądanie

Zwracana
wartość

Protokół
RPC

Lokalny
Przyczółek
Serwera

Mechanizm RPC

6

Co się dzieje gdy klient wywoła zdalną
procedurę?

•Klient wywołuje przyczółek lokalny,
•Przyczółek ukrywa fakt że procedura jest zdalna przez
przetłumaczenie argumentów na komunikat żądania.
Następnie wywołuje protokół RPC.

•RPC nadaje komunikat do serwera
•W serwerze protokół RPC dostarcza komunikat do
przyczółka lokalnego

•Przyczółek tłumaczy żądanie na argumenty procedury i
wywołuje procedurę lokalną.

•Ta wykonuje się i zwraca odpowiedź do przyczółka
serwera, który umieszcza ją w komunikacie i przekazuje
do protokołu RPC.

•RPC po stronie klienta przekazuje komunikat do
lokalnego przyczółka.

•Przyczółek przekształca go na wartość zwrotną, którą
zwraca do programu klienta.

7

•

Protokół RPC wykonuje skomplikowane zadania

dlatego traktujemy RPC jako stos trzech

protokołówrealizujących kilka algorytmów

potrzebnych do implementacji RPC:

–

BLAST: dzieli na fragmenty i składa duże

komunikaty.

–

CHAN: synchronizuje komunikaty żądania i

odpowiedzi.

–

SELECT: rozdziela komunikaty żądań do

właśćiwych procesów.

Te mikroprotokoły są samodzielnymi protokołami,

które mogą być stosowane w rozmaitych

kombinacjach.

8

Przesyłanie masowe (BLAST)

Protokół BLAST dostosowuje sieć, która dostarcza
komunikaty niewielkich rozmiarów np. 1kB w usługę,
która dostarcza komunikaty o dużo większym rozmiarze
np. 32kB i większe.
Algorytm BLAST:
BLAST stosuje technikę fragmentacji i składania.

•Nadawca dzieli komunikat na zbiór mniejszych
fragmentów, a następnie przesyła je jeden po drugim
przez sieć nie czekając na potwierdzenia. Stąd nazwa
BLAST (podmuch wybuchu).

•Odbiorca nadaje selektywne żądanie retransmisji SRR,
wskazując które fragmenty przyszły, a które nie. W
przypadku gdy przyszły wszystkie SRR służy do
potwierdzenia całego komunikatu.

•Nadawca retransmituje utracone komunikaty

BLAST nie gwarantuje jednak dostawy komunikatów.

9

Diagram czasowy protokołu BLAST

• W odróżnieniu od

protokołów AAL i IP,

BLAST próbuje odzyskać

komunikat retransmitując

utracone fragmenty

• Strategia

– selectywna retransmisja
– częściowe potwierdzenia

Nadawca

Odbiorca

Fragme

nt 1

Fragme

nt 2

Fragme

nt 3

Fragme

nt 5

Fragme

nt 4

Fragme

nt 6

Fragme

nt 3

Fragme

nt 5

SRR

SRR

10

BLAST szczegółowo

• Nadawca:

– po wysłaniu wszystkich fragmentw ustawia zegar DONE

– jeżeli otrzyma SRR, wysyła utracone fragmenty i resetuje

zegar DONE

– jeżeli zegar DONE upływa nadawca zwalmia swoja kopie

komunikatu i rezygnuje.

11

• Odbiorca:

– kiedy porzybywa pierwszy fragment, inicjuje strukture do

zapamiętania kolejnych fragmentów i ustawia zegar

LAST_FRAG

– kiedy otrzymał wszystkie fragmenty, zestawia komunikat i

przekazuje go wyżej

– mogą zaistniec cztery wyjątki od tego scenariusza:

• jeśli ostatni fragment nadejdzie lecz komunikat nie jest

kompletny

– wysyła SRR i ustawia zegar RETRY

• jeśli upływa zegar LAST_FRAG

– wysyła odpowiedni SRR i ustawia zegar RETRY

• jeśli zegar RETRY upływa poraz pierwszy lub drugi

– wysyła SRR i ustawia zegar RETRY

• jeśli zegar RETRY upływa po raz trzeci

– rezygnuje i usuwa zegar LAST_FRAG

BLAST szczegółowo cd.

12

Format nagłówka protokołu BLAST

• ProtNum identyfikuje protokół wyższego

poziomu.

• MID identyfikator komunikatu, które mogą

nadchodzic nie po kolei. Odpowiednia

liczba bitów pola zabezpiecza przed

zapętleniem (inkarnacją).
Najgorszy scenariusz: fragmenty 1B

opóźnienie dla internetu/ tempo transmisji

10Mb/s. 60s/1=60·10

6

·wartości.

• NumFrags wskazuje liczbę fragmentów
• TYPE = DATA or SRR
• FragMask zapewnia rozróżnianie

fragmentów

– Type=DATA, i-ty bit=1 reszta zera

identifikuje i-ty fragment

– Type=SRR, i-ty bit=1 identifikuje

odebrany fragment i-ty bit=0 oznacza

brakujący fragment

Data

ProtNum

MID

Length

NumFrags

Type

FragMask

0

16

31

13

Żądanie/Odpowiedź (CHAN)

Mikroprotokół CHAN implementuje logiczny kanał żadanie/odpowiedź między

parą uczestników.

• Gwarantuje dostawę komunikatu

• Synchronizuje procesy klienta i serwera. Klient blokuje się na czas oczekiwania

odpowiedzi od serwera.

• Zachowuje semantyke at-most-once. Oznacza to, że na każdy komunikat

żądania nadany przez klienta, najwyżej jedna kopia tego komunikatu jest

dostarczana do serwera. Czyli procedura jest wywoływana co najwyżej jeden

raz. (vs. zero-or-more)

Prosty daigram czasowy ukryte (implicit) ACK

Klient

Serwer

Żądanie

ACK

Odpo

wied

ź

ACK

Klient

Serwer

Żądanie

1

Żądanie

2

Odp

2

Odp

1

…

14

Szczegóły CHAN

• Serwer i klient zapamiętują kopię komunikatu do

czasu nadejścia odpowiedzi lub ACK. Każda strona
ustawia także zegar RETRANSMIT iponownie nadaje
komunikat gdy upływa czas zegara. Obie strony
regeneruja zegar i podejmują ustaloną liczbę prób.

– Komunikat którego pole MID nie pasuje do

następnego oczekiwanego MID jest odrzucany.

• Serwer może wymagac dowolnie długiego czasu na

wytworzenie wyniku (long running server)

– klient co pewien czas wysyła sondę “are you alive”
– serwer periodycznie nadaje komunikat “I’m alive”

15

Format komunikatu w protokole CHAN

Data

MID

BID

Numer Protu

Długość

0

16

31

Typ

TCID

•CID identyfikuje kanał logiczny do
którego ten komunikat należy 2

16

=64k

współbieżnych transakcji
żądanie/odpowiedź między dowolna
para komputerów.

•MID identyfikuje każda parę
żądanie/odpowiedź pole jest dłuższe niż
jeden bit ponieważ komunikaty mogą
błądzić w sieci przez pewien czas.

•BID identyfikator restartu (ładowania,
boot identyfier) komputera. Liczba BID
odczytywana z dysku i jest zwiększana
o jeden przy każdym restarcie
komputera i ponownie zapisywana na
dysk podczas uruchamiania
komputera. BID jest następnie
umieszczany w każdym komunikacie
nadawanym przez ten komputer.
Podobnie jak MID chroni przed starymi
komunikatami.

16

Dyspozytor (SELECT)

• Rozdziela komunikaty żądań do

właściwych procedur. Jest to

demultiplekser synchroniczny w

odróżnieniu od UDP.

– Po stronie klienta SELECT

otrzymuje numer procedury,

która chce wywołać.

– Wywołuje protokół niższy np.

CHAN

– Po stronie serwera

wykorzystuje num. proc. do

wyboru właściwej lokalnej

proc.

– Kiedy następuje powrót z

tego wywołania SELECT

przekazuje wartośc zwracana

do kilienta wykorzystując nr

proc.

• Przestrzeń nr. proc.

– jest płaska.

– hierarchiczna: program +

procedure number

Klient

SELECT

CHAN

xCall

xCall

xDemux

xPush

Serwer

SELECT

CHAN

xCallDemux

xCallDemux

xDemux

xPush

17

Prosty stos protokołów RPC

BLAST

ETHERNET

IP

SELECT

CHAN

•Na dole znajdują się protokoły, które implementują
sieć np. Ethernet.

•BLAST przekształca komunikaty IP w usługę
komunikacyjną, która obsługuje duże komunikaty
np. 32kB. (IP może obsługiwać kom. O długości 64kB,
ale musi dokonywać ich fragmentacji ze względu na
ograniczenia Ethernetu. BLAST traktujemy jako
protokół nadrzędny w stosunku do IP, ponieważ jest on
w stanie retransmitować utracone fragmenty. Przenosi
to ciężar fragmentacji na BLAST, tak długo jak IP nie
musi dokonać swej fragmentacji w którymś miejscu
sieci.

•CHAN mechanizm czasu oczekiwania i potwierdzenia
w CHAN zapewniają niezawodność dostarczania
komunikatów (nierób niżej tego co możesz zrobić wyżej).

•Odpowiednia wersja SELECT definiuje przestrzeń
adresów dla identyfikacji zdalnych procedur.
Protokoły SELECT, CHAN, i BLAST, mimi że poprawnie
działajace nie są znormalizowane.

18

SunRPC

Szeroko stosowany SunRPC nie został rónież

zatwierdzony przez żadna organizację

normalizacyjnąm ale de facto stał się normą i ze

względu na jego centralną role w systemie NFS

rozważa się przyjęcie go jako znormalizowanego

protokołu internetu pod nazwą Open Network

computing ONC.

• SunRPC jako odpowiednik CHAN implementuje

zasadniczy algorytm żądanie/odpowiedź

– nie gwarantując semantyki at-most-once

• Rolę protokołu SELECT spełniają UDP + SunRPC

– UDP rozdziela komunikaty do programów

poprzez zwiazane z nimi porty

– SunRPC rozdziela komunikaty do procedur

wewnątrz programu

• Nadawanie komunikatów, które są większe

od MTU sieci obsługiwana jest przez IP.

– Poza selektywna retransmisją (BLAST)

IP

ETH

SunRPC

UDP

19

SunRPC stosuje dwuwarstwowe adresy do identyfikacji
procedur zdalnych 32b nr programu i 32b nr portu. Aby
określić, który port odpowiada danemu numerowi
programu istnieje oddzielny program SunRPC (port
mapper) który odwzorowuje numery programów w
numery portów odpowiada mu stały port UDP 111.
Program ten obsługuje kilka procedur, z których
procedura 3 odwzorowuje programy w porty.

Przykład.

Aby nadać komunikat żądania do procedury read w
NFS, klient najpierw nadaje komunikat żądania do
programu odwzorowującego adresy na port UDP 111,
prosząc aby została wywołana procedura 3 do
odwzorowania numeru programu x00100003 na port UDP.
Klient nadaje komunikat żądania z nr procedury 6 read
do tego portu UDP, a moduł NFS w tym porcie wywołuje
procedurę read.Klient zapamiętuje w pamięci
podręcznej odwzorowanie programu w nr portu i nie
musi on wracać do programu odwzorowującego za
każdym razem kiedy odwołuje się do programu NFS.

20

Format nagłówka SunRPC

• XID identyfikator transakcji

podobny do MID prot. CHAN

• Serwer nie zapamiętuje ostatniego

XID, który otrzymał

• Powstaje problem igdy klient

retransmituje żądanie podczas

kiedy odpowiedź jest w drodze.

Serwer sadzi, że zakończył już

transakcję o nr XID.

• Credentials - Referencje

Verifier - Weryfikator
Obydwa pola służą do

przedstawienia dowodu, że klient

ma prawo do korzystania z serwera.

Data

MsgType = CALL

XID

RPCVersion = 2

Program

Version

Procedure

Credentials (variable)

Verifier (variable)

0

31

Data

MsgType = REPLY

XID

Status = ACCEPTED

0

31

21

Interfejs programowania aplikacji

Protokoły końcowe są często dostępne dla programów
aplikacji i dlatego musza one zapewniać dostęp do
świadczonych przez nie usług komunikacyjnych. Ten
interfejs nosi nazwę interfejsu programowania aplikacji
(application programing interface) API.

W zasadzie każdy system operacyjny ma swobodę
definiowania swojego własnego API. Jednak pewne z tych
interfejsów stały się na tyle powszechne, że są
przekazywane do innych niż rodzime systemów
operacyjnych. Ułatwia to przenoszenie programów
aplikacji pomiędzy systemami. Dlaczego dany API staje
się popularniejszy niż inne?

W dziedzinie sieci komputerowych, najpopularniejszym
interfejsem API jest interfejs gniazda (socket interface).
Oryginalnie był on opracowany w implementacji Unixa w
wersji Berkley. Obecnie został on przeniesiony do prawie
wszystkich wersji Unixa, a nawet do MS Windows.

22

Protokół definiuje semantykę komunikacji. Na
przykład, Protokół definiuje takie abstrakcyjne pojęcia
jak „porty” i „połączenia” oraz operacje jak „ otwarcie
aktywne” i „otwarcie pasywne”. (diagram stanów TCP).

Interfejs programowania aplikacji definiuje składnię
(syntax) komunikacji. Na przykład API definiuje zbiór
obiektów: sesji i uczestników własny zbiór operacji (Open,
OpenEnable).

Implementacja odwzorowuje rzeczywisty zbiór
operacji i obiektów zdefiniowanych przez API na
abstrakcyjny zbiór operacji i obiektów
zdefiniowanych przez protokół. Na przykład sesji na
porty, a Open na „aktywne otwarcie”.

23

Relacja między interfejsem programowania
aplikacji i protokołem

Aplikacja

API

Protokół

Tranportowy

Otwarcie aktywne
Otwarcie pasywne

xOpen
xOpenEnable

24

Opis interfejsu gniazda

Główna abstrakcja interfejsu gniazda jest samo gniazdo
(socket). Jest to punkt w którym loklny proces aplikacji
dołacza się do sieci.

Interfejs definiuje:

•operację utworzenia gniazda,
•dołączenia gniazda do sieci,
•nadawania i odbioru komunikatów przez gniazdo
•oraz operację zamknięcia gniazda.

25

•Utworzenie gniazda

int socket(int domain, int type, int protocol)

Argument domain specyfikuje rodzine protokołów którą
będziemy wykorzystywać. Np. PF_INET oznacza rodzinę
internetu, PF_UNIX oznacza opcje łącza (pipe facility)
Unixa.

Argument type wskazuje semantykę komunikacji. Np.
SOCK_STREAM oznacza strumien bajtów, a SOCK_DGRAM
usługę przesyłania komunikatów.

Argument protocol identyfikuje konkretny
wykorzystywany protokół.

Wartość zwracana przez operację socket jest uchwytem
(handle) nowo utworzonego gniazda. Jest ona podawana
jako argument innych operacji na gniazdach.

26

•W komputerze serwera, proces aplikacji wykonuje
następujące trzy instrukcje w celu wykonania otwarcia
pasywnego:

int bind(int socket, struct sockaddr*address, int
addr_len)

int listen(int socket, int baclog)

int accept(intsocket, struct sockaddr*address,
int*addr_len)

Operacja bind wiąże nowo utworzony socket ze
specyfikowanym adresem. Jest to adres lokalnego
uczestnika, czyli serwera. Zauważmy, że w przypadku
protokołów internetu address jest struktura danych,
zawierająca adres IP oraz numer portu UDP lub TCP.

Operacja listen definiuje liczbę połonczeń oczekujących
w specyfikowanym socket. Np. TCP przechodzi do stanu
nasłuchiwanie.

Operacja accept wykonuje otwarcie pasywne. Jest to
operacja blokująca, która nie dokonuje zwrotu wartości
zanim uczestnik zdalny nie nawiąże połączenia.

27

Po nawiązaniu połączenia operacja accept zwraca nowo
utworzone gniazdo, które odpowiada właśnie
nawiązanemu połączeniu, a argument address zawiera
adres zdalnego uczestnika.

Kiedy operacja accept zwraca wartość to oryginalne
gniazdo podane jako jej argument nadal istnieje i
odpowiada otwarciu pasywnemu dla przyszłych wywołań
operacji accept.

•W komputerze klienta, proces aplikacji wykonuje
otwarcie aktywne wywołując operację

int connect(int socket, struct sockaddr*address,
int addr_len)

Operacja ta zwraca wartość po pomyślnym zakończeniu
trójetapowej wymiany, co oznacza że aplikacja może
zacząć nadawać dane. Argument address określa adres
uczestnika zdalnego. W odróżnieniu od serwera, który
używa dobrze znanego portu, system operacyjny klienta
po prostu wybiera port niewykorzystywany.

28

Presentation Formatting

• Marshalling (encoding)

application data into

messages

• Unmarshalling

(decoding) messages

into application data

• Data types we consider

– integers

– floats

– strings

– arrays

– structs

Application

data

Presentation

encoding

Application

data

Presentation

decoding

Message Message

Message

…

• Types of data we do not consider

– images

– video

– multimedia documents

29

Difficulties

• Representation of base types

– floating point: IEEE 754 versus non-standard
– integer: big-endian versus little-endian (e.g., 34,677,374)

• Compiler layout of structures

(126)

(34)

(17)

(2)

00000010

Big-endian

Little-endian

(2)

(17)

(34)

(126)

High

address

Low

address

0

0

111111

0

0

0

0

1 0 0

1

0

0

0

01 001

0

0

0

0

1 0 0

1

0

0

0

01 001

0

0

0 000 0

1

0

0

1

1

1

1

1

1

30

Taxonomy

• Data types

– base types (e.g., ints, floats); must convert

– flat types (e.g., structures, arrays); must pack

– complex types (e.g., pointers); must linearize

• Conversion Strategy

– canonical intermediate form

– receiver-makes-right (an N x N solution)

Marshaller

Application data structure

31

Taxonomy (cont)

• Tagged versus untagged data

• Stubs

– compiled

– interpreted

type =

INT

len = 4

value = 417892

Call P

Client

stub

RPC

Arguments

Marshalled

arguments

Interface

descriptor for

Procedure P

Stub

compiler

Message

Specification

P

Server

stub

RPC

Arguments

Marshalled

arguments

Code

Code

32

eXternal Data

Representation

(XDR)

• Defined by Sun for use with SunRPC
• C type system (without function pointers)
• Canonical intermediate form
• Untagged (except array length)
• Compiled stubs

33

#define MAXNAME 256;

#define MAXLIST 100;

struct item {

int count;

char name[MAXNAME];

int list[MAXLIST];

};

bool_t

xdr_item(XDR *xdrs, struct item *ptr)

{

return(xdr_int(xdrs, &ptr->count) &&

xdr_string(xdrs, &ptr->name, MAXNAME) &&

xdr_array(xdrs, &ptr->list, &ptr->count,

MAXLIST, sizeof(int), xdr_int));
}

Count

Name

J

O

3

7

H

N

S

O

N

List

3

497

265

8321

34

Abstract Syntax Notation

One (ASN-1)

• An ISO standard

• Essentially the C type system

• Canonical intermediate form

• Tagged

• Compiled or interpretted stubs

• BER: Basic Encoding Rules

(tag, length, value)

value

type

type

length

value

length

type

value

length

INT

4

4-byte integer

35

Network Data

Representation

(NDR)

• Defined by DCE

• Essentially the C type

system

• Receiver-makes-right

(architecture tag)

• Individual data items

untagged

• Compiled stubs from IDL

• 4-byte architecture tag

– IntegerRep

• 0 = big-endian

• 1 = little-

endian

– CharRep

• 0 = ASCII

• 1 = EBCDIC

– FloatRep

• 0 = IEEE 754

• 1 = VAX

• 2 = Cray

• 3 = IBM

IntegrRep

0

4

8

16

24

31

FloatRep

CharRep

Extension 1

Extension 2