1 Sistemas Distribuídos – Capítulo 4 - Aula 5 Aula de hoje Chamada de Procedimento Remoto - RPC Aula Passada Clusters de Servidores Migração de Código Comunicação (Cap. 4) Fundamentos

Chamada de Procedimento Remoto Birrell and Nelson (1984) “Permite a processos chamar procedimentos localizados em outras máquinas” Desenvolvedor não precisa se preocupar mais com detalhes de implementação de rede ( sockets nunca mais! ) Conceitualmente simples, mas...

Chamada de Procedimento Remoto - RPC Problemas ● Arquiteturas de duas máquinas podem ser diferentes ● Espaço de endereçamento diversos ● Passagem de parâmetros

Chamada de Procedimento Remoto - RPC A idéia fundamental é fazer com que uma chamada de procedimento remoto pareça com uma chamada local Transparência

Chamada de Procedimento Remoto - Modelo Similar ao modelo de chamadas locais de procedimentos ● Rotina que invoca o procedimento coloca os argumentos em uma área de memória bem conhecida e transfere o controle para o procedimento em execução, que lê os argumentos e os processa. ● Em algum momento, a rotina retoma o controle, extraindo o resultado da execução de uma área bem conhecida da memória. Após isso, a rotina prossegue com a execução normal.

Chamada de Procedimento Remoto - Modelo ● Thread é responsável pelo controle de dois processos: invocador e servidor. O processo invocador primeiro manda uma mensagem para o processo servidor e aguarda (bloqueia) uma mensagem de resposta. ● A mensagem de invocação contém os parâmetros do procedimento e a mensagem de resposta contém o resultado da execução do procedimento. Uma vez que a mensagem de resposta é recebida, os resultados da execução do procedimento são coletados e a execução do invocador prossegue.

Chamada de Procedimento Remoto - Modelo Do lado do servidor, um processo permanece em espera até a chegada de uma mensagem de invocação. Quando uma mensagem de invocação é recebida, o servidor extrai os parâmetros, processa-os e produz os resultados, que são enviados na mensagem de resposta. O servidor, então, volta a esperar por uma nova mensagem de invocação.

Chamada de Procedimento Remoto - Modelo

Uma chamada remota de procedimento difere das chamadas locais em alguns pontos: ● Tratamento de erros: falhas do servidor ou da rede devem ser tratadas. ● Variáveis globais e efeitos colaterais: Uma vez que o servidor não possui acesso ao espaço de endereços do cliente, argumentos protegidos não podem ser passados como variáveis globais ou retornados. ● Desempenho: chamadas remotas geralmente operam a velocidades inferiores em uma ou mais ordens de grandeza em relação às chamadas locais. ● Autenticação: uma vez que chamadas remotas de procedimento podem ser transportadas em redes sem segurança, autenticação pode ser necessário.

Operação Básica de RPC Chamada de procedimento convencional count = read (fd, buf, nbytes) fd → descritor de um arquivo buf → vetor para o qual os caracteres serão lidos nbytes → quantos bytes serão lidos

Operação Básica de RPC Chamada de procedimento convencional – Em C, parâmetros podem ser chamados por valor ou chamados por referência Em RPCs – A diferença entre chamadas por valor e por referência é importante – Outro mecanismo de passagem de parâmetros é o copiar/restaurar: “chamador” copia a variável para a pilha e ao copiá-la de volta, sobreescreve o valor original → semelhante a chamada por referência

Operação Básica de RPC Consideremos a chamada da função read – Em um sistema tradicional, a função read é um tipo de interface entre o código de usuário e o sistema operacional local Usando RPC, é possível conseguir transparência na execução da função read – Por ser um procedimento remoto, uma versão diferente da função read, denominada apêndice de cliente é colocada na biblioteca – Ela não pede por dados ao SO local. Empacota os parâmetros em uma mensagem e a envia ao servidor

Operação Básica de RPC Usando RPC, é possível conseguir transparência na execução da função read – Apêndice de cliente chama receive, bloqueando até que a resposta volte – Quando a mensagem chega ao servidor, o SO do servidor a passa para um apêndice do servidor – O apêndice de servidor desempacota os parâmetros da mensagem e chama o procedimento do servidor da maneira usual

Operação Básica de RPC Usando RPC, é possível conseguir transparência na execução da função read – Do ponto de vista do servidor, é como se ele fosse chamado diretamente pelo cliente – No caso de read o servidor colocará os dados no buffer, interno ao apêndice de servidor – Ao final, empacota o buffer em uma mensagem e retorna o resultado ao cliente – Ao chegar no cliente, o SO reconhece que a msg está direcionada ao processo cliente – Msg é copiada para o buffer e o processo cliente é desbloqueado

Operação Básica de RPC

Transparência conseguida com o uso de stubs (apêndices) Stub do cliente responsável por empacotar os parâmetros em uma msg e enviar a msg para a máquina do servidor. Quando resposta chega, resultado é copiado para cliente, e controle volta a ele Stub do servidor responsável por desempacotar parâmetros, chamar o procedimento do servidor e retornar resposta para máquina do cliente

Operação Básica de RPC Cliente Chamada Empacota Parâmetros Desempacota Resultado Retorno Desempacota Parâmetros Servidor Empacota Resultado Chamada Retorno Máquina Cliente Máquina Servidora Stub do Servidor Stub do Cliente Transporte de mensagens na rede SO

Passos seguidos por um RPC 1. Procedimento do cliente chama stub cliente de modo usual 2. Stub do cliente constrói uma msg e chama o SO 3. SO envia msg para SO remoto 4. SO remoto repassa msg para stub do servidor 5. Stub do servidor desempacota parâmetros e chama procedimento servidor 6. Procedimento servidor executa e retorna o resultado 7. Stub do servidor empacota resultado em uma msg e chama SO 8. SO remoto envia msg para SO da máquina cliente 9. SO do cliente passa msg para stub cliente 10. Stub cliente desempacota resultado, repassando-o para o cliente

Passagem de Parâmetros Função do stub do cliente é pegar seus parâmetros, empacotá-los em uma mensagem e enviá-los ao stub do servidor (montagem de parâmetros - parameter marshaling). Operação parece simples, mas: Arquiteturas diferentes? Passagem de ponteiros (diferente espaço de endereçamento)?

Passagem de Parâmetros por valor

Passagem de parâmetros por valor A chamada do procedimento remoto add somente funcionará se as máquinas do cliente e do servidor forem idênticas Problemas: – Representação diferentes para caracteres – Ordenação de bytes

Passagem de parâmetros por valor

Solução: Cliente diz seu tipo. Conversão feita pelo servidor se tipos forem diferentes.

Passagem de parâmetros por referência Como são passados ponteiros ou, em geral, referências? Um ponteiro somente é significativo dentro do espaço de endereço do processo no qual está sendo usado!

Passagem de parâmetros por referência Consideremos a função read, stub do cliente “sabe” que o segundo parâmetro aponta para um conjunto de caracteres Suponha que o cliente saiba o tamanho do vetor Solução → Copiar/restaurar: – Copiar o vetor para a mensagem e enviar ao servidor – Stub do servidor, chama o servidor com um ponteiro para este vetor – Modificação feita pelo servidor é armazenada diretamente no vetor que está no stub – Ao enviar o vetor de volta ao stub do cliente, o vetor é copiado de volta ao cliente

Linguagem de Programação de Interface - IDL Interface consiste em um conjunto de procedimentos que podem ser chamados por um cliente e que são implementados por um servidor Utilização de interface simplifica consideravelmente aplicações cliente-servidor baseadas em RPCs Gerar completamente stubs de cliente e servidor - todos os sistemas de middleware baseados em RPC oferecem uma IDL para suportar desenvolvimento de aplicação

Possíveis falhas em RPCs O cliente não consegue localizar o servidor A mensagem de requisição do cliente para o servidor é perdida A mensagem de resposta do servidor para o cliente é perdida O servidor falha depois de receber uma requisição O cliente falha depois de fazer uma requisição

Possíveis falhas em RPCs O cliente não consegue localizar o servidor – Causas: Servidor Desligado Versão desatualizada da interface – Soluções Retornar o código indicando erro Ativar exceção: destroir a transparência

Possíveis falhas em RPCs A mensagem de requisição do cliente para o servidor é perdida – Soluções Kernel do cliente inicializa um timer assim que a mensagem é enviada Se o timer expirar antes da resposta, o cliente re-envia a mensagem

Possíveis falhas em RPCs A mensagem de resposta do servidor para o cliente é perdida

RPC Assíncrona Chamadas de procedimentos convencionais → cliente bloqueia até que uma resposta seja retornada RPCs podem implementar facilidades pelas quais um cliente continua imediatamente após emitir a requisição RPC → RPCs assíncronas

RPC Assíncrona