Chapter 16 Client/Server Computing

Client/Server Computing,
Middleware, RPC
Slides are mainly taken from «Operating Systems: Internals and
Design Principles”, 8/E William Stallings (Chapter 16).
Sistemi di Calcolo (II semestre) – Roberto Baldoni
Client/Server Computing
• Client machines are generally single-user
PCs or workstations that provide a highly
user-friendly interface to the end user
• Each server provides a set of shared
services to the clients
• The server enables many clients to share
access to the same database and enables
the use of a high-performance computer
system to manage the database
Client/Server Terminology
Generic Client/Server
Environment
Client/Server Applications
• Basic software is an operating system
running on the hardware platform
• Platforms and the operating systems of
client and server may differ
• These lower-level differences are
irrelevant as long as a client and server
share the same communications protocols
and support the same applications
Generic Client/Server
Architecture
Client/Server Applications
• Bulk of applications software executes on
the server
• Application logic is located at the client
• Presentation services in the client
Database Applications
• The server is a database server
• Interaction between client and server is in
the form of transactions
– the client makes a database request and
receives a database response
• Server is responsible for maintaining the
database
Client/Server Architecture for
Database Applications
Client/Server Database Usage
Client/Server Database Usage
Classes of Client/Server
Applications
• Host-based processing
– Not true client/server computing
– Traditional mainframe environment
Classes of Client/Server
Applications
• Server-based processing
– Server does all the processing
– Client provides a graphical user interface
Classes of Client/Server
Applications
• Client-based processing
– All application processing done at the client
– Data validation routines and other database
logic functions are done at the server
Classes of Client/Server
Applications
• Cooperative processing
– Application processing is performed in an
optimized fashion
– Complex to set up and maintain
Three-tier Client/Server
Architecture
• Application software distributed among
three types of machines
– User machine
• Thin client
– Middle-tier server
• Gateway
• Convert protocols
• Merge/integrate results from different data sources
– Backend server
Three-tier Client/Server
Architecture
Middleware
• Set of tools that provide
a uniform means and
style of access to
system resources
across all platforms
• Enable programmers to
build applications that
look and feel the same
• Enable programmers to
use the same method
to access data
MIDDLEWARE
Il middleware è un software di connessione che consiste di un
insieme di servizi e/o di ambienti di sviluppo di applicazioni
distribuite che permettono a più entità (processi, oggetti ecc.),
residenti su uno o più elaboratori, di interagire attraverso una rete
di interconnessione a dispetto di differenze nei protocolli di
comunicazione, architetture dei sistemi locali, sistemi operativi
ecc..
Role of Middleware in
Client/Server Architecture
MIDDLEWARE
Applicazioni Distribuite
Ambiente di
sviluppo
applicativo
Servizi di configurazione
ed amministrazione del
sistema
Servizi di
astrazione e
cooperazione
Servizi di
comunicazione
Infrastruttura di comunicazione (esempio TCP/IP)
Middleware: Servizi
Servizio di Comunicazione. Questo servizio offre una API
che permette all’applicazione distribuita di scambiarsi
informazioni tra le sue componenti residenti su elaboratori
con caratteristiche hardware e/o software differenti. Lo
scopo di questo servizio è di nascondere le disomogeneità
dovute alla rappresentazione dei dati usata dai vari
elaboratori, ai sistemi operativi locali ed a differenti reti che
costituiscono
l’infrastruttura
della
piattaforma.
Per
comunicazioni si intendono diversi paradigmi di interazione
che vanno dalle RPC, alla messaggistica applicativa al
modello publish/subscribe, al mantenimento di discipline
diverse da quella FIFO (esempio causal order, total order)
Middleware: Servizi
Servizi
di astrazione e cooperazione. Questi servizi
rappresentano il cuore del middleware e comprendono tra gli
altri:
 Directory Service (o servizio di “pagine gialle”) che provvede alla
identificazione ed alla localizzazione di entità. Questo servizio
rende le applicazioni al di sopra del middleware indipendenti dal
sottosistema di instradamento dei messaggi.
 Security Service che è finalizzato alla protezione di elementi
critici come dati e servizi applicativi attraverso tecniche come
autenticazione, autorizzazione e criptografia.
 Time Service il quale assicura che tutti i clock interni tra client e
server siano sincronizzati entro un accettabile livello di varianza
Middleware: Servizi
Servizi per le applicazioni. Questi servizi permettono ad una
applicazione di avere un accesso diretto o con la rete o con i servizi
offerti dal middleware. Ad esempio un servizio orientato alle
transazioni, all’interno di un middleware, può fornire un supporto per
accesso transazionale a basi di dati eterogenee.
Servizi di amministrazione del sistema.
– monitoring
– configurazione
– pianificazione.
Ambiente di sviluppo applicativo.
– strumenti di aiuto alla scrittura
– debugging
– caricamento di applicazioni distribuite sia ad oggetti che basate su processi.
– (Interface Definition Language) per l’interconnessione tra moduli scritti in
diversi linguaggi di programmazione e residenti su elaboratori distinti.
Middleware: Obiettivi
• interoperabilità e connettività per
applicazioni distribuite su piattaforme
eterogenee
• collante delle applicazioni utilizzate
all’interno di una azienda.
Sistema
Informativo A
Sistema
Informativo C
Middleware: Problemi
Un middleware molto spesso offre più servizi
di quelli di cui una applicazione ha
realmente bisogno, quindi si pone un
problema progettuale (scegliere il migliore
middleware in rapporto ai servizi richiesti
da una applicazione) e di prestazioni (il
middleware scelto non deve appesantire
troppo il sistema locale o la rete di
interconnessione).
Configurabilità
Distributed Message Passing
Message-Oriented Middleware
• Classe specifica di middleware che supporta
scambio di messaggi in un ambiente di
applicazioni distribuite che sono message-driven
ovvero l’evoluzione dell’applicazione è scandita
dalla trasmissione e ricezione di messaggi.
• Messaggeria asincrona (il server non deve
essere necessariamente in funzione):
– Code di messaggi
– Publish/Subscribe
Basic Message-Passing
Primitives
Code di Messaggi
• I messaggi inviati dai client ad un server
rimangono immagazzinati in una coda fino a
che il server non li preleva dalla coda stessa.
• Facilita:
– Implementazione di politiche di priorità
– Bilanciamento del carico (+ server prelevano
messaggi dalla stessa coda)
– Gestione di applicazioni tolleranti ai guasti
– Miglioramento delle prestazioni (client non-bloccante)
Publish/Subscribe
• message bus architecture
• Sul bus si poggiano due entità i publisher (coloro che
inviano/pubblicano i messaggi) e i subscriber (coloro
che ricevono i messaggi).
• Il publisher pubblica un messaggio con un certo
subject (es. “/calcio/italia/squadre/lazio”) e questo
messaggio raggiunge tutti i subscriber che si sono
abbonati a tale subject.
• Un publisher non è costretto a conoscere tutti i suoi
subscriber e viceversa.
• l’insieme dei publisher e dei subscriber di un certo
soggetto può cambiare dinamicamente
Publish/Subscribe
•
Un processo può essere publisher di diversi soggetti e
subscriber di altri.
• Il software che implementa tale paradigma di
comunicazione deve cercare di non inondare la rete con
copie dello stesso messaggio.
• I soggetti formano uno spazio unico e gerarchico dei nomi
(come in un file system)
• Il message bus consente diversi livelli di gestione dalla
consegna con certificato alla consegna non-affidabile.
• Se un subscriber e’ attivo all’arrivo di un messaggio viene
attivata una upcall.
• Se non e’ attivo viene immagazzinato il messaggio all’interno
di un elemento dell’architettura pub/sub che provvederà a
consegnarlo non appena il subscriber sarà attivo
Mqseries (IBM)
• MQseries è fondato su un sistema di code di
messaggi.
• Mqseries è un middleware basato su una serie di
oggetti. Queue managers, Queues, Namelists,
Distribution list.
• L’elemento chiave in Mqseries è il queue manager
che gestisce l’invio, la ricezione e l’accodamento dei
messaggi per conto delle applicazioni attraverso la
Message Queue Interface (MQI).
• Le code vengono create/rimosse dalle applicazioni
attraverso opportune chiamate al queue manager.
• Esistono due tipi di code, quelle locali (gestite dal
queue manager a cui è connessa l’applicazione) e
quelle remote
Mqseries (IBM)
• All’interno di un queue manager le code possono
essere di due tipi temporanee e persistenti.
• I nomi delle code definite dagli utenti vengono
mantenute in un deposito chiamato namelist che
gestisce l’associazione nome logico-nome fisico.
•
Quindi quando un utente vuole accedere ad una
coda conoscendo il suo indirizzo logico, l’ indirizzo
fisico viene ritrovato attraverso la namelist.
• Una applicazione può inviare lo stesso messaggio in
più code attraverso il meccanismo di distribution list.
(emulazione del multicast)
Tib/Redezvous
• Tib/Rendezvous è
basato
su
un
servizio
di
comunicazione
publish/subscribe
molto sofisticato.
Tib/Redezvous
• Tib/rendezvous fornisce due livelli di affidabilità sulle
consegne dei messaggi: consegna affidabile e
consegna certificata
• La consegna affidabile notifica un rapporto al al
publisher in caso di perdita di un messaggio (senza
indicare il messaggio).
• Nel caso di consegna certificata il rapporto indica il
messaggio perso ed i subscriber che non lo hanno
ricevuto.
• I messaggi inviati con consegna certificata sono
immagazzinati nella memoria di massa del publisher
in modo da essere prelevati successivamente in caso
di guasti.
Tib/Redezvous
• L’architettura software di TIB/rendezvous è formata da una
serie di componenti:
– Una libreria TIB/rendezvous che permette all’applicazione di usare
l’API di TIB/Rendezvous.
– Un processo nascosto (demone) TIB/Rendezvous che riceve le
chiamate dalla libreria e gestisce tutte le comunicazioni tra i
processi applicativi (sia remoti che residenti sulla stessa
macchina), la frammentazione ed il reassemblaggio dei pacchetti
ed il filtraggio basato sul subject dei messaggi.
– Un
processo
nascosto
instradatrore
dei
messaggi
(TIB/Rendezvous Deamon) che permette di non inviare messaggi
in sottoreti dove non è presente nessun subscriber per quel
soggetto (altrimenti le varie sottoreti sarebbero intasate di
messaggi!).
– I cambiamenti delle tavole dei suscriber vengono notificati ai vari
TIB/Rendezvous Deamon attraverso protocolli periodici di scambio
di messaggi.
Tib/Redezvous
• L’architettura software di TIB/rendezvous è formata da una
serie di componenti:
–  Cache di Messaggi (Message Cache) immagazzina messaggi
che transitano sulla rete riguardanti un certo subject. Quando un
processo esegue il subscribe per un certo soggetto, se è attiva la
message cache per quel soggetto, egli riceverà tutti i messaggi
presenti nella cache. Questo permette ad un processo di ricevere
messaggi anche quando non è in esecuzione e di gestire politiche
di tolleranza ai guasti.
Remote Procedure Calls
Distributed Message Passing
Remote Procedure Calls
• Allow programs on different machines to
interact using simple procedure call/return
semantics
• Widely accepted
• Standardized
– Client and server modules can be moved
among computers and operating systems
easily
Remote Procedure Call
Mechanism
Remote Procedure Call
Una Chiamata a Procedure Remota (RPC)
trasforma l’interazione Client/Server in una
chiamata a procedura, simile a quella locale,
nascondendo al programmatore la maggiore
parte dei meccanismi implementativi che la
compongono, come:
•
•
•
l’interscambio di messaggi,
la localizzazione del server che fornisce il servizio
le possibili differenti rappresentazioni dei dati delle
macchine coinvolte nell’interazione.
RPC
Questo mascheramento avviene in quattro fasi:
•
•
•
•
A tempo di scrittura del codice. Le RPC usate/fornite dovranno essere
dichiarate esplicitamente dal programmatore attraverso import/export delle
definizioni delle interfacce.
A tempo di esecuzione. Ogni macchina su cui è in esecuzione un
programma client e/o server dovrà avere un supporto a tempo si esecuzione
per le RPC (RPC run-time support) in grado di eseguire alcune operazioni
delle RPC come ad esempio la localizzazione del server o la registrazione di
un nuovo servizio offerto da un nuovo server.
A tempo di compilazione. Durante la compilazione per ogni chiamata a
procedura remota vengono agganciate linee di codice al programma originario
(stub) che permettono operazioni standard sui dati (impacchettamento e
codifica universalmente riconosciuta) e le chiamate al RPC run-time support;
A tempo di collegamento. Durante il collegamento il programma sorgente
viene collegato al RPC run-time support per ottenere il codice eseguibile.
RPC Timeline
Client
Server
Blocked
Blocked
Computing
Blocked
Meccanismi per RPC
• Un protocollo che nasconde le insidie della
rete (perdita di pacchetti e riordinamento
dei messaggi)
• Un meccanismo per impacchettare gli
argomenti dal lato chiamante e per
spacchettarli dal lato chiamato
Risultati
Impacchetta
i risultati
Server
SERVER STUB
RPC Run-Time Support
RPC Run-Time Support
Kernel del SO locale
Kernel del SO locale
Spacchetta
i parametri
CLIENT STUB
Spacchetta
i risultati
Impacchetta
i Parametri
CLIENT
Risultati
Chiamata
RPC
RPC
Server
procedure
Server program
Server stub
Interface
Specifications
RPC
generator
Header file
RPC
run-time support
Client stub
Client Main
program
Client program
Localizzazione del server
Metodo Statico. Cablare all’interno del client l’indirizzo (IP
address) del server.
Metodo Dinamico. Lo stub del client, mentre impacchetta i
dati, invia concorrentemente un broadcast richiedendo
l’indirizzo di un server in grado di eseguire la RPC
desiderata. Il supporto run-time delle RPC di ogni
machina risponde se il servizio richiesto e’ fornito da un
suo server in esecuzione.
Localizzazione del server
Name Server. Il client alla ricerca di un server consulta
una entità, name server, la quale gestisce una lista
di associazioni server-servizi.
server
stub
client
stub
4
3
2
name
server
1
Passaggio dei Parametri
Call by Reference – sconsigliato
Call by Copy/Restore. Copia
una variabile a, da parte dello stub del
client, nel pacchetto dati (come se fosse passata per valore). Il nuovo valore di
a, restituito dal server nei parametri di ritorno della RPC sarà copiato, dallo
stub del client, nella cella di memoria che contiene la variabile a.
CLIENT SIDE
begin
…..
a=0;
doppioincr(a,a);
writeln (a); ...
end
SERVER SIDE
procedure doppioincr (var x,y: integer)
begin
…….
x:= x+2;
y:= y+3;
end
Risultato: Call by ref, a=“5”
Call by copy/restore a= “2” o “3”
dipendente dall’implementazione dello stub del client
Semantica delle RPC
“At least once”
– Time-out stub del client
– Ritrasmissione
“At most once”
– Time-out stub del client
– Codice di errore di ritorno
“Exactly once”
Semantica delle RPC
“Exactly once”
Lato server
– Immagazzinare tutti i risultati delle RPC nel server (logging)
– Se arriva al server una richiesta già effettuata il risultato dovrà
essere preso dal file di log
Lato Client
– Numerare tutte le richeste dai client (sequence number)
– Numero di reincarnazione (add 1 ad ogni restart del client)
– A seguito di un guasto un client invia il numero di reincarnazione
corrente prima di cominciare ad eseguire le RPC (per uccidere le
RPC pendig della incarnazione precedente.
Sottosistema di
Comunicazione
TCP – troppo costoso in fase di connessione
UDP – nessun costo di connessione ma si deve gestire al di
sopra an protocollo per l’invio affidabile dei dati e per il
dispatching delle RPC all’interno dello stesso host
IP – dobbiamo gestire anche il multiplexing/demultiplexing dei
pacchetti all’interno del singolo host oltre ai problemi che
derivano dall’utilizzo di UDP
Gestione di pacchetti di riscontro
– Stop and wait
– Blast (tutti i pacchetti sono inviati in sequenza
ed il server invia un ack in ricezione dell’ultimo
pacchetto)
Simple RPC Stack
SELECT
CHAN
BLAST
UDP/IP
ETH
•
RCP Components (an
example)
Protocol Stack
– BLAST: fragments and reassembles large messages
– CHAN: synchronizes request and reply messages
(at most once semantic)
– SELECT: dispatches request to the correct process
• Stubs
Caller
(client)
Arguments
Return
value
Return
value
Arguments
Server
stub
Client
stub
Request
Callee
(server)
Reply
RPC
protocol
Request
Reply
RPC
protocol
Bulk Transfer (BLAST)
Sender
• Strategy
– selective
retransmission
– partial
acknowledgements
– Use of three timers
• DONE
• LAST_FRAG
• RETRY
Receiver
BLAST Details
• Sender:
– Store fragments in local memory, send all
fragments, set timer DONE
– if receive SRR, send missing fragments
and reset DONE
– If receive SRR “all fragments have been
received”, then sender frees fragments
– if timer DONE expires, free fragments (sender
gives up)
BLAST Details (cont)
• Receiver:
– when first fragment arrives, set timer LAST_FRAG
– when all fragments present, reassemble and pass up
– four exceptional conditions:
• if last fragment arrives but message not complete
– send SRR and set timer RETRY
• if timer LAST_FRAG expires
– send SRR and set timer RETRY
• if timer RETRY expires for first or second time
– send SRR and set timer RETRY
• if timer RETRY expires a third time
– give up and free partial message
BLAST (iii)
• Performance of BLAST in “nice” conditions
does not depend on how carefully timers
are set
– DONE can be a fairly large value
– RETRY is used to retransmit SRR messages.
However when things are bad, performance is
the last thing in mind.
– LAST_FRAG is used to retransmit SRR
messages when the last frag is dropped by
the network (unlikely event)
BLAST (iv)
• BLAST is persistent in asking retrasmission of missing
packets (designed to deliver large messages)
• BLAST does not guarantee anything on the delivery of the
complete message.
• Assume a message composed by two fragments and these
fragments are lost. The message will never be delivered. The
sender’s DONE timer will expires and the sender gives up
• BLAST does not have capability to resend the complete
message. This can be done by an upper layer protocol.
Question: Why?
• Answer: preferable resending only those packets that are
missing rather than having to retransmit the complete
message when one fragment is lost
BLAST Header Format
0
• MID must protect against wrap around
(all fragments of a message have the same
MID)
• TYPE = DATA or SRR
• NumFrags indicates number of fragments
• FragMask distinguishes among fragments
– if Type=DATA, identifies this fragment
– if Type=SRR, identifies missing fragments
– Max 32 fragments per message
16
31
ProtNum
MID
Length
NumFrags
Type
FragMask
Data
Request/Reply (CHAN)
• Guarantees message delivery
• Synchronizes client with server
• Supports at-most-once semantics
Client
Server
Client
Implicit Acks
Server
…
Simple case
CHAN Details
• To account opportunity of message loss,
each message (REQ, REPLY) is stored till
the ACK for it has arrived.
• Otherwise set a timer RETRANSMIT and
and resend the message each time the
timer expires
• Retrasmission implies message
duplication at recipient side:
– use message id (MID) field to distinguish
CHAN more Details
• Slow (long running) server
– client periodically sends “are you alive” probe, or
– server periodically sends “I’m alive” notice
• Want to support multiple outstanding calls
– use channel id (CID) field to distinguish
• Machines crash and reboot
– use boot id (BID) field to distinguish
• Use RETRANSMIT (client), RETRANSMIT (Server)
and PROBE (Client)
• Retransmit on a LAN can be set to 20msec and a
WAN suffer the same as TCP
Differences between TCP/IP
and CHAN/BLAST/IP
• Assume the network cannot be partitioned
forever and that both sender and receiver
do not fail
• Does CHAN/BLAST/IP protocol stack
ensure a message will be delivered to the
destination?
• Does TCP does not ensure this property?
CHAN Header Format
typedef struct {
u_short Type;
u_short CID;
int
MID;
int
BID;
int
Length;
int
ProtNum;
} ChanHdr;
/*
/*
/*
/*
/*
/*
typedef struct {
u_char
type;
u_char
status;
int
retries;
int
timeout;
XkReturn ret_val;
Msg
*request;
Msg
*reply;
Semaphore reply_sem;
int
mid;
int
bid;
} ChanState;
REQ, REP, ACK, PROBE */
unique channel id */
unique message id */
unique boot id */
length of message */
high-level protocol */
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
CLIENT or SERVER */
BUSY or IDLE */
number of retries */
timeout value */
return value */
request message */
reply message */
client semaphore */
message id */
boot id */
Dispatcher (SELECT)
• Dispatch to
appropriate
procedure
• Synchronous
counterpart to
UDP
Client
Server
Caller
Callee
xCall
xCallDemux
SELECT
SELECT
xCall
xCallDemux
CHAN
xPush
CHAN
xDemux
xPush
• Address Space for Procedures
– flat: unique id for each possible procedure
– hierarchical: program + procedure number
xDemux
Presentation Formatting
• Marshalling
(encoding) application Application
data
data into messages
• Unmarshalling
(decoding) messages Presentation
encoding
into application data
Message
• Data types we
consider
–
–
–
–
–
integers
floats
strings
arrays
structs
Application
data
Presentation
decoding
Message
…
Message
Difficulties
• Representation of base types
– floating point: IEEE 754 versus non-standard
– integer: big-endian versus little-endian
Big-endian
(2)
(17)
00000010 00010001
(126)
Little-endian 01111110
High
address
(34)
(126)
00100010
01111110
(34)
(17)
(2)
00100010
00010001
00000010
Low
address
• Different representation of integers (1,2,4 bytes)
• Data types
Taxonomy
– base types (e.g., ints, floats); must convert
– flat types (e.g., structures, arrays); must pack
– complex types (e.g., record); must linearize
Application data structure
Marshaller
• Conversion Strategy
– canonical intermediate form
– receiver-makes-right (an N x N solution)
•
Taxonomy
(cont)
How a receiver knows which type of data is in the
packet
• Tagged versus untagged data
type =
INT
len = 4
value =
417892
– Type, len, architecture
•
Untagged data
– No variable size data structures
– End-to-end presentation formatting
eXternal Data Representation
(XDR)
•
•
•
•
•
Defined by Sun for use with SunRPC
C type system
Canonical intermediate form
Untagged (except array length)
Compiled stubs
Example of encoding a string and a vector
#define MAXNAME 256;
#define MAXLIST 100;
struct item {
int
count;
char
name[MAXNAME];
int
list[MAXLIST];
};
Count
3
Name
7
J
O
H
N
S
O
N
List
3
4 97
8 32 1
2 65
Abstract Syntax Notation One (ASN-1)
•
•
•
•
•
An ISO standard
Essentially the C type system
Canonical intermediate form
Tagged
BER: Basic Encoding Rules
(tag, length, value)
• Nested representation of data structures
type
length
type
length
value
type length
value
value
INT
4
4-byte integer
Standard for SNMP
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
0
4
IntegrRep CharRep
8
16
FloatRep
– IntegerRep
• 0 = big-endian
• 1 = little-endian
– CharRep
• 0 = ASCII
• 1 = EBCDIC
– FloatRep
•
•
•
•
0 = IEEE 754
1 = VAX
2 = Cray
3 = IBM
24
Extension 1
31
Extension 2
Distributed Message Passing
Object-Oriented Mechanisms
• Clients and servers ship messages back
and forth between objects
• A client sends a request to an object
broker
• The broker calls the appropriate object
and passes along any relevant data
Object-Oriented Mechanisms
• Microsoft’s Component Object Model
(COM)
• Common Object Request Broker
Architecture (CORBA)