Capítulo 3: Chamadas de Procedimentos Remotos

Transcrição

1 Capítulo 3: Chamadas de Procedimentos Remotos 1

2 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 2

3 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 3

4 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 ) { } 4

5 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 5

6 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 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 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 6

7 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) cliente serverfunc ( ); clientstub ( ) { } serverstub ( ) { } servidor serverfunc ( ) { } 7

8 Arquitectura do sistema de RPC: Blocos funcionais das aplicações Departamento de Engenharia Informática 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 8

9 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 9

10 A Visão da Programação do RPC LINGUAGEM DE DESCRIÇÃO DE INTERFACES - IDL 10

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 11

12 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

13 IDL: Parâmetros Quais os parâmetros de entrada/saída da seguinte função? int transfere(int origem, int destino, int valor, int *saldo, char *descr); 13

14 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 14

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

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

17 Exemplo: IDL Sun RPC Ficheiro banco.x Departamento de Engenharia Informática 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 ; 17

18 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; 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, 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

19 Protocolos e Serviços necessário para suportar o RPC HETEROGENEIDADE E NOMES 19

20 Heterogeneidade Nos sistemas distribuídos a heterogeneidade é a regra Os formatos de dados são diferentes Nos processadores (ex.: little endian, big endian, apontadores, vírgula flutuante) Nas estruturas de dados geradas pelos compiladores Nos sistemas de armazenamento (ex: strings ASCII vs Unicode) Nos sistemas de codificação 20

21 Marshalling As redes transmitem bytes entre as máquinas Necessário serializar objectos em memória para sequência de bytes Des-serializar sequência de bytes para objectos na máquina destino Máquinas representam tipos de formas diferentes É necessário traduzir entre representação de tipos do emissor e representação de tipos do receptor Marshalling: serializar + traduzir Unmarshalling: operação inversa

22 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. 22

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 23

24 Protocolos de Apresentação XDR (external Data Representation) NDR (Network Data Representation) ASN.1 (Abstract Syntax Notation) CDR (Common Data Representation) Java Object Serialization XML (Extensible Markup Language) Sun RPC DCE RPC Microsoft RPC OSI CORBA Java RMI W3C Conversão Canónica O-receptorconverte Canónica O-receptorconverte Canónica Canónica Estrutura das msgs. Implícita Binária Implícita Binária Explícita Tagged Binária Implícita Binária Explícita Binária Explicita Tagged Textual Comprimento s de vectores variáveis Alinhamento a 32 bits (excepto vectores de caracteres) Marcas arquitecturais (architecture tags) Encoding Rules: Basic Distinguished Canonical Packed Tipos de Documentos DTD XML schema 24

25 Caso de estudo: extensible Markup Language - XML Resolver a heterogeneidade na comunicação e nos dados de forma universal

26 XML Formato canónico Estrutura explícita Textual

27 extensible Markup Language O XML deriva de uma linguagem muito mais antiga para definição do formato de impressão de documentos o SGML. O SGML já tinha sido a tecnologia de base no desenvolvimento do HTML. Essencialmente o XML permite através de etiquetas (tags) associar a descrição do formato aos dados de um documento. Toda a descrição é textual o que resolve muito dos problemas de portabilidade. O XML é uma proposta do W3C e é percepcionado como o substituto dos formatos anteriores de representação de dados como o EDI

28 Importância do XML O XML trabalha sobre documentos Os documentos podem ser usados para múltiplos fins: Representar/apresentar a informação num forma visível: em papel ou transformada para html Comunicação de dados entre plataformas heterogéneas Para armazenamento da informação em ficheiros ou em bases de dados 28

29 Sintaxe XML Regras de construção simples mas rígidas: Existe um elemento raiz único Todos os elementos têm que fechar Fecham pela ordem inversa em que abrem Os nomes são case-sensitive Um documento que respeita as regras dizse bem formado (well formed) Adicionalmente, pode-se definir uma gramática para validar documentos XML Que sequências de elementos são válidas Que tipo de dados contém o elemento Exemplo de uma estrutura de dados em XML <person id=" "> <name>smith</name> <place>london</place> <year>1934</year> <!-- a comment --> </person >

30 Exemplo de uma estrutura de dados em XML <?xml version= 1.0 encoding = UTF-8?> <! este documento define uma lista de empregados --> <employeelist xmlns=" > <employee type= contract > <employee_id>75868</employee_id> <name> <first_name>john</first_name> <last_name>doe</last_name> </name> <extn>27304</extn> <dept> </dept> < >john.doe@flute.com</ > </employee> </employeelist> employeelist Namespace Permite a unicidade de nomes e resolver colisões. Os Espaços de nomes são normalmente associados a um domínio de aplicação Um nome torna-se único por associação a um URI A inclusão de um URL no nome de dominio serve apenas para garantir que é uma cadeia de caracteres única no mundo, não serve para obter nenhum documento pela rede 30

31 Múltiplos espaços de nomes possíveis no mesmo documento

32 Benefícios do XML Tecnologia não proprietária Independente das plataformas o formato é texto Compatível com o HTTP O XML tem uma sintaxe mais restritiva que o HTML, mas pode ser usado como o HTML pelo que passa pelas firewalls Internacional Formato texto que usa UTF-8 ou UTF-16 para representar os caracteres Extensível Novas tags podem ser adicionadas por necessidade de extensão. Para evitar duplicações existem namespaces a que um documento pode ser associado.

33 Benefícios do XML(II) A interpretação das mensagens depende de tags e não da posição do campo na mensagem Permite a transformação automática dos dados As transformações são especificadas usando XML Stylesheet Language Transformatiom (XSLT) Auto definida A estrutura de um documento XML tem uma meta-descrição com base Document Type Definition (DTD) ou actualmente com XML schema Ferramentas genéricas Ferramentas Open Source em Java e ferramentas já existentes para SGML.

34 Tecnologia XML 34

35 Tecnologia XML Xpath Define um mecanismo de acesso a elementos dentro de um documento XML Xlink Mecanismo para indexar outros documentos semelhantes aos hiperlinks do HTML mas mais robusto XSL XML style sheet- documentos XML que definem transformações de documentos em XML DOM - Document Object Model O DOM define os métodos para aceder a um documento XML. Pressupõe que o documento é carregado em memória e que através de uma API se acede aos diferentes elementos SAX - Simple API for XML O SAX é um parser que invoca funções à medida que encontra elementos no documento

36 Exemplo simples mensagem Com definição de namespace Departamento de Engenharia Informática <person pers:id=" " xmlns:pers = " <pers:name> Smith </pers:name> <pers:place> London </pers:place > <pers:year> 1934 </pers:year> </person>

37 Exemplo simples mensagem Com definição de namespace Departamento de Engenharia Informática <mensagem xmlns="urn:empresa.pt:mensagem" id="74536"> <!-- isto é um comentário --> <de>joão</de> <para>carla</para> <assunto>reunião</assunto> <texto>confirmo a reunião dia 6</texto> </mensagem>

38 extensible Stylesheet Language (XSL) Permite: Transformar XML em HTML Transformar XML noutro XML Filtrar e ordenar dados XML Apresentar o mesmo documento de formas diferentes dependendo do dispositivo de destino (ecrã, impressão, telefone móvel, etc.)

39 JAM1 JAM2 Departamento de Engenharia Informática Esquema do Documento A especificação de documentos era inicialmente efectuada em DTD Document Type Definition Em 2001 foi proposto o XML Schema Estende as capacidades do DTD mas cuja principal vantagem é ter uma sintaxe XML que o DTD não tinha Um parser usando um DTD ou XML Schema pode verificar se o documento está sintacticamente correcto e se está conforme com um determinado tipo A meta-descrição pode ser incluída no documento, mas a utilização mais interessante é poder aceder-lhe através de um URI partilhando-o entre aplicações

40 Slide 39 JAM1 Situar o DTD Identificar as deficiencias Jose Alves Marques; JAM2 Aula 7 Jose Alves Marques;

41 Comparação XML Schema e DTD DTD era anterior ao XML pelo que não suporta bem alguns aspectos da norma como por exemplo os namespaces O DTD tinha por objectivo descrever documentos legíveis por humanos e não documentos para representar dados, por conseguinte faltam-lhe alguns construções para exprimir diversas restrições simples, ex.: idade só pode ter um valor não negativo entre 0 e 150 A sintaxe do DTD não é a do XML o que torna mais complexas as ferramentas 2009 José Alves Marques

42 XML Schema Define Elementos obrigatórios e proibidos Estrutura hierárquica dos elementos Que elementos são elementos filhos Qual a ordem dos elementos filhos Qual a cardinalidade - o número de elementos filhos atributos 'minoccurs' e 'maxoccurs' Se um elemento é vazio ou pode conter texto Atributos necessários ou opcionais dos elementos Tipos de dados para elementos e atributos Valores fixos ou por omissão para elementos e atributos Restrições aos valores possíveis para um elemento ou atributo Referências de parte de um documento a outros elementos do documento A principal utilidade do XSD é permitir validar automaticamente documentos XML, sem necessidade de escrever um programa para o efeito.

43 DTD Simples para o documento employeelist Departamento de Engenharia Informática <!DOCTYPE employeelist [ <!ELEMENT employeelist (employee*)> <!ELEMENT employee (employee_id, name, extn, dept, )> <!ATTLIST employee type (perm contract) #REQUIRED> <!ELEMENT employee_id (#PCDATA)> Element employeelist consists of zero or more employee elements. NOTE: * = zero or more,? = zero or one, + = one or more Element employee contains elements employee_id, name, dept, and . Attribute type for element employee is required and must have either of these two values: contract or perm. <!ELEMENT NAME (first_name, last_name)> <!ELEMENT first_name (#PCDATA)> <!ELEMENT last_name (#PCDATA)> <!ELEMENT extn (#PCDATA)> <!ELEMENT dept (#PCDATA)> <!ELEMENT (#PCDATA)> ]> Sintaxe próxima das expressões regulares Element dept. may contain any parsable character data (PCData).

44 XML schema para a estrutura de dados Person <xsd:schema xmlns:xsd = URL of XML schema definitions > <xsd:element name= "person" type ="persontype" /> <xsd:complextype name="persontype"> <xsd:sequence> <xsd:element name = "name" type="xs:string"/> <xsd:element name = "place" type="xs:string"/> <xsd:element name = "year" type="xs:positiveinteger"/> </xsd:sequence> <xsd:attribute name= "id" type = "xs:positiveinteger"/> </xsd:complextype> </xsd:schema>

45 Exemplo de XML Schemas mais elaborado </xml version= 1.0 encoding= UTF-8?> <xsd:schema xmlns:xsd= targetnamespace= xmlns= > <xsd:element name= employeelist > <xsd:complextype> <xsd:sequence> <xsd:element ref= employee minoccurs= 1 maxoccurs= unbounded /> <xsd:seuqence> </xsd:complextype> </xsd:element> <xsd:element name= employee <xsd:complextype> <xsd:sequence> <xsd:element ref= employee_id minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= name minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= extn minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= dept minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= minoccurs= 1 maxoccurs= 1 /> </xsd:sequence> <xsd:attributegroup ref= employeeattribute /> </xsd:comlextype> </xsd:element> <xsd:element name= name <xsd:complextype> <xsd:sequence> <xsd:element ref= first_name minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= last_name minoccurs= 1 maxoccurs= 1 /> <xsd:sequence> </xsd:complextype> </xsd:element> 2009 José Alves Marques Namespace declaration <!ELEMENT employeelist (employee*)> <!ELEMENT employee (employee_id, name, extn, dept, )> <!ELEMENT name (first_name, last_name)>

46 <xsd:element name= employee_id > <xsd:simpletype> <xsd:restriction base= xsd:int > <xsd:minlnclusive value= 1 /> <xsd:maxlnclusive value= /> <xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name= first_name type= xsd:string /> employee:_id must be an integer between 1 and 100,000. <!ELEMENT first_name (PCDATA)> <xsd:element name= last_name type= xsd:string /> <xsd:element name= type= xsd:string /> <xsd:element name= dept > <xsd:simpletype> <xsd:restriction base= xsd:string> <!ELEMENT (PCDATA) Department must be specified in the form: <xsd:pattern value= [0-9]{3}-[0-9]{3}-[0-9]{4} /> </xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name= extn > <xsd:simpletype> <xsd:restrition base= xsd:string > <xsd:pattern value= [0-9]{5} /> </xsd:restrition> </xsd:simpletype> </xsd:element> <xsd:attributegroup name0 employeeattribute > <xsd:attribute name= type use= required > <xsd:simpletype> <xsd:restriction base= xsd:string > <xsd:enumerator value= contract /> Extension must be specified in the form (String consisting of five digits). <!ATTLIST employee type (permicontract) #REQUIRED>

47 Tecnologia XML 46

48 SAX Simple API for XML Processamento em série Baseado no tratamento de eventos

49 Quando usar Quando pretendemos processar informação em série (data stream). A informação a processar não precisa de manter estado. Importação/exportação de dados

50 DOM - Document Object Model Manipulação de árvore em memória

51 Set Compiled Schema on DocumentBuilder/SAXParserFactory 8/28/2003 José Alves Marques

52 Ligação entre o Cliente e o Servidor LIGAÇÃO OU BINDING 51

53 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 N1 52

54 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 53

55 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 54

56 Etapas da ligação (binding) cliente-servidor Localização Indicação directa de um porto de transporte máquina + porto TCP/IP Utilização de um serviço de nomes, ex.: NFS máquina + porto TCP/IP NFS@algures Autenticação Identificação fidedigna do utente cliente ou do serviço/servidor Username + password Estabelecimento de um canal Criação de um canal de transporte Criação de referências (handles) que permitam identificar o canal 55

57 Referências de sessão binding handles Cliente Criação do binding handle no extremo cliente Servidor Identifica um canal de comunicação ou um porto de comunicação para interactuar com o 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 56

58 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 57

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

60 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 59

61 Aspectos importantes a analisar 1. Transparência 2. Semântica de Execução 1. Protocolo de controlo 3. Multitarefas e RPC 60

62 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 61

63 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 62

64 Algumas faltas possíveis cliente t reenvio servidor cliente t servidor início cliente t servidor cliente servidor reenvio início reenvio 63

65 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) 64

66 Arquitectura do sistema de RPC: Semânticas de execução Departamento de Engenharia Informática 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 65

67 Arquitectura do sistema de RPC: Semânticas de execução Departamento de Engenharia Informática 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? 66

68 Resumo de técnicas para cada semântica Fault tolerance measures Invocation semantics Retransmit request message Duplicate filtering Re-execute procedure or retransmit reply No Not applicable Not applicable Maybe Yes No Re-execute procedure At-least-once Yes Yes Retransmit reply At-most-once E no caso da semântica exactamente-uma-vez?

69 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) 68

70 Protocolo de RPC Situação Ideal Departamento de Engenharia Informática Máquina do Cliente Utilizador RPC Chamada Enviar pacote Esperar ack ou resultado Call [CallID, procedimento, argumentos] Máquina do Servidor RPC Servidor Invocar função Executar função Retornar Resultado[CallID, resultados] Enviar resultados Retornar Apenas são utilizadas duas mensagens 69

71 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 70

72 RPC sobre UDP ou TCP? Vantagens do uso de TCP Possibilidade de envio de parâmetros de tamanho arbitrário Datagrams UDP limitados a 8KBytes, tipicamente Envio de parâmetros maiors que 8KB implica protocolo RPC multipacote mais complexo de implementar TCP já assegura entrega fiável de pedido/resposta, tornando RPC mais simples Qual a semântica oferecida por um RPC sobre TCP? Mecanismos de controlo de fluxo do TCP adequados para envio de parâmetros de grande dimensão Vantagens do uso de UDP Evita tempo de estabelecimento de ligação TCP Quando os aspectos acima não são relevantes, envia mensagens mais eficientemente

73 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 Departamento de Engenharia Informática 72

74 Execução de RPCs: (ii) Fluxos de execução simples Departamento de Engenharia Informática 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 73

75 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 mesmocallid base 74

76 Execução de RPCs: (iv) Fluxos de execução alternativos Departamento de Engenharia Informática Lançamento Recuperação Lançamento Recuperação CLIENTE CLIENTE 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 75

77 Execução de RPCs: (v) Fluxos de execução alternativos Departamento de Engenharia Informática 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 76

78 Execução de RPCs: (vi) Fluxos de execução alternativos Departamento de Engenharia Informática 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 77

79 Execução de RPCs: (vii) Fluxos de execução alternativos Departamento de Engenharia Informática 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? 78

80 Execução de RPCs: Desempenho Departamento de Engenharia Informática 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 79

81 Exemplos de RPC existentes no mercado RPC - EXEMPLOS 80

82 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 81

83 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, ) 82

84 Objectivos Máquina A Aplicação cliente funcx(args); RPC stubs Máquina B Aplicação servidora funcx(args); RPC stubs + dispatcher pedido resposta pedido resposta Kernel Socket TCP ou UDP Kernel Socket TCP ou UDP connect 83

85 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 84

86 Sun RPC: Exemplo de IDL Departamento de Engenharia Informática 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) 85

87 Sun RPC: Serviço de Nomes e encaminhamento de RPCs Departamento de Engenharia Informática Máquina A cliente porto de transporte rpcbind procura (n interface, transporte) Máquina B porto 111 registo (n interface, porto de transporte) servidor pedido resposta Cliente XID (op. id) RPC version XID RPC error Servidor n interface resultados stub n função call ( binding handle n interface, n função, parâmetros) autenticador parâmetros transporte despacho da interface stub operação 86

88 rpcbind: registo e procura de serviços (servidores) Departamento de Engenharia Informática Máquina A Program number Version number Transport P. IP address Máquina B Program number Version number Transport P. Port cliente rpcb_getaddr() RPC run-time library servidor rpcb_set() rpcb_unset() RPC run-time library rpcbind (portmap) 87

89 Interface de mais alto nível Máquina A Program number Version number Transport Ps. Host name Máquina B Program number Version number Transport Ps. RPC dispatcher cliente clnt_create() RPC run-time library servidor svc_create() RPC run-time library svc_destroy() rpcbind (portmap) 88

90 Diagrama de ficheiros calc.x Service Interface calc_clnt.c 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 89

91 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.c 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; calc_result MUL(calc_args) = 3; calc_result DIV(calc_args) = 4; } = 1; } = ; Sample client Sample server Sample Makefile 90

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

93 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; } = ; Funções de conversão calc_xdr.c para cada tipo definido no IDL #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); } Chamadas a funções de conversão de tipos base (oferecidas na biblioteca run-time do SUN RPC) 92

94 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 Função genérica de chamada de procedimento remoto (da biblioteca de run-time) 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) {...} 93

95 #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 Departamento de Engenharia Informática (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 */ Cria porto UDP Associa nome da interface e função de despacho ao porto Função de despacho Faz o mesmo para porto TCP Lança ciclo de espera de pedidos Quando chegar algum pedido, svc_run() chama a função de despacho 94

96 Função de despacho 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; } Departamento de Engenharia Informática case PEDIREXTRATO: xdr_argument = xdr_pedirextratoin; xdr_result = xdr_pedirextratoret; local = (char *(*)()) pedirextrato_1; break; Função genérica para obter argumentos (da biblioteca de run-time) 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; Função genérica para enviar resposta (da biblioteca de run-time) 95

97 DCE RPC: Exemplo de IDL Departamento de Engenharia Informática [ 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 96

98 DCE RPC: Serviço de Nomes Departamento de Engenharia Informática Cada servidor é identificado por um UUID Diferente do UUID da sua interface O registo e a procura de servidores (do seu porto de transporte) usa os serviços de nomes do DCE: CDS (Cell Directory Service) GDS (X.500 Global Directory Service) Registo e procura de nomes nome lógico (int. UUID + versão, obj. UUID, portos de transporte) procura ( nome lógico, int. UUID + versão, transportes) (obj. UUID, porto) 97

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

100 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 99

101 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 100

102 Mensagem de Pedido GET /somedir/page.html HTTP/1.1 Host: Connection: close User-agent: Mozilla/4.0 Accept-language: fr 101

103 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 102

104 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... ) 103

105 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 104

106 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 105