Remote Procedure Calls. Mário Antonio Meireles Teixeira

Transcrição

1 Remote Procedure Calls Mário Antonio Meireles Teixeira 1

2 Introdução No paradigma cliente-servidor, os usuários interagem com aplicações clientes que solicitam tarefas dos servidores. A comunicação entre clientes e servidores se dá através de um mecanismo do tipo send/receive (request/reply). Cliente DoOperation.. wait.. Request message Reply message Servidor GetRequest. execute. SendReply RPC introduz uma abstração maior nesse esquema, permitindo que os clientes se comuniquem com os servidores através de chamadas a procedimentos. Assim, um serviço pode ser visto como um módulo que possui uma interface bem definida de acesso às suas funções. - uniformidade de acesso (+ simples) - segurança - transparência 2

3 Aspectos de uma RPC Os parâmetros são enviados ao servidor em uma mensagem através da rede, assim como os valores que são retornados ao cliente Passagem por valor. Não faz sentido utilizar variáveis globais ou ponteiros referências opacas. Interface Definition Language: Especifica os nomes dos procedimentos de acesso aos serviços, lista de seus parâmetros, tipos e se são de entrada ou saída (Procedure Signatures). Benefícios: - esconde a implementação dos procedimentos; - independência em relação à linguagem; - em suma: maior abstração. Classes de RPC: O sistema de RPC está integrado com uma linguagem de programação. Ex: Cedar, Argus. É utilizada uma linguagem específica para definição da interface entre clientes e servidores. Ex: Sun RPC (NFS), ANSA, MIG (Mach). Tratamento de Exceções Transparência 3

4 Chamadas Locais a Procedimentos Como funciona uma Local Procedure Call? Suponha a função: int mul(x,y) Em uma chamada local, acontecem as seguintes ações: os parâmetros e o endereço de retorno são colocados na pilha; é alocado espaço para as variáveis locais; o controle é passado para a rotina chamada. Quando o procedimento chega ao fim: o valor retornado é copiado para um registrador; recupera-se o endereço de retorno; a área na pilha é liberada; o controle retorna a rotina que fez a chamada. Parâmetros podem ser passados por: valor referência copy/restore 4

5 Operação de uma RPC Chamada Local Retorno Local Ordena argumentos Retira resultados Envia solicitação Recebe resposta Recebe solicitação Envia resposta Retira argumentos Seleciona Procedimento Ordena resultados Executa Procedim. Retorna Client Stub Módulos de Comunicação Dispatcher Server Stub Em uma RPC, o cliente chama um tipo especial de rotina, denominada client stub coloca os parâmetros em uma mensagem e a envia ao servidor, bloqueando-se até que venha uma resposta. No lado do servidor, o server stub recebe a mensagem, retira os parâmetros e faz uma chamada local ao procedimento servidor. Durante todo o processo, cliente e servidor acreditam que tudo está acontecendo localmente. 5

6 Geração da Interface ( Stubs ) A partir da linguagem de definição da interface são gerados os stubs. Cada procedimento recebe um número identificador (0, 1, 2...), que é conhecido tanto pelos clientes quanto pelo servidor. No lado cliente: O compilador de interface provê uma stub procedure para cada procedimento remoto. Cuja função é: - criar uma mensagem composta dos argumentos e do identificador do procedimento; - enviá-la ao servidor; - aguardar a resposta; - retirar os argumentos e retornar os resultados ao caller 6

7 Geração da Interface ( Stubs ) No lado servidor: Existe um dispatcher identifica procedimento servidor E uma stub procedure para cada procedimento Cuja função é: Exemplos: - retirar os argumentos da mensagem; - chamar o procedimento servidor; - quando este retornar, compõe a mensagem de retorno e a envia ao cliente. Interface Definition Language XDR Interface Compiler rpcgen 7

8 Passagem de Parâmetros Parameter Marshalling: ordenar os parâmetros em uma mensagem. Não é tão simples quanto aparenta. Máquina Cliente Máquina Servidora x = mul (2, 3) mul 2 3 mul 2 3 mul(i,j) int i,j; {... } Kernel Kernel Problemas: EBCDIC Esquemas de codificação IBM mainframes: IBM PCs: ASCII Representação de números inteiros (complemento de 1 ou 2) e de ponto flutuante. Armazenamento de inteiros na memória: - Intel numera da direita para a esquerda - Sun SPARC esquerda para a direita 8

9 Passagem de Parâmetros Como fazer Passagem por Referência? Ponteiros só fazem sentido no espaço de enderaçamento em que foram definidos. Ex: read(fd, buf, nbytes) Uma solução: Enviar buf na mensagem. O server stub chama o procedimento servidor com um valor de ponteiro diferente do usado no cliente. Ao final, copia o novo buf sobre o antigo copy/restore Otimização: Parâmetros só de entrada não precisam ser copiados de volta para o cliente. Parâmetros só de saída não precisam ser enviados ao servidor. Estas informações são obtidas a partir da especificação dos procedimentos (IDL). Ponteiros para estrturas complexas (árvores, grafos) mais problemático ainda. 9

10 Binding Problema: Como o cliente localiza o servidor? Uma solução: colocar o endereço de rede do servidor no programa cliente inflexível Alternativa: mapear dinamicamente cada serviço em uma porta específica de um dado servidor binding dinâmico No UNIX, o identificador do servidor é composto por: end. internet + port number socket Binder: mantém uma tabela mapeando os serviços nas portas dos servidores. PROCEDURE Register (Servico:String; Porta:Port; Versao:Int) Solicita ao binder que registre o nome de um serviço, seu endereço de acesso e número de versão. PROCEDURE WithDraw (Servico:String; Porta:Port; Versao:Int) Solicita ao binder que retire um determinado serviço de sua tabela PROCEDURE LookUp (Servico:String; Versao:Integer) : Port O binder procura por um serviço em sua tabela e retorna o endereço de acesso se o número da versão for compatível 10

11 Binding Como localizar o Binder? Ele possui um endereço well-known (host address) Seu endereço é mantido em uma variável de ambiente Para localizá-lo, o cliente ou servidor faz um broadcast, ao qual o binder responde com seu host address Vantagens Binding Dinâmico: bastante flexível permite vários servidores para o mesmo serviço balancear os clientes entre os servidores o servidor pode escolher os clientes que deseja atender controle de versão Desvantagens: overhead para localizar o binder os clientes geralmente têm vida curta Binder pode se tornar um gargalo Alternativa: - múltiplos binders mas: - há o overhead de mânte-los consistentes 11

12 Possíveis Falhas durante uma RPC Cliente não consegue localizar o Servidor o servidor está down o client stub utilizado está defasado Solução: criar um novo tipo de erro, p.ex.: Cannot locate server Causar uma exception (não é transparente) Perda de Mensagens de Solicitação de Serviços Ao enviar uma mensagem, inicia-se um timer. Se este expirar antes de vir uma resposta, envia a mensagem novamente. Perda de Mensagens de Resposta Usa-se um timer, como acima. Qual a falha a solicitação se perdeu? a resposta se perdeu? o servidor está sobrecarregado? Nem todas as solicitações podem ser repetidas sem causar dano (Não idempotentes). 12

13 Possíveis Falhas durante uma RPC Crash do servidor REQ Servidor REQ Servidor Receive Execute Reply Receive Execute Crash REP (a) No REP (b) REQ No REP Servidor Receive Crash (c) Crash do Cliente Se um cliente cai enquanto sua solicitação está sendo processada, esta se torna inútil órfã Como solucionar? - extermínio - reencarnação - reencarnação gentil - expiração 13

14 Possíveis Falhas durante uma RPC Semântica da Chamada RPC: Semântica Maybe Os clientes não sabem nada sobre o resultado da RPC. Fácil de implementar. Semântica At-least-once Garante que a solicitação foi executada uma ou mais vezes. Se as operações do servidor são todas idempotentes, então não há problema. Semântica At-most-once Garante que a solicitação foi executada no máximo uma vez, mas pode também não ter sido executada (mais comum). Ideal: Semântica Exactly-once 14

15 Sun RPC Procedimentos Servidores senhasrv.c cc Prog. Servidor senhasrv Especificação da Interface senha.x rpcgen senha_svc.c senha.h senha_xdr.c Biblioteca RPC Fonte Programas Clientes ulogin.c adduser.c rmuser.c senha_clnt.c cc Prog. Clientes ulogin adduser rmuser Para gerar os procedimentos stubs e o arquivo de cabeçalho, é preciso criar um arquivo (*.x) com a especificação da interface do servidor. Em seguida, este é submetido ao Gerador de Stubs: - rpcgen senha.x que fornece como resultado: - senha.h senha_clnt.c senha_svc.c senha_xdr.c 15

16 Sun RPC Estes arquivos devem ser, então, compilados com os programas cliente e servidor reais: $ cc -o adduser adduser.c senha_clnt.c $ cc -o senhasrv senhasrv.c senha_svc.c Conteúdo de senha.x: struct tusuario { char username[20]; char password[20]; int status; }; program SENHA_PROG { version SENHA_VERS { int CONSULTA (struct tusuario) = 1; int CADASTRA (struct tusuario) = 2; int VAL_SENHA(struct tusuario) = 3; int REMOVE (struct tusuario) = 4; } = 1; } = 0x ; 16

17 Sun RPC Programa Cliente: void main(argc, argv) int argc; char *argv[]; { CLIENT *cl; struct tusuario reg; char *server; int *result; server = argv[1]; cl = clnt_create(server,senha_prog,senha_vers, "udp"); for(;;) { printf("\nusername : "); scanf("%s",reg.username); if (!strcmp(reg.username,"*")) break; Criptografa(reg.username); result = consulta_1(&reg,cl); if (*result > 0) { printf("username ja\' existe\n"); continue; }... }... } 17