J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 1

Architektura klient serwer

6. Architektura typu Klient – Serwer


Architektura klient - serwer to sposób przetwarzania informacji
gdzie proces

żądający usług i proces dostarczający usług są

wyodr

ębnione. Jest ona szczególnie wygodna w systemach

sieciowych i rozproszonych.

•

Klient – proces potrzebuj

ący pewnej usługi i zlecający ja

serwerowi.

•

Serwer – proces dostarczaj

ący usługi zlecanej przez klienta.

S1

Serwery

K1

Klienci

K2

Kn

S2

S3

Serwer S1 jest

klientem serwera S3

Ilustracja architektury klient – serwer.

Procesy klientów i serwerów mog

ą być zlokalizowane na tych

samych b

ądź innych komputerach. Proces serwera może być

klientem serwera innej us

ługi.

Komunikacja
Podzia

ł ze względu na separację bajtów:

•

Strumieniowa (np. TCP)

•

Komunikaty (np. UDP)

Podzia

ł ze względu na synchronizację nadawcy i odbiorcy:

•

Synchroniczna

- zwykle

•

Asynchroniczna

- rzadko

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 2

Architektura klient serwer

Je

żeli stosowane są funkcje send (),receive () to do realizacji

zlecenia potrzebne s

ą cztery wywołania tych funkcji:

Aplikacja klienta

send(...)

Aplikacja serwera

receive(...)

oczekiwanie

receive(...)

send(...)

oczekiwanie

realizacja

zlecenie

odpowiedź

Komunikacja wy

ślij-odbierz

W systemach rozproszonych Mach, Amoeba, Chorus, QNX
zaprojektowane s

ą protokoły specjalnie przeznaczone dla

przetwarzania klient – serwer.

•

DoOperation(port_serwera, zamowienie,

odpowiedź)

•

GetRequest(port_serwera, zamowienie)

•

SendReply(port_klienta, odpowiedź)

Aplikacja klienta

DoOperation(...)

Aplikacja serwera

oczekiwanie

GetRequest(...)

SendReply(...)

oczekiwanie

realizacja

zamowienie

odpowiedź

Komunikacja zamówienie-odpowied

ź

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 3

Architektura klient serwer

Operacja DoOperation(...) dla ka

żdego zamówienia wytwarza jego

unikalny numer sprawdzany przy odbiorze. Umo

żliwia to

sprawdzenie czy odpowied

ź jest na dane w parametrze

zamówienie czy spó

źnioną odpowiedzią na wcześniejsze zlecenie.

typ komunikatu

(zamówienie / odpowied

ź)

identyfikator zamówienia

(liczba naturalna)

parametry zamówienia

Struktura komunikatu zamówienie-odpowied

ź

B

łędy komunikacji klient – serwer:

•

Komunikaty mog

ą być gubione – (awaria sieci )

•

Procesy mog

ą ulegać awarii

•

Nie wyst

ępują uszkodzenia danych

Klient nie ma mo

żliwości odróżnienia awarii komunikacji od awarii

serwera. Gdy serwer nie odpowiada wykonuje N powtórze

ń.

Pytania:

•

po jakim czasie powtarza

ć

•

ile razy powtarza

ć

Popularnym protoko

łem obsługi komunikacji klient – serwer jest

Sun RPC (

ang. Remote Procedures Calls). Do realizacji RPC

stosowane s

ą trzy protokoły

•

R

- Zamówienie (

ang. Request)

•

RR - Zamówienie – odpowied

ź (ang. Request-Reply)

•

RRA - Zamówienie – odpowied

ź – potwierdzenie (ang.

Request-Reply-Acknowledge)

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 4

Architektura klient serwer

klient

serwer

serwer

klient

serwer

klient

protokól R

protokól RR

protokól RRA

Powtarzanie zamówie

ń

Funkcja DoOperation() powtarza zamówienie gdy po pewnym
czasie brak odpowiedzi. Dopiero gdy po N krotnym powtórzeniu
brak odpowiedzi zwraca informacj

ę do klienta że serwer jest

niedost

ępny.

Pomijanie powtórzonych zamówie

ń

Gdy klient (lub funkcja DoOperation()) retransmituje zamówienie
serwer mo

że wielokrotnie otrzymać te samo zamówienie.

Serwer powinien odró

żniać retransmisję komunikatu od

powtórzenia zamówienia. Gdy zamówienia s

ą numerowane

serwer powinien zignorowa

ć powtórzone komunikaty tego

samego zamówienia.

Utracone komunikaty z odpowiedziami.
Komunikaty z odpowiedzi

ą mogą ulec zagubieniu. Wtedy klient

(lub funkcja DoOperation()) retransmituje zamówienie. Co si

ę

zdarzy gdy serwer wykona operacj

ę wielokrotnie?

Operacja idempotentna (ang. idempotent operation)
Operacja idempotentna to taka operacja której wielokrotne
wykonanie powoduje taki sam skutek jakby by

ła wykonana

jednokrotnie.



Operacje idempotentne: dodawanie do zbioru
Operacje nie idempotentne: dodawanie liczb

Rejestr odpowiedzi
Aby w przypadku retransmisji tego samego zamówienia serwer nie
musia

ł wykonywać operacji ponownie stosuje się rejestr

odpowiedzi.

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 5

Architektura klient serwer

Rejestr taki powinien zawiera

ć:

•

Identyfikator zamówienia

•

Identyfikator klienta

•

Odpowied

ź

•

Czas bie

żący

Po przyj

ściu kolejnego zamówienia odpowiedź na poprzednie

mo

żna wykasować. Co zrobić gdy klient wysyła ostatnie

zamówienie i nie informuje serwera

że się kończy? – limit czasowy

rejestru odpowiedzi.

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 6

Architektura klient serwer

Rodzaje architektury klient serwer:

1. Serwer po

łączeniowy / bezpołączeniowy

2. Serwer sekwencyjny / wspó

łbieżny

3. Serwer stanowy / bezstanowy

Serwer bezpo

łączeniowy / połączeniowy

Aplikacja klienta

send(...)

Aplikacja serwera

receive(...)

receive(...)

send(...)

Serwer bezpo

łączeniowy

Aplikacja klienta

Send(...)

Aplikacja serwera

connect(...)

Receive(...)

close

Receive(...)

Send(...)

close

Rejestracja

accept(...)

Rozlączenie

SIGIO
SIGURG
SIGPIPE

Handler

Serwer po

łączeniowy

Powinny by

ć obsługiwane dwa wątki sterowania:

1. Normalny
2. Obs

ługi zdarzeń związanych ze zmianą stanu połączenia

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 7

Architektura klient serwer

Serwer iteracyjny / współbieżny

Serwer iteracyjny
Serwer iteracyjny – serwer zdolny do obs

ługi jednego zlecenia

klienta w danym odcinku czasu

t – czas obs

ługi jednego zlecenia

N – liczba zlece

ń klientów

T - Czas obs

ługi N zleceń

T = t * N

Klient 1

Serwer

Zlecenie 1

Zlecenie 2

Klient 2

T1

T2

Dzia

łanie serwera iteracyjnego

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 8

Architektura klient serwer

Serwer wspó

łbieżny

Serwer wspó

łbieżny – serwer zdolny do współbieżnej obsługi

zlece

ń wielu klientów. Składa się z pewnej liczby procesów lub

w

ątków realizujących zlecenia klientów.

Klient 1

Serwer

Odpowiedz 1

Zlecenie 1

Odpowiedź 2

Zlecenie 2

Klient 2

T1

T2

W1

W2

Wątek 1 Wątek 2

Dzia

łanie serwera współbieżnego

T = t

K1

KN

Klienci

Wykonawca

N

Wykonawca

1

Zarządca

Serwer wspó

łbieżny typu zarządca / wykonawca

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 9

Architektura klient serwer

Przykład – serwer współbieżny typu zarządca / wykonawca w
systemie QNX

Serwer wspó

łbieżny ze stałą liczbą procesów realizujących

zlecenia.

Serwer wspó

łbieżny składa się z:

1. Procesu g

łównego SG przyjmującego zlecenia i

synchronizuj

ącego działanie innych procesów.

2. Procesów S1,…Sl realizuj

ących usługi klientów K1…Kn. Każdy

z procesów realizuj

ących usługi może być wykonywany na

oddzielnych maszynach.

Klienci

Proces

SG

S6

K1

KN

S2

S7

Wolne procesy

kolejka SQ

K1 K5

K3

Nieobsluzeni klienci

kolejka KQ

S1

Sl

Procesy

wykonawcze

Proces przyjmujący

zgoszenia

Struktura serwera wspó

łbieżnego

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 10

Architektura klient serwer

Zasada dzia

łania serwera współbieżnego:

1. Proces g

łówny serwera tworzy L procesów usługowych (być

mo

że na oddzielnych maszynach).

2. Procesy us

ługowe wykonują operację MsgSend do procesu

g

łównego i są zablokowane na operacji MsgReply gdyż nie

udzielono im odpowiedzi. Ich identyfikatory PID s

ą umieszczone

w kolejce SQ – wolnych procesów us

ługowych.

3. Gdy przychodz

ą zlecenia od klientów to odbiera je proces

g

łówny SG. Wykonuje on następujące działania:

- Z kolejki SQ pobierany jest wolny proces us

ługowy Sj i

przydziela mu si

ę do obsługi klienta Ki.

- Proces us

ługowy odblokowuje się udzielając mu odpowiedzi

MsgReply . W parametrach odpowiedzi przekazywane s

ą

parametry zlecenia.

- PID nie obs

łużonego klienta umieszcza się w kolejce KQ.

4. Gdy do procesu SG przychodzi komunikat od procesu

us

ługowego Sj że zakończył on obsługę klienta Ki to:

- PID procesu obs

ługowego Sj dodawany jest do kolejki SQ.

- PID procesu klienta Ki usuwany jest z kolejki KQ.
- Wynik dostarczony przez proces us

ługowy odbierany jest z

bufora funkcji MsgReceive.

- Procesowi klienta Ki udzielana jest odpowied

ź za pomocą

funkcji MsgReply a wyniki przekazywane jako parametry .

- Proces klienta Ki jest odblokowany na czym ko

ńczy się jego

obs

ługa.

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 11

Architektura klient serwer

pid_t SQ[MAX_PROC]; //Kolejka procesów usługowych
pid_t KQ[MAX_KLI]; //Kolejka nieobsłużonych klientów

main(void) {
pid_t pid;

// Utworzenie procesów usługowych S1,S2… ------
for(j=0;j<MAX_PROC;j++) {

// Utwórz proces wykonawczy Sj
pid = spawnl(P_NOWAIT,”proc”, ”proc”,atoi(j),NULL);
Umieść proces Sj w kolejce SQ;

}

do { // Pętla główna ------------------------------
pid = MsgReceive(0,&msg,sizeof(msg),…);
// Komunikaty od procesów usługowych -----------

if( Komunikat od procesu Sj) {
if(Realizacja zlecenia Ki przez Sj) {
Odblokuj klienta Ki i usuń do Ki z KQ;

MsgReply(Ki,…);
}
Umieść proces Sj w kolejce SQ;

}
// Komunikaty od procesów Klientów ------------

if( Komunikat od klienta Ki) {
Pobierz z SQ proces Sj;
Przekaż mu zlecenie od Ki;

Odblokuj serwer Sj – Reply(Sj,…);
Wstaw Ki do KQ;
}

} while(……);
}

Szkic kodu serwera wspó

łbieżnego

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 12

Architektura klient serwer

Serwer bezstanowy / stanowy

Serwer bezstanowy (ang. stateless server) - serwer, który nie
przechowuje

żadnych informacji o kliencie. Zwracając się do

serwera bezstanowego, klient musi ka

żdorazowo określić komplet

informacji dotycz

ących usługi.

Serwer stanowy (ang. Stateful server) – serwer przechowuje
informacje o kliencie. S

ą dwa typy informacji przechowywanej

przez serwer:
- Informacja globalna
- Informacja o stanie sesji

Informacja globalna – informacja przechowywana przez ca

ły okres

aktywno

ści serwera.

Przyk

ład – protokół licznikowy

Gdy dowolny klient zwraca si

ę do serwera to licznik zwiększany

jest o jeden. Warto

ść tego licznika zwracana jest do klienta.

Informacja o stanie sesji (

ang. Session state information)

Dla pewnych protoko

łów i aplikacji serwer musi przechowywać

pewne informacje o stanie sesji.

Informacja o stanie sesji obejmuje:

1. Nazw

ę pliku,

2. bie

żący numer bloku,

3. rodzaj akcji (pobieranie, wysy

łanie)

W serwerze bezstanowym informacja o stanie sesji
przechowywana jest u klienta.

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 13

Architektura klient serwer

Nazwa pliku

Serwer FTP

Klient FTP

Identyfikator pliku - ID

Numer bloku NR

Identyfikator pliku - ID

Wyslij(ID, blok 0)

Dane z pliku ID bloku 0

Wyslij( ID, blok 1)

Dane z pliku ID bloku 1

Protokó

ł FTP – serwer bezstanowy

W serwerze stanowym informacja o stanie sesji przechowywana
jest w serwerze.

Nazwa pliku

Serwer FTP

Klient FTP

ID1

NR1

wynik

Wyslij następny blok

Dane z pliku ID bloku 0

Wyslij następny blok

Dane z pliku ID bloku 1

ID2

NR2

Numer bloku

Ident. pliku

klient 1

klient 2

Protokó

ł FTP – serwer stanowy

PDF created with pdfFactory trial version

www.pdffactory.com

J. U

łasiewicz Programowanie aplikacji współbieżnych i rozproszonych 14

Architektura klient serwer

Przyk

ład - serwery usług systemu QNX6 Neutrino

System QNX sk

łada się z mikrojądra i zbioru serwerów rożnych

us

ług zwanych administratorami. Pewne serwery mogą być

klientami innych serwerów.

PA1

PA2

PAn

Procesy aplikacyjne

Administrator

plików

szeregowanie

wątków

IPC komunikacja

międzyprocesowe

timery

obsługa przerwań

synchroni-

zacja

MIKROJĄDRO

przerwania

Administrator

sieci

Administrator

procesów

procnto

Administratory
systemowe

procnto

Zarz

ądzanie pamięcią, wątkami i

procesami

devb-eide

Proces obs

ługi dysków stałych typu IDE

devb-fdc

Proces obs

ługi stacji dyskietek

devc-par

Proces obs

ługi portu równoległego

devc-ser8250 Proces obsługi portu szeregowego

RS232

devc-con

Proces obs

ługi konsoli

io-net

Ogólny administrator sieci

io-graphics

Proces obs

ługi karty graficznej

Photon

Proces interfejsu graficznego

Tabela 6-1 Ważniejsze procesy systemowe systemu QNX6

Neutrino

PDF created with pdfFactory trial version

www.pdffactory.com