UNIVERSIDADE. Sistemas Distribuídos

Transcrição

1 UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Comunicação Inter-Processos Representação Externa de Dados e Marshalling

2 Representação externa de dados Informações armazenadas em programas são representadas como uma estrutura de dados Na transmissão de informações, as informações são representadas numa seqüência de bytes Necessidade de conversão: estrutura de dados < > seqüência de bytes Problema Solução Diferentes sistemas possuem diferentes estruturas de dados Ex: Código ASC x UNICODE, big endian x little endian, formatos de ponto flutuante etc. Conversão para um formato de dados de comum acordo (external Data Representation XDR) Enviar no formato do emissor e incluir informação sobre o formato empregado

3 Representação externa de dados

4 Representação externa de dados Formato independente de linguagem, SO etc Utilizada para comunicação dos dados de requisições e respostas entre clientes e servidores Formato serializado Marshalling: conversão entre a representação interna e externa CORBA Common Data Representation Serialização de objetos em Java XML (Extensible Markup Language)

5 Marshalling (Empacotamento) Processo de converter uma coleção de dados e organizá-los em um formato próprio para transmissão Unmarshalling é o processo oposto Ideal não haver o envolvimento explícito da aplicação (transparência) Responsabilidade do middleware Duas técnicas básicas Conversão dos dados para um formato binário Conversão dos dados para um formato texto (ASC II) Serialização Java e XML

6 CORBA CDR Representação para tipos primitivos inteiros, ponto flutuante, octeto big-endian e little-endian posicionamento de cada item de dados na msg. Representação para tipos construídos seqüência, string, array, struct, enumeração, união construída a partir das seqüências de bytes correspondentes aos tipos primitivos constituintes Informação de tipo: subentendida através da definição das operações em IDL

7 Representação de tipos construídos em CORBA CDR Type sequence stri ng Repr esenta ti on length (unsi gned long) fo ll ow ed by elements i n order length (unsi gned long) fo ll ow ed by characters in o rder (can al so can have w i de characters) ar ra y stru ct enumer ated uni on arr ay elem ents i n order ( no l ength speci f ied b ecause i t is fi xed) in t he or der o f declarati on o f the comp onents unsigned l ong (the v al ues are specif ied by t he order d ecl ared) ty pe tag f ol lowe d b y the selected m emb er

8 Mensagem em CORBA CDR index in sequence of bytes bytes 5 "Smit" "h " 6 "Lond" "on " 1934 notes on representation length of string Smith length of string London unsigned long The flattened form represents a Person struct with value: { Smith, London, 1934} struct Person { string name; string city; unsigned long year; };

9 Marshalling em CORBA O código gerado automaticamente a partir das definições em IDL das operações Converte os parâmetros e valores de retorno das operações Seguindo as regras de representação CORBA CDR Stub marshalling de parâmetros e unmarshalling do valor de retorno Skeleton: vice-versa

10 Inclusão de informações de tipo no Marshalling Se dados empacotados (marshalled) devem incluir informações de seus tipos Informar se o tipo, por exemplo, é int ou um array No caso de CORBA são incluídos apenas os valores Considera-se que o cliente já saibam os tipos dos dados e a ordem de chegada destes dados Entretanto, XML e Java inclui tanto os tipos quanto os próprios dados

11 Serialização em Java Transformação de um objeto Java para uma seqüência de bytes Informações de tipo e classe dos objetos são incluídas na forma serializada Permitem a reconstrução dos objetos sem conhecimento prévio de suas classes Processo recursivo: serializa todos os objetos referenciados pelo objeto em questão Classes precisam implementar a interface Serializable Objetos remotos: a referência é serializada

12 Serialização em Java Forma de disponibilização ao usuário Classes ObjectOutputSream e ObjectInputStream e seus respectivos métodos writeobject e readobject Classe do objeto implementa a interface Serializable Conteúdo do formato serializado Nome da classe Versão da classe (quando são feitas alterações na classe) Referências a outros objetos (handles) Valores das instâncias das variáveis

13 Formato de serialização Java Objetos (instância de uma classe Java) e valores de dados primitivos podem ser passados como argumentos e resultados de invocações de método Ex.: struct Person public class Person implements Serializable { } private String name; private String place; private int year; public Person(String aname, String aplace, int ayear) { name = aname; place = aplace; year = ayear; } // seguido dos métodos para acessar as vaiáveis de instância

14 Formato de serialização Java Serializando a instância de objeto Person: Person p = new Person( Smith, London, 1934); Serialized values Explanation Person 8-byte version number h0 class name, version number 3 int year java.lang.string name: java.lang.string place: number, type and name of instance variables Smith 6 London h1 values of instance variables O formato serializado na prática contém marcadores de tipos de dados adicionais h0 and h1 são handles

15 Formato de serialização Java Serialização e desserialização geralmente são operações feitas automaticamente pelo middleware Java oferece meios para o programador personalizar a serialização Exemplo é o uso da palavra-chave transient que serve para informar que uma variável não deve ser serializada Arquivos ou sockets

16 XML (Extensible Markup Language) Linguagem de marcação assim como HTML Definir documentos estruturados para a Web Os itens de dados são rotulados com strings de marcação Diferente do HTML, permite que os usuários definam suas próprias tags (Extensível)

17 XML (Extensible Markup Language) Usos de interesse aqui: definir a interface de serviços Web prover a representação externa de dados na comunicação entre clientes e serviços Representação textual: independente de plataforma Representação hierárquica Textual e Auto-descritiva: tags, esquemas e namespaces Desempenho inferior comparado com CORBA CDR

18 Definição da estrutura Pessoa em XML tag <person id=" "> <name>smith</name> <place>london</place> <year>1934</year> atributo <!-- a comment --> </person > elementos Atributos: rotular dados Elementos: container para dados

19 Namespaces Permitem definir contextos para os marcadores (tags) utilizados em um documento Referenciados através de URLs Evitam choques de nomes de tags em contextos diferentes As tags name, place e year podem ser usadas em diferentes documentos <person pers:id=" " xmlns:pers = " <pers:name> Smith </pers:name> <pers:place> London </pers:place > <pers:year> 1934 </pers:year> </person>

20 Esquemas XML Definem: os elementos e atributos que podem aparecer em documentos XML (i.e., um vocabulário) como os elementos são aninhados a ordem, o número e o tipo dos elementos Usados para validar documentos XML Um mesmo esquema pode ser compartilhado por vários documentos

21 Um esquema XML para a estrutura Pessoa 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>

22 Referências de Objetos Remotos Num sistema distribuído, um processo servidor pode conter vários objetos remotos Necessário uma maneira de identificar um objeto remoto de forma única dentro de um sistema distribuído Necessária quando objetos remotos são passados como parâmetro

23 Referências de Objetos Remotos Devem ser descartada quando o objeto remoto deixar de existir A referência é serializada (não o objeto) Deve conter toda informação necessária para identificar (e endereçar) um objeto unicamente no sistema distribuído. Ex.: hora da criação, nº da porta. 32 bits 32 bits 32 bits 32 bits Internet address port number time object number interface of remote object

24 Comunicação Cliente-Servidor Modelo geral: requisição-e-resposta Variantes: síncrona: cliente bloqueia até receber a resposta assíncrona: cliente recupera (explicitamente) a resposta em um instante posterior não sendo bloqueante Implementação sobre protocolo baseado em datagramas é mais eficiente evita: reconhecimentos redundantes, mensagens de estabelecimento de conexão, controle de fluxo

25 Protocolo requisição-e-resposta Client Server dooperation (wait) (continuation) Request message Reply message getrequest select object execute method sendreply

26 Operações utilizadas para implementar o protocolo de requisição-e-resposta public byte[] dooperation (RemoteObjectRef o, int methodid, byte[] arguments) envia uma mensagem de requisição para o objeto remoto e retorna a resposta. Os argumentos especificam o objeto remoto, o método a ser chamada e os argumentos para aquele método. public byte[] getrequest (); obtém uma requisição de um cliente através de uma porta servidora. public void sendreply (byte[] reply, InetAddress clienthost, int clientport); envia a mensagem de resposta para o cliente, endereçando-a a seu endereço IP e porta.

27 Estrutura de mensagens de requisição-e- resposta messagetype requestid objectreference methodid arguments int (0=Requisição, 1= Resposta) int (identifica a requisição) Referência de objeto remota int (identifica o método) array de bytes Identificador da mensagem pode ser formado a partir: requestid junto com o ID do processo remetente que fez a requisição usando por exemplo o seu endereço de IP.

28 Modelo de falhas Suposições processos: param após falha canais: podem omitir mensagens Uso de timeouts: em dooperation. Para detectar se a resposta (ou a requisição) foi perdida. Alternativas de tratamento: sinalizar a falha para o cliente (uma boa opção?) repetir o envio da requisição (um certo número de vezes melhor abordagem) Até ter certeza sobre a natureza da falha (quem falhou? O canal ou o processo?)

29 Modelo de falhas Descarte de mensagens duplicadas o servidor deve distinguir requisições novas de requisições retransmitidas RequestIDs Em caso de perda da resposta (reply), o servidor: Pode re-executar a requisição para gerar novamente a resposta, ou Pode manter um histórico das respostas geradas para o caso de precisar retransmití-las

30 Protocolos de troca de mensagens Nome R Request Mensagens enviadas pelo Cliente Servidor Cliente RR Request Reply RRA Request Reply Acknowledge reply

31 Protocolos de troca de mensagens Protocolo R: cliente transmite requisição para o servidor. Não há necessidade de retornar valor e o cliente não precisa de confirmação de recebimento Geralmente implementado sobre o protocolo UDP Protocolo RR: cliente transmite requisição e necessita de confirmação de recebimento pelo servidor. Confirmação feita pela resposta (reply) do servidor Protocolo RRA: Semelhante ao protocolo RR sendo que o servidor também necessita de confirmação de recebimento de resposta (reply) pelo cliente (acknowledge) Não bloqueia o cliente

32 Protocolo de transporte utilizado: UDP Leva em conta o tamanho da mensagem se sessões são curtas (apenas uma requisição e sua resposta) não compensa o overhead do handshake TCP Não oferece confiabilidade necessitando que o programador recursos de garantia de entrega de mensagens Retransmissão de mensagens Filtragem de mensagens duplicadas Histórico de respostas mantido pelo servidor

33 Protocolo de transporte utilizado: TCP Implementação mais fácil Não impõem limites no tamanho das mensagens na verdade, cuida da segmentação (divisão das mensagens) de forma transparente permite argumentos de tamanho arbitrário (ex.: listas) Transferência confiável lida com mensagens perdidas e duplicadas Controle de fluxo Overhead reduzido em sessões longas (muitas requisições e respostas sucessivas)

34 Comunicação de Grupo Processo envia a mensagem para o grupo (não para seus membros diretamente) Entrega de uma mesma mensagem, enviada por um processo, para cada um dos processos que são membros de um determinado grupo O conjunto de membros do grupo é transparente para o processo que envia a mensagem Mensagens comunicadas através de operações de multicast

35 Comunicação de Grupo

36 Aplicações da comunicação de grupo Tolerância a falhas baseada em serviços replicados Busca por serviços de descoberta em redes espontâneas Melhoria de desempenho através de dados replicados Propagação de eventos

37 IP Multicast É o protocolo básico para comunicação de grupo Assim como o IP (unicast): não-confiável mensagens podem ser perdidas (falha de omissão) i.e., não entregues para alguns membros do grupo mensagens podem ser entregues fora de ordem Acessível às aplicações através de UDP Grupos são identificados por: endereço IP + porta, utiliza endereços IP que iniciam por 1110 (IPv4) Processos se tornam membros de grupos, mas não conhecem os demais membros

38 IP Multicast (cont.) Um computador é membro de um grupo se ele possui um ou mais processos com sockets que se juntaram ao grupo: multicast sockets Camada de rede: recebe mensagens endereçadas a um grupo, se computador for membro entrega as mensagens para cada um dos sockets locais que participa do grupo processos membros são identificados pelo número de porta associado ao grupo vários processos compartilham o mesmo número de porta

39 API Java para IP Multicast Classe MulticastSocket Derivada de DatagramSocket Principais métodos: joingroup: método para entrar em um grupo leavegroup: método para sair de um grupo settimetolive: serve para configurar o TTL TTL (Time to live): serve para limitar a distância de propagação de um datagrama multicast pela rede Pequenas distâncias: redes locais Grandes distâncias: redes externas, Internet (uso de roteadores externos)

40 Processo entra em um grupo de multicast e envia e recebe datagramas import java.net.*; import java.io.*; public class MulticastPeer{ public static void main(string args[]){ // args give message contents & destination multicast group (e.g. " ") MulticastSocket s =null; try { InetAddress group = InetAddress.getByName(args[1]); s = new MulticastSocket(6789); s.joingroup(group); byte [] m = args[0].getbytes(); DatagramPacket messageout = new DatagramPacket(m, m.length, group, 6789); s.send(messageout); // this figure continued on the next slide

41 ...continuação } } // get messages from others in group byte[] buffer = new byte[1000]; for(int i=0; i< 3; i++) { DatagramPacket messagein = new DatagramPacket(buffer, buffer.length); s.receive(messagein); System.out.println("Received:" + new String(messageIn.getData())); } s.leavegroup(group); }catch (SocketException e){system.out.println("socket: " + e.getmessage()); }catch (IOException e){system.out.println("io: " + e.getmessage());} }finally {if(s!= null) s.close();}

42 Confiabilidade e ordenação de multicast Fontes de falhas membros de um grupo podem perder mensagens devido a congestionamento (fila de chegada cheia) falhas em roteadores de multicast roteador não propaga a mensagem para os membros que estão após ele na rede Falhas de ordenação Mensagens enviadas por um processo podem ser recebidas por outros processos em ordens diferentes Mensagens enviadas por diferentes processos podem não chegar na mesma ordem em todos os demais processos

43 Exemplo de falha de ordenação send receive receive X 1 m 1 4 Y 2 receive send 3 m 2 receive Physical time Z receive receive send A m 3 m 1 m 2 receive receive receive t 1 t 2 t 3 45

44 Efeitos de falhas nas principais aplicações de comunicação de grupo Serviços replicados causa inconsistência das réplicas: nem todas as réplicas terão processado todas as requisições Busca por serviços de descoberta imune a falhas: basta que alguém responda Dados replicados depende do modelo de replicação Propagação de eventos dependente de aplicação

45 Conclusão sobre IP Multicast Protocolo de multicast não-confiável Uso sobre redes locais: utiliza multicast físico ex.: em redes Ethernet Uso na Internet: utiliza roteadores de multicast configurados através de algum protocolo de roteamento multicast time-to-live para limitar a propagação de mensagens