Sistemas Distribuídos

Carlos A. G. Ferraz

DI/UFPE

Aula 06

Tópicos O Modelo Cliente/Servidor (cont.) RPC

O Modelo Cliente/Servidor (cont.)

Servidores “Gordos”: fazem maior parte das operações

Exemplos: Servidores de transação Servidores de objetos Servidores de groupware

O Modelo Cliente/Servidor (cont.)

Clientes “Gordos” / Servidores “Magros”

Exemplos: Servidores de arquivos Servidores de banco de dados

O Modelo Cliente/Servidor (cont.)

Endereçamento: Máquina.processo Broadcasting Servidor de nomes

Cliente/Servidor: EndereçamentoMáquina.processo

cliente servidor1

2

1. Pedido para 243.02. Resposta para 199.0

Cliente/Servidor: EndereçamentoBroadcasting

cliente servidor3

4

1. Broadcast2. “Here I am”3. Pedido4. Resposta

1 2

Cliente/Servidor: EndereçamentoServidor de nomes

clienteservidor

de nomes

1

2

1. Procura2. Resposta do servidor de nomes3. Pedido4. Resposta

servidor4

3

Cliente/Servidor: Endereçamento

Problemas: Máquina.processo: não

transparente Broadcasting: sobrecarga no

sistema Servidor de nomes: centralizado

O Modelo Cliente/Servidor (cont.)

Primitivas: Bloqueantes (síncronas) Não-bloqueantes (assíncronas)

Cliente/Servidor: Primitivas(a) Blocking send

parada durante transmissão da mensagem

(b) Nonblocking send com cópia perda de tempo para

a cópia tx em background

(c) Nonblocking send programação mais

difícil

cliente

envio da mensagem

executando executandobloqueado

envio da mensagem

executando executandobloq.

msgcopiadap/ buffer

(a)

(b)

Cliente/Servidor: Primitivas

A vantagem de melhor desempenho de primitivas não-bloqueantes pode ser desfeita pela seguinte desvantagem: o sender não pode modificar o buffer de mensagem até que a mensagem seja enviada - seria um grande erro gravar sobre a mensagem

O pior é o processo nunca poder saber quando pode reusar o buffer -> solução por timeout

Cliente/Servidor: Primitivas

Assim como send pode ser bloqueante ou não-bloqueante, receive também pode

Quase sempre a versão bloqueante de receive é mais simples e preferida

Cliente/Servidor: PrimitivasPassagem de mensagem: Sem buffer: o servidor tem que

chamar receive antes que o cliente chame outro send

Com buffer: o servidor, ao chamar receive, retira uma mensagem do “mailbox” ou bloqueia se não houver mensagem no buffer

Cliente/Servidor: PrimitivasPrimitivas confiáveis versus não-

confiáveis: Não-confiáveis: não há garantias

de entregaEx: correio

Cliente/Servidor: PrimitivasPrimitivas confiáveis:

núcleo núcleo núcleo núcleo

cliente servidor cliente servidor1

2

34

1

2

3

1. Request (cliente-servidor)2. ACK (núcleo-núcleo)3. Reply (servidor-cliente)4. ACK (núcleo-núcleo)

1. Request (cliente-servidor)2. Reply (servidor-cliente)4. ACK (núcleo-núcleo)

RPC

Protocolo Pedido-Resposta Integração relativamente

transparente com linguagem de programação

RPC (cont.)

Evitar passagem de endereço e variáveis globais

Novos tipos de erros em função da distribuição Incl.: tratamento de exceções

(ex.: atraso de comunicação -> timeout)

RPC (cont.)

Clientes acessam serviços fazendo RPCs para operações nas interfaces de servidores

Stubs: transparência de acesso tratamento de algumas

exceções no local marshalling unmarshalling

RPC (cont.)

Binder Ligação dinâmica Transparência de localização

RPC (cont.)

Sun x ANSA IDL: Sun só permite um

argumento e um resultado ANSA fornece nomes de

interface, SUN fornece números de programa e versão

Concorrência: ANSA fornece um pacote de threads; SunOS não, Solaris sim.

RPC: Sun x ANSA (cont.) Semântica de chamada: ao-

menos-uma-vez (Sun), no-máximo-uma-vez (ANSA)

Limitações no tamanho de argumentos e resultados: sim (Sun), não (ANSA)

Transparência: Sun não fornece transparência de localização

RPC (cont.)

Considerações finais: RPC assíncrono Comunicação em grupo