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