Capítulo 3: Chamadas de Procedimentos Remotos

(1)

3/6/2005 José Alves Marques 1

Capítulo 3: Chamadas de Procedimentos

Remotos

Departamento de Engenharia Informática

Resumo da aula anterior

• Redes de comunicação

• Programação da comunicação

– API de comunicação permite aceder directamente ao

nível transporte

(2)

Sockets sem Ligação

socket bind recvfrom sendto socket bind sendto recvfrom Servidor Cliente

Sockets UDP em Java (Cliente)

import java.net*; import java.io*; public class UDPClient{

public static void main(String args[]){

// args give message contents and server hostname DatagramSocket aSocket = null;

try {

aSocket = new DatagramSocket(); byte [] m = args [0].getBytes();

InetAddress aHost = InetAddress.getByName(args[1]); Int serverPort = 6789;

DatagramPacket request =

new DatagramPacket(m, args[0].length(), aHost, serverPort); aSocket.send(request);

byte[]buffer = new byte[1000];

DatagramPacket reply = new DatagramPacket(buffer, buffer.length); aSocket.receive(reply);

System.out.println(“Reply:” + new String(reply.getData())); } catch (SocketException e){System.out.println(“Socket:” +

e.getMessage());

} catch (IOException e){System.out.println(“IO:” + e.getMessage());

Conversão do nome DNS para endereço IP

Constrói um socket datagram (associado a qualquer porto disponível)

(3)

Sockets UDP em Java (Servidor)

import java.net*; import java.io*; public class UDPServer{

public static void main(String args[]){ DatagramSocket aSocket = null;

try{

aSocket = new DatagramSocket(6789);

byte[] buffer = new byte [1000]; while(true){

DatagramPacket request = new DatagramPacket(buffer, buffer.legth);

aSocket.receive(request);

DatagramPacket reply = new DatagramPacket(request.getData(), request.getLength(); request.getAddress(),

request.getPort()); aSocket.send(reply);

}

} catch (SocketException e){System.outprintln(“Socket:”+ e.getMessage());

} catch (IOException e){System.out.println(“IO:” + e.getMessage()); } finally {if(aSocket ! = null) aSocket.close();}

} }

Constrói um socket datagram (associado ao

porto 6789)

Sockets com Ligação

socket bind listen socket connect accept read write read write Cliente Servidor

(4)

Sockets Stream em Java (Cliente)

import java.net*;

import java.io*; public class TCPClient{

public static void main(String args[]){ // args: message and destin. hostname

Socket s = null; try{

int server Port = 7896;

s = new Socket (args[1], serverPort);

DataInputStream = new DataInputStream(s.getInputStream()); DataOutputStream out =

newDataOutputStream (s.getOutputStream()); out.writeUTF(args[0]);

String data = in.readUTF();

System.out.prtintln(“Received: ” + data); }catch (UnknownHostException e){

System.out.println(“Sock:” + e.getMessage());

}catch (EOFException e){System.out.println(“EOF:”e.getMessage()); }catch (IOException e){System.out.println(“IO:”e.getMessage()); }finally {if(s!=null) try{s.close();}catch (IOException e} }

• classe Socket – suporta o socket cliente. Argumentos: nome DNS do servidor e o porto. • Construtor não só cria o socket como efectua a ligação

Métodos getInputStream / getOutputStream – permitem aceder aos dois streams definidos pelo socket WriteUTF / readUTF – para

Universal transfer format / para as cadeias de caracteres

Sockets Stream em Java (Servidor)

import java.net*; import java.io*; public class TCPServer{

public static void main(String args[]){ try{

int server Port = 7896;

ServerSocket listenSocket = new ServerSocket(serverPort); while(true){

Socket clientSocket = listenSocket.accept(); myConnection c = new myConnection(clientSocket); }

}catch (IOException e){System.out.println(“Listen:” +e.getMessage());}

} }

Bloqueia até cliente estabelecer ligação. Cria socket servidor

que fica à escuta no porto “serverPort”

(5)

Limitações das APIs de Nível Transporte

• Semântica de envio do tipo pedido resposta

– Garante que a operação se executou – fiabilidade

• Heterogeneidade

• Integração no ambiente de programação

– Esconder detalhes do protocolo de transporte

– Utilizar a capacidade das linguagens para tratar os tipos

de dados

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

(6)

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:

(7)

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

• 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

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 automático

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

Positivo

(8)

3/6/2005 José Alves Marques 15 Run-Time Library

Run-Time Library

Arquitectura do sistema de RPC:

Blocos funcionais das aplicações

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

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( … ) { … }

(9)

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

RPC: 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

• Terminação da sessão

(10)

RPC: 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

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

(11)

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

(12)

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

(13)

Exemplo: Interface em C

Resul = criar (long valor,char* nome,char* morada,long* numero)

Resul = saldo (long nConta,long* valor); Resul = depositar (long nConta,long valor); Resul = levantar (long nConta,long valor);

Resul = transferir (long nContaOrig,long nContaDest,long valor);

Resul = pedirExtrato (long nConta,long mes,long ano, struct dadosOperacao* dados,int*

nElementos);

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)

(14)

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;

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;

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,

(15)

Aspectos a analisar

1. Transparência

2. Ligação – Binding

3. Semântica de Execução

4. Protocolo de Apresentação

5. Multitarefas e RPC

6. Biblioteca de 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

(16)

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

(17)

Ligação cliente-servidor

• Os binding handles podem ser usados pelos stubs de uma forma

– Explícita – Implícita – Automática

Obtém informação de ligação Guarda-a localmente e usa-a Usa a variável global

A função de stub tem um parâmetro de entrada que especifica o handle a usar na chamada

Stubcliente

(não necessária) Obtém informação de ligação

Guarda-a numa variável global Obtém informação de ligação

Usa-a explicitamente em cada RPC

Inicialização do Cliente

Automático (DCE RPC) Implícito (DCE RPC)

Explícito (Sun RPC, DCE RPC)

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

(18)

Algumas faltas possíveis

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

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)

(19)

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

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?

(20)

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)

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

(21)

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, ...]

(22)

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 apenas podem enviar

tipos básicos: caracteres, inteiros, reais, etc.

• As redes transmitem bytes entre as máquinas. Todos os

restantes tipos têm de ser serializados para os tipos básicos

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.

(23)

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

Explicita – Tagged Tipos de Documentos DTD XML schema Canónica W3C XML Extensible Markup Language Canónica O-receptor-converte Canónica Conversão OSI DCE RPC Microsoft RPC Sun RPC Implícita Marcas arquitecturais (architecture tags) NDR (Network Data Representation) Explícita - Tagged Encoding Rules: Basic (BER) Distinguished (DER) Canonical (CER) Packed (PER) Implícita Comprimentos de vectores variáveis Alinhamento a 32 bits (excepto vectores de caracteres) Estrutura das mensagens ASN.1 (Abstract Syntax Notation) XDR (eXternal Data Representation)

(24)

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

(25)

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

(26)

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

(27)

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

(28)

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

• Outros:

• CORBA (Common Object Request Broker Architecture)

• DCOM (Distributed Component Object Model)

• Java RMI (Remote Method Invocation)

• SOAP (RPC sobre HTTP e apresentação XML)

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

(29)

Objectivos

Máquina A Aplicação cliente Aplicação cliente Socket TCP ou UDP Socket TCP ou UDP Máquina B pedido resposta RPC stubs funcX(args); Aplicação servidora 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

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

(30)

Sun RPC:

Exemplo de IDL

• Identificação (nomes)

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

(300030, 1)

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

(300030, 1, 5)

program BINOP {

version BINOP_VERS {

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

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

(31)

Diagrama de ficheiros

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

rpcgen:

definição e compilação da interface

calc.x calc.x

calc_clnt.c

calc_clnt.c calc_svc.ccalc_svc.c calc_xdr.ccalc_xdr.c

Sample client Sample client Sample server Sample server Sample Makefile 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;

(32)

Diagrama de ficheiros (cont.)

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

Funções de conversão via XDR

calc.x

enum calc_error{

CALC_OK = 0, /* No error */ CALC_ZERO_DIV = 1 /* Div. by zero */ }; structcalc_args{ double v1; double v2; }; structcalc_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

(33)

Funções do cliente (stubs)

calc.x

calc.x enumcalc_error{

CALC_OK = 0, /* No error */ CALC_ZERO_DIV = 1 /* Division by zero */ }; structcalc_args{ double v1; double v2; }; structcalc_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 }; 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 *

div_1(calc_args *argp, CLIENT *clnt) {...}

#include "calc.h”

static struct timeval TIMEOUT = { 25, 0 };

calc_result *

sum_1(calc_args*argp, CLIENT *clnt) {

static calc_resultclnt_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*

div_1(calc_args*argp, CLIENT *clnt) {...}

rpcgen -C

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

(34)

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

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

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

(35)

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 Pedido para apagar um documento

DELETE

Fornecimento de informação para ser acrescentada ao documento POST

Pedido para guardar um documento PUT

Pedido apenas de cabeçalho de documento HEAD Pedido de documento GET Descrição Método

Capítulo 3: Chamadas de Procedimentos Remotos