Cliente/ Servidor

▶ Q uais os problem as ?
▶ – Baseado e m E/S
▶ – Erro propagado e m Sistemas Distribuídos
▶ – Difícil implementação
▶ – Não são amigáveis – foge da programação
convencional (estruturado, OO, etc.)
▶ – Diferente da proposta de Sistemas
Distribuídos
▶ Parecer u m Sistema Centralizado

1
 Conceito
▶ Trans parência

▶ – Chamada de procedimentos que estão em

outras máquinas
– Transferência de parâmetros para execução
▶

remota
▶ – Retorno das informações para o processo

“chamador”
▶ – Conhecido como chamada remota de
procedimento ou RPC
2
 Conceito

3
 Problemas

▶ E spaços de endereçam ento diferentes

(máquinas diferentes)
▶ Arquitetura diferentes, interferindo nos

tipos de dados
▶ Problem as no s ervidor
▶ Problem as no cliente

4
 Características

▶ Funcionam ento
▶ – Cham ada ao s tub do cliente
▶ Versão no cliente res pons ável por
iniciar a RPC
▶ Es ta versão recebe os parâm etros do
procedimento e empacota para envio ao
servidor, usando send
▶ Após o envio, fica bloqueado (em
receive) esperando a resposta do
5 servidor
 Características

▶ Funcionamento
▶ – No servidor, existe o stub do servidor
▶ Serviço de S O responsável por receber u m
pacote de informações remotas
▶ Verifica para qual s erviço, e executa de acordo
com os parâmetros recebidos
▶ Envia de volta ao cliente, através de send

6
 Características
▶ Funcionamento

▶–Para o S O (kernel), o env io e

recebimento de m e n s ag e n s é
transparente, ou seja, ele não sabe
que é u m a RPC
▶–Portanto, dev e existir um proces so
específico para o tratamento de RPCs

7
 Características

8
 Características
1. procedimento chama o stub de cliente (forma normal)
2. stub constrói a m e n s a g e m e faz u m send (trap ao kernel)
3. o kernel envia a m e n s a g e m para a máquina remota
4. o kernel remoto entrega a m e n s a g e m ao stub do servidor
5. o stub desempacota a m e n s a g e m e chama o “servidor”
6. o servidor realiza a tarefa e retorna ao stub
7. o stub do servidor empacota o retorno e faz u m send para
o cliente
8. o kernel remoto envia a m e n s a g e m ao kernel do cliente
9. o kernel do cliente entrega a m e n s a g e m ao stub do
cliente
10. o stub desempacota a m e n s a g e m e entrega ao cliente
9
 Parâmetros
▶ Pas s agem por v alor
▶ – Cópia do valor do parâmetro, mantendo
o original
▶ Pas s agem por referência
▶ – U so de endereço de m em ória
▶ Pas s agem por
cópia/res taura
▶ – Copia o valor, e após sua modificação,
sobrescreve o valor original
10
 Parâmetros

▶ Problem as com Arquitetura

▶ – EB C D IC v s . A S CII
Am erican S tandard Code for
▶

Inform ation Interchange

▶ E xtended Binary Coded D ecim al

Interchang e Code
▶ • M ainframe s e PCs

▶ – Little Endian v s . Big Endian

▶ • I3 8 6 e S PARC-Sun
▶– Com plem ento de
11
2 v s . C om plem ento
 Parâmetros
▶ S o luções
▶– O conhecim ento do procedim ento, por
a mb os os lados – cliente/servidor –
permite resolver o impasse
▶– D efinição de um padrão de com um
acordo
▶ • D es em penho?
▶ – Utilização de 1 bit para identificação
do formato do padrão
12
 Parâmetros
▶ Ponteiros
▶– C ópia do endereço?
▶ – Utilização de técnicas cópia/restaura
▶ • Envio do buffer da m ens a g em , a partir
do tamanho
▶– Aum ento do dese m penho
▶ • D iminuição de um envio de m ens age m ,
baseado no tipo do procedimento
▶ N ão existe va riáv eis “globais”
13
 Binding Dinâmico

▶ Ligação dinâmica entre

Cliente/Servidor
▶Es pecificação form al
de um S e rvidor
▶– IN: v alores de EN TRAD A
no s erv idor
▶– O UT: v alores de S AÍD A
do se rv idor
▶1–4 IN O UT: entrada e sa ída
 Binding Dinâmico

▶ Es s a especificação é utilizada para o

processo de linkedição do compilador
▶– O arquiv o-objeto se rá linkado ao
programa cliente ou servidor
▶– S tub do cliente e do s erv idor
▶ É necess ário con struir o código
referente a esses procedimentos
15
 Binding Dinâmico

▶ S erv idor
▶ – Ao s er executado, av is a ao program a
de registro (binder) que está ativo:
registro do serviço
▶ C liente
▶ – Q uando um procedim ento é cham ado,
este se liga ao servidor, utilizando
o binder como intermediário
16
 Binding Dinâmico

▶ Vantag ens
▶ – D iv erso s s erv idores com a m esm a “interface”
▶ – Servidores que falham são automaticamente
“desregistrados”
▶ – Autenticação de usu ários/clientes
▶ D es va ntag ens
▶ – O v erhead de cons ulta ao binder
▶ – Diversos binders necessita de atualização
entre eles
17
 Falhas

▶ A concepção do RPC é deixar a programação

transparente, mas:
▶ – Cliente não acha o servidor
▶ – A m e n s a g e m do cliente para o servidor foi
perdida
▶ – A m e n s a g e m do servidor para o cliente foi
perdida
▶ – O servidor sai do ar após receber u m a
solicitação
▶ – O cliente sai do ar após ter enviado u m a
solicitação
18
 Falhas

▶ Cliente não acha o s ervidor

▶ – O servidor está fora do ar
▶ – Versões diferentes de stubs
▶ – Retornos de variáveis
“inválidas”: e.g. -1
▶ – Criação de exceções
▶ – Perda da transparência

19
 Falhas

▶ A m e n s agem do cliente para

o servidor foi perdida
▶ – Lim ite de tem po de es pera
(tim eout)
▶ – Reenvio em kernel
▶ – Retorno de erro, após div ersas

tentativas
20
 Falhas

▶ A m e n s ag e m do servidor para o cliente foi

perdida
▶ – Reenv io da s olicitação (? )
▶ potência de execução
▶ – O kernel do cliente m antém um a s eqüência
de
números de envio
▶ – A cada m ens ag em, o s erv idor v erifica s e o
número deste kernel já não foi executado
▶ 2–1 Bit de sinalização: original ou
 Falhas

▶ O servidor sai do ar após receber um a

solicitação
▶ – Es pera e reenvia / ache novo servidor
▶ – Desiste e comunica a falha
▶ – Nada é garantido (implementação)

▶ As falhas até o m o m ento não s ão

distinguíveis para u m Cliente
22
 Falhas

▶ O cliente sai do ar após ter enviado um a

solicitação
▶ – Processamento “órfão”
▶ – Gasto de tempo do servidor
▶ – Soluções
▶ Extermínio
▶ Reencarnação
▶ Reencarnação branda
▶ Expiração (quantum T)
23
 Falhas

▶ Extermínio
▶ – Eliminar todos os órfãos
▶ – Falha na rede??
▶ – Problema: encadeamento de falhas (servidor pode ter
sido cliente e m um a RPC)
▶ Reencarnação
▶ – Dividir o tempo e m “épocas”
▶ – Nova chamada  nova época
▶ – Falha na rede  impossível encontrar o órfão 
facilmente detectado depois (necessita nova
época)
24
 Falhas

▶ Reencarnação Branda
▶ – Verificar se há processamento de
épocas anteriores antes de eliminar
órfão
▶ – Servidor tenta encontrar cliente
▶ S e cliente não existir, elimina o órfão
▶ Expiração
▶ – Tempo máximo para servidor executar
serviço
▶ 2–5 Problema: mensurar o quantum
 CORBA

▶ C o m m o n Object Request Broker Architecture

▶ troca de dados entre sistemas distribuídos heterogêneos
▶ – Padrão aberto, definido pela O M G
▶ – Aplicável a Orientação a Objetos
▶ – Independente de linguagem (cliente/servidor)
▶ – Chamada remota através de O R B s (Object
Request Broker) locais: de stub-cliente para
skeleton-servidor
▶ – Definição da interface de chamada através da
IDL
2–6 Interface Definition Language
 DCOM

▶ D is tributed Com ponent O bject M odel

▶ – Interação distribuída de componentes
▶– Definido pela Microsoft para O O e
Componentes
▶ – A s interfaces do objetos podem ser definidas
e m várias linguagens de programação e e m
diversas plataformas
▶ – Stub do cliente (proxy) se comunica com o stub
do servidor, que requisita o objeto D C O M

27
 RM
I
▶ Remote M ethod Inv ocation
▶ – RPC da linguagem Java
▶ – Orientação a Objetos
▶ – 3 camadas
▶ Stub/Skeleton: é invocado primeiro, recebendo
objetos e serializando-os (bytes)
▶ RRL – Remote Reference Layer: cada lado possui
a sua, responsável por montar a m e ns a ge m
de envio/resposta entre cliente/servidor
▶ Transporte: envio das informações via rede
28