Sistemas Distribuídos 05/04/2017 Sistemas Distribuídos Carlos A. G. Ferraz DI/UFPE Aula 06

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

O Modelo Cliente/Servidor (cont.) 05/04/2017 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.) 05/04/2017 O Modelo Cliente/Servidor (cont.) Clientes “Gordos” / Servidores “Magros” Exemplos: Servidores de arquivos Servidores de banco de dados

O Modelo Cliente/Servidor (cont.) 05/04/2017 O Modelo Cliente/Servidor (cont.) Endereçamento: Máquina.processo Broadcasting Servidor de nomes

Cliente/Servidor: Endereçamento 05/04/2017 Cliente/Servidor: Endereçamento Máquina.processo 1 cliente servidor 2 1. Pedido para 243.0 2. Resposta para 199.0

Cliente/Servidor: Endereçamento 05/04/2017 Cliente/Servidor: Endereçamento Broadcasting 3 cliente servidor 4 1 2 1. Broadcast 2. “Here I am” 3. Pedido 4. Resposta

Cliente/Servidor: Endereçamento 05/04/2017 Cliente/Servidor: Endereçamento Servidor de nomes 4 1 servidor cliente servidor de nomes 3 2 1. Procura 2. Resposta do servidor de nomes 3. Pedido 4. Resposta

Cliente/Servidor: Endereçamento 05/04/2017 Cliente/Servidor: Endereçamento Problemas: Máquina.processo: não transparente Broadcasting: sobrecarga no sistema Servidor de nomes: centralizado

O Modelo Cliente/Servidor (cont.) 05/04/2017 O Modelo Cliente/Servidor (cont.) Primitivas: Bloqueantes (síncronas) Não-bloqueantes (assíncronas)

Cliente/Servidor: Primitivas 05/04/2017 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 (a) executando bloqueado executando envio da mensagem (b) executando bloq. executando msg copiada p/ buffer envio da mensagem

Cliente/Servidor: Primitivas 05/04/2017 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 05/04/2017 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: Primitivas 05/04/2017 Cliente/Servidor: Primitivas Passagem 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: Primitivas 05/04/2017 Cliente/Servidor: Primitivas Primitivas confiáveis versus não-confiáveis: Não-confiáveis: não há garantias de entrega Ex: correio

Cliente/Servidor: Primitivas 05/04/2017 Cliente/Servidor: Primitivas Primitivas confiáveis: 1 1 núcleo núcleo núcleo núcleo cliente servidor cliente servidor 3 2 4 3 2 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 05/04/2017 RPC Protocolo Pedido-Resposta Integração relativamente transparente com linguagem de programação

RPC (cont.) Evitar passagem de endereço e variáveis globais 05/04/2017 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)

05/04/2017 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 05/04/2017 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 05/04/2017 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.

05/04/2017 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 05/04/2017 RPC (cont.) Considerações finais: RPC assíncrono Comunicação em grupo