Projecto hipotético para resolvermos hoje

(1)

Projecto hipotético para

resolvermos hoje

12/13 Sistemas Distribuídos 1

Departamento de Engenharia Informática

Projecto hipotético para resolvermos hoje

• Implementar servidor de contagem que mantém

contador e oferece estas operações aos clientes:

– Colocar contador a zero

– Avançar o contador em x unidades – Consultar valor actual do contador

• Requisitos adicionais:

– Rede não é fiável

• mensagens perdem-se, etc

– Sistema heterogéneo

• Servidor e clientes representam inteiros de forma diferente

(2)

Tentemos implementar isto com

sockets...

(3)

Como executar cada operação?

Protocolo RR

12/13 Sistemas Distribuídos 5 Request Message Servidor Cliente doOperation (espera) (continua) Reply Message getRequest Executa operação sendReply

Vamos escolher TCP ou UDP?

• Vantagens do TCP

– Oferece canal fiável sobre rede não fiável

• Mas talvez seja demasiado pesado. Porquê?

– Para cada invocação remota passamos a precisar de

mais 2 pares de mensagens

– Gestão de fluxo é redundante para as invocações

simples do nosso sistema

– Acknowledges nos pedidos são desnecessários

• Logo optemos por UDP!

(4)

O que levam as mensagens de

pedido/resposta?

Identificador do

pedido

Identificador da

operação

Argumentos/retorno

Booleano

(pedido ou resposta)

Id Cliente + número

sequencial

Limpa=0

Incrementa=1

Consulta=2

Serializados em

sequência de bytes

Como serializar os argumentos/retorno?

• Necessário:

– Converter estruturas de dados para sequência de

bytes

– Encontrar forma de emissor e receptor

heterogéneos interpretarem dados correctamente

• Por exemplo: serializar em “formato de rede”

(5)

Modelo de faltas

• Usando UDP para enviar mensagens, estas

podem:

– Perder-se

– Chegar repetidas

– Chegar fora de ordem

• Processos podem falhar silenciosamente

• Como lidar com isto?

Timeout no cliente

• Situação: cliente enviou pedido mas resposta

não chega ao fim do timeout

• O que deve o cliente fazer?

• Hipótese 1: Cliente retorna erro.

– Pouco interessante...

• Hipótese 2: Cliente re-envia pedido

– Repete re-envio até receber resposta ou até número

razoável de re-envios

(6)

Timeout no cliente com re-envio

• Quando a resposta chega após re-envio, o que

pode ter acontecido?

12/13 Sistemas Distribuídos ∆t cliente servidor reenvio ∆t reenvio cliente servidor ∆t cliente servidor início reenvio Operação executada 2x!

Operação pode ter sido executada 2x! Se não houver garantia de atomicidade (transacções), caso ainda pode ser pior...

Execuções repetidas do mesmo pedido:

Qual o problema?

• Perde-se tempo desnecessário

• Efeitos inesperados se operação não for

idempotente

• Função limpa é idempotente?

• Função incrementa é idempotente?

Operação que, se executada repetidamente, produz

mesmo resultado que se só executada 1 vez

(7)

Execuções repetidas do mesmo pedido:

Como evitar?

• Servidor deve ser capaz de verificar se

id.pedido já foi recebido antes

• Se é a primeira vez, executa

• Se é pedido repetido?

– Deve guardar história de respostas de pedidos

executados

• Tabela com (id.pedido, resposta)

– E retornar a resposta correspondente

Quantos pedidos manter por cliente?

Como escalar para grande número de clientes?

Outros protocolos de invocação remota

R Request

RR Reply

RRA Acknowledge reply

Request

Request Reply

Client Server Client

Name Messages sent by

Quando não há retorno e cliente não precisa de confirmação Acknowledge permite ao servidor descartar resposta

(8)

E se as mensagens forem maiores que um

datagrama UDP?

• Podemos usar variante multi-pacote dos

protocolos anteriores…

– Implica implementar protocolo complicado

• Ou usar TCP!

– Boa opção quando tamanho dos pedidos/respostas

pode ser arbitrariamente grande

• Exemplo: HTTP

– Nesse caso, implementaçao é mais simples pois TCP

já assegura fiabilidade da comunicação

– Como evitar o custo de estabelecimento de ligação?

• Exemplo: HTTP versão 1.1.

Projecto hipotético para resolvermos hoje

• Implementar servidor de contagem que mantém

contador e oferece estas operações aos clientes:

– Colocar contador a zero

– Avançar o contador em x unidades – Consultar valor actual do contador

• Requisitos adicionais:

– Rede não é fiável

• mensagens perdem-se, etc

– Sistema heterogéneo

(9)

Capítulo 3: Chamadas de

Procedimentos Remotos

17

Chamada de Procedimentos Remotos – RPC

-Remote Procedure Call

• Modelo de programação da comunicação num

sistema cliente-servidor

• Objectivo: Tornar a programação distribuída

semelhante à programação convencional

• Estrutura a programação distribuída com base

na chamada pelos clientes de procedimentos

que se executam remotamente no servidor

(10)

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

21

Caso de estudo: Sun RPC

(11)

Exemplo de RPC: SUN RPC

• 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, Linux, Windows, etc

– C (linguagem original) mas também C++, Java, .Net,..

• Actualmente, também chamado ONC RPC

23

24

Sun RPC

1º passo: definição da interface remota

• 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

(12)

25

Sun RPC

1º passo: definição da interface remota

• Identificação (nomes)

– Interface _{(n° programa, n° versão)}

(300030, 1)

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

(300030, 1, 2)

program COUNTER {

version COUNTER_VERS { void clean (int) = 0; void inc (int) = 1; int read (int) = 2; } = 1;

} = 300030;

Sun RPC

2º passo: geração de stubs, etc

Makefile Sample Makefile counter_clnt.c counter_clnt.c Client stubs counter_srv.c counter_srv.c Server stubs & dispatcher counter.h Definições Protótipos Definições Tipos Protótipos Client source files Server source files counter.x Service Interface rpcgen counter_xdr.c counter_xdr.c marshaling XDR marshaling #include

(13)

Sun RPC:

3º passo: implementar procedimentos

void *

clean_1_svc(int *argp, struct svc_req *rqstp) {

static char * result;

/* * insert server code here */

return (void *) &result; }

Sun RPC:

4º passo: implementar cliente

clnt = clnt_create(host,COUNTERS,COUNTERS_VERS,"udp"); if (clnt == NULL) {...} ... result_3 = read_1(&read_1_arg, clnt); if (result_3 == NULL) {...} 12/13 Sistemas Distribuídos 28

(14)

Linguagem de Descrição de interfaces

-IDL

A Visão da Programação do RPC

29

RPC IDL: Características

• Linguagem própria

• Permite definir

– Tipos de dados

– Protótipos de funções

• Fluxo de valores (IN, OUT, INOUT)

– Interfaces

• Conjuntos de funções

(15)

32

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

33

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

(16)

35

IDL:

Soluções para alguns dos problemas

• Só se permite passagem por valor

– Se pretendíamos passar variável por referência, devemos definir como parâmetro de entrada e de saída

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