Capítulo 3: Chamadas de Procedimentos Remotos

Transcrição

1 Capítulo 3: Chamadas de Procedimentos Remotos 2009 José Alves Marques 1 Chamada de Procedimentos Remotos RPC - Remote Procedure Call Modelo de programação da comunicação num sistema cliente-servidor Obvia as limitações referidas Objectivo: Estruturar a programação distribuída com base na chamada pelos clientes de procedimentos que se executam remotamente no servidor 2009 José Alves Marques 2 1

2 Chamada de um Procedimento Remoto Execução de um procedimento noutro processo O chamador (cliente) envia uma mensagem com um pedido O chamado (servidor) devolve uma mensagem com a resposta O programador chama um procedimento local normal O envio e recepção de mensagens são escondidos cliente r = serverfunc ( p1, p2 ); servidor r_type serverfunc ( p_type p1, p_type p2 ) { 2009 José Alves Marques 3 RPC: Fluxo de execução CLIENTE SERVIDOR Bloqueia-se Chamada ao procedimento remoto: envio dos parâmetros Cliente bloqueado Execução do procedimento pedido Retoma a execução Retorno do procedimento remoto: devolução dos resultados 2009 José Alves Marques 4 2

3 RPC: Benefícios Adequa-se ao fluxo de execução das aplicações Chamada síncrona de funções Simplifica tarefas fastidiosas e delicadas Construção e análise de mensagens Heterogeneidade de representações de dados Esconde diversos detalhes do transporte Endereçamento do servidor Envio e recepção de mensagens Tratamento de erros Simplifica a divulgação de serviços (servidores) A interface dos serviços é fácil de documentar e apresentar A interface é independente dos protocolos de transporte 2009 José Alves Marques 5 RPC: comparação com Mensagens Positivo A interface do serviço encontra-se claramente especificada e não é apenas um conjunto de mensagens Mecanismo de estabelecimento da ligação entre o cliente e o servidor é automatizado através do serviço de nomes e rotinas do run-time de suporte ao RPC As funções do cliente e do servidor são consistentes, o sistema garante que são correctamente emparelhadas O modelo de invocação de uma função e respectiva sincronização simplificam a programação Os dados são automaticamente codificados e descodificados resolvendo o problema da heterogeneidade As excepções adaptam-se bem ao tratamento de erros nas invocações remotas Negativo Só são bem suportadas as interacções 1-para-1 (ou seja não suporta difusão) Existem mais níveis de software que implicam maior overhead na execução 2009 José Alves Marques 6 3

4 RPC: Rotinas de adaptação (stubs) (também chamados ties do lado do servidor) Cliente Servidor Conversão de parâmetros Recepção e análise de Criação e envio de mensagens mensagens (pedidos) (pedidos) Conversão de parâmetros Recepção e análise de mensagens Conversão de resultados (respostas) Criação e envio de mensagens Conversão de resultados (respostas) cliente serverfunc ( ); clientstub ( ) { serverstub ( ) { servidor serverfunc ( ) { 2009 José Alves Marques 7 Arquitectura do sistema de RPC: Blocos funcionais das aplicações Código do cliente Código do servidor stubs Run-Time Library Protocolo de apresentação Protocolo de sessão stubs (ou ties) Run-Time Library Threads transporte Protocolo de transporte transporte Threads 2009 José Alves Marques 8 4

5 Arquitectura As Rotinas de Adaptação Stubs Efectuam as conversões de envio e recepção dos parâmetros da Chamada Remota Cada rotina tem os seus parâmetros específicos pelo que cada uma tem um stub Do lado do servidor existe um stub ou tie que executa as mesmas conversões pela ordem inversa Função de despacho do servidor Espera por mensagens de clientes num porto de transporte Envia mensagens recebidas para o stub respectivo Recebe mensagens dos stubs e envia-os para os clientes O Sistema de Suporte Run-time system Executa as operações genéricas do RPC, por exemplo: Abrir a ligação com o servidor, efectuar o envio e recepção das mensagens, fechar ligação Como são operações genéricas existe apenas um RTS por cliente e um por servidor 2009 José Alves Marques 9 A Visão da Programação do RPC LINGUAGEM DE DESCRIÇÃO DE INTERFACES - IDL 2009 José Alves Marques 10 5

6 RPC IDL: Características Linguagem própria Linguagem declarativa (não tem a parte operacional das linguagens de programação) permite definir Tipos de dados Protótipos de funções Fluxo de valores (IN, OUT, INOUT) Interfaces Conjuntos de funções 2009 José Alves Marques 11 RPC IDL: Código gerado pelo compilador Stubs Para o cliente Traduzem e empacotam parâmetros numa mensagem Enviam a mensagem para o servidor, esperam uma resposta Desempacotam a mensagem e traduzem a resposta Para o servidor Desempacotam a mensagem e traduzem os parâmetros Invocam a função desejada e esperam pelo seu retorno Traduzem e empacotam a resposta numa mensagem Função de despacho do servidor Espera por mensagens de clientes num porto de transporte Envia mensagens recebidas para o stub respectivo Recebe mensagens dos stubs e envia-os para os clientes 2009 José Alves Marques 12 6

7 IDL: Pode ser um.h? Quais os parâmetros de entrada/saída da seguinte função? int transfere(int origem, int destino, int valor, int *saldo, char *descr); 2009 José Alves Marques 13 RPC IDL: Limitações usuais Ambiguidades acerca dos dados a transmitir: Endereçamento puro de memória (void *) Flexibilidade no uso de ponteiros para manipular vectores Passagem de vectores (normalmente por ponteiro) Strings manipuladas com char * Passagem de variáveis por referência (&var) Semânticas ambíguas Valores booleanos do C (0 False;!= 0 True) Problemas complexos (durante a execução) Transmissão de estruturas dinâmicas com ciclos Integridade referencial dos dados enviados 2009 José Alves Marques 14 7

8 RPC IDL: Soluções para alguns dos problemas Novos tipos de dados próprios do IDL Sun RPC define 3 novos string: para definir cadeias de caracteres bool: valor booleano, apenas dois valores opaque: bit-arrays, sem tradução Agregados próprios do IDL Uniões (unions) com descriminantes Vectores conformes (DCE/Microsoft) Vectores variáveis (Sun, DCE/Microsoft) 2009 José Alves Marques 16 Exemplo: IDL Sun RPC Ficheiro banco.x program BANCOPROG { version BANCOVERS { criarret CRIAR(criarIn) = 1; saldoret SALDO(int) = 2; resultado DEPOSITAR(contaEvalor) = 3; resultado LEVANTAR(contaEvalor) = 4; resultado TRANSFERIR(transferirIn) = 5; pedirextratoret PEDIREXTRATO(pedirExtratoIn) = 6; = 1; = 0x ; 2009 José Alves Marques 17 8

9 Exemplo: Interface em IDL RPC Microsoft [ uuid(00918a0c-4d50-1c17-9bb3-92c1040b0000), version(1.0) ] interface banco { typedef enum { SUCESSO, ERRO, ERRO_NA_CRIACAO, CONTA_INEXISTENTE, FUNDOS_INSUFICIENTES resultado; typedef enum { CRIACAO, SALDO, DEPOSITO, LEVANTAMENTO, TRANSFERENCIA, EXTRATO tipooperacao; resultado criar([in] handle_t h, [in] long valor, [in, string] char nome[], [in, string] char morada[], [out] long *numero); resultado saldo([in] handle_t h, [in] long nconta, [out] long *valor); resultado depositar([in] handle_t h, [in] long nconta, [in] long valor); resultado levantar([in] handle_t h, [in] long nconta, [in] long valor); resultado transferir([in] handle_t h, typedef struct { [in] long ncontaorigem, long dia; [in] long ncontadest, long mes; [in] long valor); long ano; tipodata; resultado pedirextrato([in] handle_t h, [in] long nconta, typedef struct { tipodata data; [in] long mes, tipooperacao operacao; [in] long ano, long movimento; [in, out, ptr] dadosoperacao dados[50], long saldo; [out] long *nelemento); dadosoperacao; 2009 José Alves Marques 18 Protocolos e Serviços necessário para suportar o RPC HETEROGENEIDADE E NOMES 2009 José Alves Marques 19 9

10 Heterogeneidade Nos sistemas distribuídos a heterogeneidade é a regra Os formatos de dados são diferentes Nos processadores (ex.: little endian, big endian, apontadores) Nas estruturas de dados geradas pelos compiladores Nos sistemas de armazenamento Nos sistemas de codificação As mensagens entre as máquinas enviam tipos básicos do RPC (caracteres, inteiros, reais, etc) ou tipos agregados. As redes transmitem bytes entre as máquinas. É necessário traduzir tipos das mensagens para bytes. De forma a suportar heterogeneidade entre emissor e receptor 2009 José Alves Marques 20 Resolução da Heterogeneidade na Comunicação Modelo OSI camada de Apresentação Protocolo ASN.1 Sistemas de RPC aproveitam descrição formal da interface heterogeneidade resolvida através de técnicas de compilação. A partir destes sistemas a heterogeneidade na comunicação ficou resolvida no ambiente de execução José Alves Marques 21 10

11 Protocolos de Apresentação no RPC Decisões a efectuar Estrutura dos mensagens Implícita as mensagens apenas contêm os dados a transmitir Explicita Auto-descritiva (marcada, tagged) Políticas de conversão dos dados Canónica Uma única representação para que todos convertem N formatos N funções Não há comportamentos variáveis É preciso converter mesmo quando é inútil O-receptor-converte (Receiver-makes-it-right) Poupa conversões inúteis N formatos N x N funções 2009 José Alves Marques 22 Protocolos de Apresentação XDR (external Data Representation) Sun RPC NDR (Network Data Representation) DCE RPC Microsoft RPC ASN.1 (Abstract Syntax Notation) Conversão Canónica O-receptor-converte Canónica Canónica Estrutura das mensagens Implícita Comprimentos de vectores variáveis Alinhamento a 32 bits (excepto vectores de caracteres) Implícita Marcas arquitecturais (architecture tags) OSI Explícita - Tagged Encoding Rules: Basic (BER) Distinguished (DER) Canonical (CER) Packed (PER) XML Extensible Markup Language W3C Explicita Tagged Tipos de Documentos DTD XML schema 2009 José Alves Marques 23 11

12 Ligação entre o Cliente e o Servidor LIGAÇÃO OU BINDING 2009 José Alves Marques 24 RPC: Serviço de Nomes Permite que o servidor registe um nome de um serviço Que tem de estar associado ao identificador de um porto de transporte Permite que um cliente consiga encontrar o servidor através do nome do serviço. Obter o nome do seu porto de transporte cliente procura N2 N1 registo Serviço de Nomes servidor N José Alves Marques 25 12

13 O binding tem de ser efectuado pelo cliente Estabelecimento da sessão - ligação ao servidor (binding) Localização do servidor Autenticação do cliente e/ou do servidor Estabelecimento de um canal de transporte {Chamada de procedimentos remotos* - efectua os RPC necessários Terminação da sessão Eliminação do canal de transporte 2009 José Alves Marques 26 O registo tem de ser efectuado pelo servidor Registo Escolha da identificação do utilizador Nome do porto de transporte Outros nomes alternativos Registo dessa identificação {Esperar por pedidos de criação de sessões* Estabelecimento de um canal de transporte Autenticação do cliente e/ou do servidor {Esperar por invocações de procedimentos* Enviados pelos clientes ligados Terminação da sessão Eliminação do canal de transporte 2009 José Alves Marques 27 13

14 Referências de sessão binding handles Cliente Criação do binding handle no extremo cliente Identifica um canal de comunicação ou um porto de comunicação para interactuar com o servidor Servidor Possível criação de um binding handle no extremo servidor Útil apenas se o servidor desejar manter estado entre diferentes RPCs do mesmo cliente Um servidor sem estado não mantém binding handles 2009 José Alves Marques 29 Exemplo Binding : Cliente Sun RPC void main (int argc, char *argv[]){ CLIENT *cl; int a, *result; char* server; if (argc < 2) { fprintf(stderr, "Modo de Utilização: %s máquina do servidor\n", argv[0]); exit(1); server = argv[1]; cl = clnt_create(server, BANCOPROG, BANCOVERS, "tcp"); if(cl == NULL) { clnt_pcreateerror(server); exit(1); sresult = saldo(nconta, cl); 2009 José Alves Marques 30 14

15 Ligação cliente-servidor Os binding handles podem ser usados pelos stubs de uma forma Explícita Implícita Automática Explícito (Sun RPC, DCE RPC) Implícito (DCE RPC) Automático (DCE RPC) Inicialização do Cliente Obtém informação de ligação Usa-a explicitamente em cada RPC Obtém informação de ligação Guarda-a numa variável global (não necessária) Stub cliente A função de stub tem um parâmetro de entrada que especifica o handle a usar na chamada Usa a variável global Obtém informação de ligação Guarda-a localmente e usa-a 2009 José Alves Marques 31 RPC: Infra-estrutura de suporte No desenvolvimento Uma linguagem de especificação de interfaces Interface Description Language, IDL Compilador de IDL Gerador de stubs Na execução Serviço de Nomes Biblioteca de suporte à execução do RPC (RPC Run-Time Support) Registo de servidores Binding protocolo de ligação do cliente ao servidor Protocolo de controlo da execução de RPCs Controlo global da interação cliente-servidor 2009 José Alves Marques 32 15

16 Aspectos importantes a analisar 1. Transparência 2. Semântica de Execução 1. Protocolo de controlo 3. Multitarefas e RPC 2009 José Alves Marques 33 RPC: Entraves à transparência IDL Normalmente diferente da linguagem usada pelos programas Passagem de parâmetros Semânticas não suportadas pelo RPC Execução do procedimento remoto Tolerância a faltas e notificação de faltas Desempenho Depende em grande medida da infra-estrutura de comunicação entre cliente e servidor 2009 José Alves Marques 34 16

17 Semânticas de execução A semântica de execução determina o modelo de recuperação de faltas Semântica ideal procedimento local Modelo de faltas Perda, duplicação ou reordenação de mensagens Falhas no servidor e no cliente Possibilidade de servidor e cliente re-iniciarem após a falhas 2009 José Alves Marques 35 Algumas faltas possíveis cliente t servidor reenvio cliente servidor t início reenvio cliente t servidor cliente início servidor reenvio 2009 José Alves Marques 36 17

18 Semânticas de execução Semânticas Talvez (maybe) Pelo-menos-uma-vez (at-least-once) No-máximo-uma-vez (at-most-once) Exactamente-uma-vez (exactly-once) 2009 José Alves Marques 37 Arquitectura do sistema de RPC: Semânticas de execução Semântica talvez O stub cliente retorna um erro se não receber uma resposta num prazo limite Sem uma resposta o cliente não sabe se o pedido foi executado ou não Protocolo não tem de se preocupar com duplicações de pedidos Semântica pelo-menos-uma-vez O stub cliente repete o pedido até obter uma resposta Caso haja uma resposta o cliente tem a garantia que o pedido foi executado pelo menos uma vez E se o servidor falha permanentemente? Para serviços com funções idempotentes 2009 José Alves Marques 38 18

19 Arquitectura do sistema de RPC: Semânticas de execução Semântica no-máximo-uma-vez O protocolo de controlo tem que: Identificar os pedidos para detectar repetições no servidor Manter estado no servidor acerca de que pedidos estão em curso ou já foram atendidos Semântica exactamente-uma-vez Também implica identificar os pedidos para detectar repetições E se for usado um temporizador? Qual a semântica ao expirar? 2009 José Alves Marques 39 Arquitectura do sistema de RPC: Protocolo de controlo Suporte de vários protocolos de transporte Com ligação O controlo é mais simples RPCs potencialmente mais lentos Sem ligação Controlo mais complexo (mais ainda se gerir fragmentação) RPCs potencialmente mais rápidos Emparelhamento de chamadas/respostas Identificador de chamada (CallID) Confirmações (Acks) Temporizações Estado do servidor para garantir semânticas Tabela com os CallIDs das chamadas em curso Tabela com pares (CallID, resposta enviada) 2009 José Alves Marques 40 19

20 Protocolo de RPC Situação Ideal Máquina do Cliente Utilizador Chamada RPC Enviar pacote Esperar ack ou resultado Call [CallID, procedimento, argumentos] Máquina do Servidor RPC Invocar função Servidor Executar função Retornar Resultado[CallID, resultados] Enviar resultados Retornar Apenas são utilizadas duas mensagens 2009 José Alves Marques 41 Protocolo de RPC: Situação Complexa Máquina Cliente Máquina do Servidor Utilizador Chamada RPC Enviar call msg Esperar ack Call[CallID. Pkt=0, pleaseack,...] RPC Servidor memorizar a msg Construir o prox. pacote Ack[CallID, Pkt=0] Confirmar Esperar pelo próximo pacote Enviar o pacote Esperar ack Data[CallID, Pkt=1, dontack,...] Chamar a função Executar função Retransmitir Esperar ack Data[CallID, Pkt=1, pleaseack,...] Esperar resultado Retornar Confirmar Ack[CallID, Pkt=1] Result[CallID, Pkt=2, dontack,...] Result[CallID, Pkt=2, pleaseack,...] Ack[CallID, Pkt=2] Confirmar Enviar resultado Esperar ack Retransmitir Esperar ack Retornar 2009 José Alves Marques 42 20

21 Execução de RPCs: (i) Fluxos de execução simples Servidores Um pedido de cada vez Serialização de pedidos Uma única thread para todos os pedidos Vários pedidos em paralelo Uma thread por pedido A biblioteca de RPC tem que suportar paralelismo: Sincronização no acesso a binding handles Sincronização no acesso a canais de comunicação 2009 José Alves Marques 43 Execução de RPCs: (ii) Fluxos de execução simples Clientes Um pedido de cada vez Vários pedidos em paralelo Uma thread por pedido A biblioteca de RPC tem que suportar paralelismo: Sincronização no acesso a binding handles Sincronização no acesso a canais de comunicação 2009 José Alves Marques 44 21

22 Execução de RPCs: (iii) Fluxos de execução complexos Chamadas em ricochete (callbacks) Um cliente é contactado como sendo um servidor no fluxo da sua chamada cliente servidor mesma thread ou threads diferentes? mesma thread mesmo CallID base 2009 José Alves Marques 45 Execução de RPCs: (iv) Fluxos de execução alternativos CLIENTE Lançamento Recuperação CLIENTE Lançamento SERVIDOR SERVIDOR Chamadas assíncronas (follow-up RPC) Duas operações não consecutivas: Lançamento Recuperação Permitem optimizar os clientes Menos tempo bloqueado Transparente para os servidores Podem simplificar a realização de RPC concorrentes Recuperação 2009 José Alves Marques 46 22

23 Execução de RPCs: (v) Fluxos de execução alternativos Chamadas sem retorno (one-way operation) Equivalente a uma chamada assíncrona sem recuperação São definidas na interface dos serviços Afecta todos os clientes (ex. atributo maybe no DCE IDL) Não permitem retornar resultados Porque não há qualquer mensagem de resposta Semânticas limitadas Talvez Algumas falhas podem ser detectadas pelos clientes Erros de transmissão locais 2009 José Alves Marques 47 Execução de RPCs: (vi) Fluxos de execução alternativos RPCs locais (numa única máquina) Podem-se simplificar ou optimizar várias acções protocolares Simplificações: Eliminação dos protocolos de apresentação Optimizações: Partilha de tampões para troca de mensagens Diminuição de cópias de dados A maioria dos RPCs de uso genérico não optimizam significativamente 2009 José Alves Marques 48 23

24 Execução de RPCs: (vii) Fluxos de execução alternativos RPC em difusão (broadcast) Questões técnicas e semânticas Qual a abrangência da difusão? Como se processa o estabelecimento da ligação? Qual o suporte de transporte à difusão? Qual a política de envio e recolha de respostas? 2009 José Alves Marques 49 Execução de RPCs: Desempenho Influência da aplicação Ligação (autenticação, etc.) Dimensão dos parâmetros e resultados Protocolo de transporte escolhido Execução do pedido Influência da infra-estrutura Rede Largura de banda, congestão, latência Máquinas cliente e servidora Velocidade, carga 2009 José Alves Marques 50 24

25 Exemplos de RPC existentes no mercado RPC - EXEMPLOS 2009 José Alves Marques 51 Exemplos de RPCs ONC RPC (ex- Sun RPC) RFC 1831 (RPC: Remote Procedure Call Protocol Specification) RFC 1832 (XDR: External Data Representation Standard) RFC 1833 (RPC: Binding Protocols) DCE RPC CAE Specification C706 (DCE 1.1: Remote Procedure Call) Microsoft RPC Compatível com o DCE RPC (definição de interfaces, protocolos) Suporta extensões próprias 2009 José Alves Marques 52 25

26 SUN RPC Sistema de RPC desenvolvido pela SUN cerca de 1985 Destinado inicialmente a suportar o sistema de ficheiros distribuído NFS Especificação de domínio público Implementação simples e muito divulgada em grande número de plataformas (Unix, MS-DOS, ) 2009 José Alves Marques 53 Objectivos Máquina A Aplicação cliente funcx(args); Máquina B Aplicação servidora funcx(args); Kernel RPC stubs pedido resposta Socket TCP ou UDP RPC stubs + dispatcher pedido resposta Kernel Socket TCP ou UDP connect 2009 José Alves Marques 54 26

27 SUN RPC Linguagem de IDL semelhante a C, suportada pelo compilador rpcgen Apenas um parâmetro de entrada e um parâmetro de saída Vários valores são transferidos em estruturas Construção que permite transmitir condicionalmente informação Todos os parâmetros são passados por referência para os stubs rpcgen gera automaticamente o programa principal do servidor Biblioteca de RPC inicialmente usava sockets, actualmente usa TLI 2009 José Alves Marques 55 Sun RPC: Exemplo de IDL program BINOP { version BINOP_VERS { long BINOP_ADD ( struct input_args ) = 5; = 1; = ; struct input_args { long a; long b; ; Identificação (nomes) Interface (n programa, n versão) (300030, 1) Função (Interface, n função) (300030, 1, 5) 2009 José Alves Marques 56 27

28 Sun RPC: Serviço de Nomes e encaminhamento de RPCs Máquina A rpcbind Máquina B cliente porto 111 porto de transporte registo (n interface, porto de transporte) procura (n interface, transporte) servidor Cliente stub call ( binding handle n interface, n função, parâmetros) pedido resposta XID (op. id) XID RPC version RPC error n interface resultados n função autenticador parâmetros transporte despacho da interface stub Servidor operação 2009 José Alves Marques 57 Diagrama de ficheiros calc.x Service Interface calc_clnt.cc Client stubs Client source files rpcgen calc.h Definições Tipos Protótipos #include calc_xdr.c XDR marshaling Makefile Sample Makefile calc_srv.c Server stubs & dispatcher Server source files 2009 José Alves Marques 60 28

29 rpcgen: definição e compilação da interface calc.x enum calc_error { CALC_OK = 0, /* No error */ CALC_ZERO_DIV = 1 /* Division by zero */ ; struct calc_args { double v1; double v2; ; struct calc_result { calc_error error; double value; ; calc_clnt.cc calc_svc.c calc_xdr.c rpcgen -C rpcgen -Sc rpcgen -Ss rpcgen -Sm program CALC_PROG { version CALC_VERS { calc_result SUM(calc_args) = 1; calc_result SUB(calc_args) = 2; Sample Sample Sample calc_result MUL(calc_args) = 3; client server Makefile calc_result DIV(calc_args) = 4; = 1; = ; 2009 José Alves Marques 61 Diagrama de ficheiros (cont.) calc.x calc_result sum(calc_args)... VERSION=1 rpcgen -C calc_clnt.cc calc_result sum_1(calc_args,...).) {... calc.h typedef... calc_result; calc_xdr.c typedef... calc_args; calc_result xdr_calc_result() sum_1(calc_args,...); {... calc_result xdr_calc_args() sum_1_svc(calc_args,...);..); {... main(...) {... calc_srv.c main(...) {... svc_run(); calc_prog_1(...) {... calc_result sum_1_svc(calc_args,...)..) { José Alves Marques 62 29

30 Funções de conversão via XDR calc.x enum calc_error { CALC_OK = 0, /* No error */ CALC_ZERO_DIV = 1 /* Div. by zero */ ; struct calc_args { double v1; double v2; ; struct calc_result { calc_error error; double value; ; rpcgen -C program CALC_PROG { version CALC_VERS { calc_result SUM(calc_args) = 1; calc_result SUB(calc_args) = 2; calc_result MUL(calc_args) = 3; calc_result DIV(calc_args) = 4; = 1; = ; calc_xdr.c #include "calc.h bool_t xdr_calc_error(xdr *xdrs, calc_error *objp) { if (!xdr_enum(xdrs, (enum_t *)objp)) return (FALSE); return (TRUE); bool_t xdr_calc_args(xdr *xdrs, calc_args *objp) {... bool_t xdr_calc_result(xdr *xdrs, calc_result *objp) { if (!xdr_calc_error(xdrs, &objp->error)) return (FALSE); if (!xdr_double(xdrs, &objp->value)) return (FALSE); return (TRUE); 2009 José Alves Marques 63 Funções do cliente (stubs) calc.x enum calc_error { CALC_OK = 0, /* No error */ CALC_ZERO_DIV = 1 /* Division by zero */ ; struct calc_args { double v1; double v2; ; struct calc_result { calc_error error; double value; ; program CALC_PROG { version CALC_VERS { calc_result SUM(calc_args) = 1; calc_result SUB(calc_args) = 2; calc_result MUL(calc_args) = 3; calc_result DIV(calc_args) = 4; = 1; = ; rpcgen -C #include "calc.h calc_clnt.c static struct timeval TIMEOUT = { 25, 0 ; calc_result * sum_1(calc_args *argp, CLIENT *clnt) { static calc_result clnt_res; if (clnt_call(clnt, SUM, xdr_calc_args, argp, xdr_calc_result, &clnt_res, TIMEOUT)!= RPC_SUCCESS) SS) { return (NULL); return (&clnt_res); calc_result * sub_1(calc_args *argp, CLIENT *clnt) {... calc_result * mul_1(calc_args *argp, CLIENT *clnt) {... calc_result * div_1(calc_args *argp, CLIENT *clnt) { José Alves Marques 64 30

31 #include <stdio.h> #include <rpc/rpc.h> #include "banco.h" static void bancoprog_1(); main() { register SVCXPRT *transp; Exemplo: Ficheiro banco_svc.c Gerado pelo rpcgen (void) pmap_unset(bancoprog, BANCOVERS); transp = svcudp_create(rpc_anysock); if (transp == NULL) { fprintf(stderr, "cannot create udp service."); exit(1); if (!svc_register(transp, BANCOPROG, BANCOVERS, bancoprog_1, IPPROTO_UDP)) { fprintf(stderr, "unable to register (BANCOPROG, BANCOVERS, udp)."); exit(1); transp = svctcp_create(rpc_anysock, 0, 0); if (transp == NULL) { fprintf(stderr, "cannot create tcp service."); exit(1); if (!svc_register(transp, BANCOPROG, BANCOVERS, bancoprog_1, IPPROTO_TCP)) { fprintf(stderr, "unable to register (BANCOPROG, BANCOVERS, tcp)."); exit(1); svc_run(); fprintf(stderr, "svc_run returned"); exit(1); /* NOTREACHED */ 2009 José Alves Marques 65 Exemplo: Ficheiro banco_svc.c Gerado pelo rpcgen static void bancoprog_1(rqstp, transp) struct svc_req *rqstp; register SVCXPRT *transp; { union { criarin criar_1_arg; int saldo_1_arg; contaevalor depositar_1_arg; contaevalor levantar_1_arg; transferirin transferir_1_arg; pedirextratoin pedirextrato_1_arg; argument; char *result; bool_t (*xdr_argument)(), (*xdr_result)(); char *(*local)(); switch (rqstp->rq_proc) { case NULLPROC: (void) svc_sendreply(transp, xdr_void, (char *)NULL); return; case CRIAR: xdr_argument = xdr_criarin; xdr_result = xdr_criarret; local = (char *(*)()) criar_1; break; case SALDO: xdr_argument = xdr_int; xdr_result = xdr_saldoret; local = (char *(*)()) saldo_1; break; case PEDIREXTRATO: xdr_argument = xdr_pedirextratoin; xdr_result = xdr_pedirextratoret; local = (char *(*)()) pedirextrato_1; break; default: svcerr_noproc(transp); return; bzero((char *)&argument, sizeof(argument)); if (!svc_getargs(transp, xdr_argument, &argument)) { svcerr_decode(transp); return; result = (*local)(&argument, rqstp); if (result!= NULL &&!svc_sendreply(transp, xdr_result, result)) { svcerr_systemerr(transp); if (!svc_freeargs(transp, xdr_argument, &argument)) { fprintf(stderr, "unable to free arguments"); exit(1); return; 2009 José Alves Marques 66 31

32 DCE RPC: Exemplo de IDL [ uuid 522fd85c-4da5-4a50-aa82-43d14e5ad74e ], version (5), endpoint ( )] interface binopwk { [idempotent] void binopwk_add ( [in] handle_t h, [in] long a, [in] long b, [out] long *c ); ; UUID (Universal Unique Identifier) Valor de 128 bits único no espaço e no tempo Identificação (nomes) Interface (UUID, n versão) (522fd85c-4da5-4a50-aa82-43d14e5ad74e, 5) Função (Interface, n função) O número de função é atribuído pelo compilador de IDL 2009 José Alves Marques 67 Um exemplo de um protocolo cliente servidor mas que não é um RPC genérico HTTP 2009 José Alves Marques 69 32

33 HyperText Transfer Protocol - HTTP Foi o protocolo de base da World Wide Web definido em 1990 Um cliente web comunica com um servidor Web usando uma ou várias ligações TCP Um porto normalmente predefinido para o servidor Web é o porto 80 O protocolo é muito simples: O cliente estabelece uma ligação TCP com o servidor Manda um pedido Lê a resposta O servidor fecha a ligação Nas versões posteriores existem persistent connections que permanecem estabelecidas durante uma interacção 2009 José Alves Marques 70 HyperText Transfer Protocol - HTTP Protocolo de Pedido Resposta do tipo RPC Diferença: funções remotas estão predefinidas: GET, PUT, POST, etc. O protocolo permite parametrizar Conteúdos os pedidos dos clientes podem especificar que tipo de dados aceitam Autenticação Credenciais e desafios são utilizados para uma autenticação do tipo password Método GET HEAD PUT POST DELETE Descrição Pedido de documento Pedido apenas de cabeçalho de documento Pedido para guardar um documento Fornecimento de informação para ser acrescentada ao documento Pedido para apagar um documento 2009 José Alves Marques 71 33

34 Mensagem de Pedido GET /somedir/page.html HTTP/1.1 Host: Connection: close User-agent: Mozilla/4.0 Accept-language: fr 2009 José Alves Marques 72 Formato genérico da mensagem de pedido Request line method sp URL sp Version cr lf Header field name: sp value cr lf Header lines Blank line Entity body cr Header field name: sp value cr lf lf 2009 José Alves Marques 73 34

35 Mensagem de Resposta HTTP Response Message HTTP/ OK Connection: close Date: Thu, 03 Jul :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Sun, 5 May :23:24 GMT Content-Length: 6821 Content-Type: text/html (data data data data data... ) 2009 José Alves Marques 74 Formato genérico da mensagem de resposta Status line version sp status code SP phrase cr lf Header field name: sp value cr lf Header lines Blank lines cr Header field name: sp value cr lf lf Entity body 2009 José Alves Marques 75 35

36 HTTP Heterogeneidade: Os pedidos e respostas são transformados em cadeias de caracteres, eliminando o problema da heterogeneidade mas tornado as mensagens muito mais longas A semântica é no máximo uma vez 2009 José Alves Marques 76 36