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
Top Related