Capítulo 3: Chamadas de Procedimentos Remotos

(1)

2009 José Alves Marques 1

Capítulo 3: Chamadas de Procedimentos

Remotos

Departamento de Engenharia Informática

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

(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

…

r = serverFunc( p1, p2 ); …

r_type

serverFunc( p_type p1, p_type p2 ) {

… }

cliente servidor

RPC: Fluxo de execução

CLIENTE SERVIDOR

Cliente bloqueado Bloqueia-se

Chamada ao procedimento remoto:

envio dos parâmetros

Execução do procedimento

pedido

Retoma a execução

Retorno do procedimento remoto:

(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

RPC: comparação com Mensagens

Positivo

Negativo

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

• 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

(4)

RPC: Rotinas de adaptação (stubs)

(também chamados ties do lado do servidor)

• Cliente

– Conversão de parâmetros – Criação e envio de mensagens

(pedidos)

– Recepção e análise de mensagens (respostas) – Conversão de resultados • Servidor – Recepção e análise de mensagens (pedidos) – Conversão de parâmetros – Conversão de resultados – Criação e envio de mensagens

(respostas) serverFunc( … ); serverFunc( … ) { … } servidor clientStub( … ) { … } cliente serverStub( … ) { … }

Run-Time Library Run-Time Library

Arquitectura do sistema de RPC:

Blocos funcionais das aplicações

Código do cliente stubs Run-Time Library Run-Time Library transporte Threads Código do servidor stubs (ou ties) transporte Protocolo de transporte Protocolo de transporte Protocolo de sessão Protocolo de sessão Protocolo de apresentação Protocolo de apresentação Threads

(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

LINGUAGEM DE DESCRIÇÃO

DE INTERFACES - IDL

(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

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

(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);**

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

(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)

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; } = 0x20000005;

(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; typedef struct { long dia; long mes; long ano; } tipoData; typedef struct { tipoData data; tipoOperacao operacao; long movimento; long saldo; } dadosOperacao;

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,

[in] long nContaOrigem,

[in] long nContaDest,

[in] long valor);

resultado pedirExtrato([in] handle_t h,

[in] long nConta,

[in] long mes,

[in] long ano,

[in, out, ptr] dadosOperacao dados[50],

[out] long *nElemento);

HETEROGENEIDADE E

NOMES

(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

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.

(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

Protocolos de Apresentação

XDR (eXternal Data Representation) NDR (Network Data Representation) ASN.1 (Abstract Syntax Notation) XML Extensible Markup Language Sun RPC DCE RPC Microsoft RPC OSI W3C

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) Explícita - Tagged Encoding Rules: Basic (BER) Distinguished (DER) Canonical (CER) Packed (PER) Explicita – Tagged Tipos de Documentos DTD XML schema

(12)

LIGAÇÃO OU BINDING

Ligação entre o Cliente e o Servidor

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

servidor

N1 registo procura N1 N2 Serviço de Nomes

(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

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

(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

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); }

(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)

Stubcliente 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

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

(16)

Aspectos importantes a analisar

1. Transparência

2. Semântica de Execução

1. Protocolo de controlo

3. Multitarefas e RPC

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

(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

Algumas faltas possíveis

∆t cliente servidor início reenvio ∆t cliente servidor reenvio cliente servidor início ∆t reenvio cliente servidor

(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)

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

(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?

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)

(20)

Protocolo de RPC

Situação Ideal

Chamada Enviar _pacote Esperar ack ou resultado Retornar Invocar função Enviar resultados Executar função Retornar RPC Servidor Call [CallID, procedimento, argumentos] Resultado[CallID, resultados]

Máquina do Cliente Máquina do Servidor

Utilizador RPC

Apenas são utilizadas duas mensagens

Protocolo de RPC: Situação Complexa

Call[CallID. Pkt=0, pleaseAck, ....] Chamada Enviar call msg

Esperar ack Construir o prox. pacote Enviar o pacote _{Esperar ack}

Retransmitir _{Esperar ack}

Esperar resultado Retornar

Confirmar Utilizador RPC

Máquina Cliente Máquina do Servidor

memorizar a msg Confirmar Esperar pelo próximo pacote Chamar a função Confirmar Enviar resultado _{Esperar ack}

Retransmitir _{Esperar ack}

Executar função Retornar RPC Servidor Ack[CallID, Pkt=0] Data[CallID, Pkt=1, dontAck, ...] Ack[CallID, Pkt=1] Result[CallID, Pkt=2, dontAck, ...] Result[CallID, Pkt=2, pleaseAck, ...] Ack[CallID, Pkt=2] Data[CallID, Pkt=1, pleaseAck, ...]

(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

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

(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 mesma thread

ou

threads diferentes?

mesmo CallID base

Execução de RPCs:

(iv) Fluxos de execução alternativos

• 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 CLIENTE SERVIDOR Lançamento Recuperação CLIENTE SERVIDOR Lançamento Recuperação

(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

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

(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?

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

(25)

RPC - EXEMPLOS

Exemplos de RPC existentes no mercado

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

(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, …)

Objectivos

Máquina A Aplicação cliente Socket TCP ou UDP Socket TCP ou UDP Máquina B pedido resposta RPC stubs funcX(args); Aplicação servidora Socket TCP ou UDP Socket TCP ou UDP pedido resposta RPC stubs + dispatcher funcX(args); c o n n e c t Kernel Kernel

(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

Sun RPC:

Exemplo de IDL

• Identificação (nomes)

– Interface (n° programa, n° versão) (300030, 1)

– Função (Interface, n° função)

program BINOP {

version BINOP_VERS {

long BINOP_ADD ( struct input_args ) = 5; } = 1; } = 300030; struct input_args { long a; long b; };

(28)

Servidor

Sun RPC:

Serviço de Nomes e encaminhamento de RPCs

Máquina A cliente Máquina B servidor rpcbind Cliente stub stub call( binding handle n° interface, n° função, parâmetros) _transporte porto 111 porto de transporte

registo(n° interface, porto de transporte) procura (n° interface, transporte)

despacho da interface

operação

XID (op. id) RPC version n° interface n° função autenticador parâmetros XID RPC error resultados pedido resposta

Diagrama de ficheiros

Makefile Sample Makefile calc_clnt.c calc_clnt.c Client stubs calc_srv.c Server stubs & dispatcher calc.h Definições Protótipos Definições Tipos Protótipos Client source files Server source files calc.x Service Interface rpcgen calc_xdr.c marshaling XDR marshaling #include

(29)

rpcgen:

definição e compilação da interface

calc.x

calc_clnt.c

calc_clnt.c calc_svc.c calc_xdr.c

Sample client Sample server Sample Makefile rpcgen -C

rpcgen -Sc rpcgen -Ss rpcgen -Sm

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; }; programCALC_PROG { versionCALC_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; } =100400;

Diagrama de ficheiros (cont.)

,...) calc_result ∗∗∗∗ sum_1(calc_args ∗∗∗∗,...) {...} calc_srv.c main(...) { ... svc_run(); } calc_prog_1(...) {...} calc.h ,...); typedef ...calc_result; typedef ...calc_args; calc_result ∗∗∗∗ sum_1(calc_args ∗∗∗∗,...); calc_result ∗∗∗∗ sum_1_svc(calc_args ∗∗∗∗,...); calc.x calc_result sum(calc_args) ... VERSION=1 rpcgen -C ,...) calc_result ∗∗∗∗ sum_1_svc(calc_args ∗∗∗∗,...) {...} main(...) {...} calc_clnt.c calc_clnt.c calc_xdr.c () xdr_calc_result() {...} xdr_calc_args() {...}

(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; }; programCALC_PROG { versionCALC_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; } =100400; calc_xdr.c 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); } rpcgen -C

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; }; programCALC_PROG { versionCALC_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;

} =100400;

calc_clnt.c calc_clnt.c#include "calc.h”

static struct timeval TIMEOUT = { 25, 0 };

, &clnt_res, TIMEOUT) != RPC_SUCCESS) {

} } #include "calc.h”

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) { 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* rpcgen -C

(31)

Exemplo: Ficheiro banco_svc.c

Gerado pelo rpcgen

#include <stdio.h> #include <rpc/rpc.h> #include "banco.h" static void bancoprog_1(); main()

{

register SVCXPRT *transp;

(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 */ }

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; 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; }

(32)

DCE RPC:

Exemplo de IDL

• 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 [ uuid522fd85c-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 ); };

HTTP

Um exemplo de um protocolo cliente servidor mas que não é um RPC genérico

(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

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 Descrição

GET Pedido de documento

HEAD Pedido apenas de cabeçalho de documento

PUT Pedido para guardar um documento

POST Fornecimento de

informação para ser acrescentada ao documento

DELETE Pedido para apagar um documento

(34)

Mensagem de Pedido

GET /somedir/page.html HTTP/1.1

Host:

www.someschool.edu

Connection: close

User-agent: Mozilla/4.0

Accept-language: fr

Formato genérico da mensagem de pedido

Request line

Header lines

method sp URL sp Version cr lf

Header field name: sp value cr lf

Header field name: sp value cr lf cr lf

Blank line Entity body

(35)

Mensagem de Resposta

HTTP Response Message

HTTP/1.1 200 OK

Connection: close

Date: Thu, 03 Jul 2003 12:00:15 GMT

Server: Apache/1.3.0 (Unix)

Last-Modified: Sun, 5 May 2003 09:23:24

GMT

Content-Length: 6821

Content-Type: text/html

(data data data data data ... )

Formato genérico da mensagem de resposta

Status line

Header lines

version sp status code SP phrase cr lf Header field name: sp value cr lf

Header field name: sp value cr lf cr lf

Blank lines Entity body

(36)

Capítulo 3: Chamadas de Procedimentos Remotos