docprocessos - Ricardo Mendao Silva
download 
Denúncia Transcrição
processos - Ricardo Mendao Silva
SISTEMAS DISTRIBUIDOS E PARALELOS 2014/2015 – 1º SEMESTRE Comunicação Inter-processos Ricardo Mendão Silva [email protected] Comunicação Inter-processos Outline • Introdução • A API para os protocolos de internet • Representação e empacotamento de dados externos • Comunicação mul$cast Coulouris G., Dollimore J., Kindberg T., Blair, G.,(2011), Distributed Systems: Concepts and Design (5th EdiMon), Addison-‐Wesley, ISBN: 978-‐0132143011 (Capítulo 4) Ricardo Mendão Silva [email protected] Comunicação Inter-processos Introdução • Neste capítulo vamos abordar a comunicação entre processos, suportada através de APIs montadas em cima dos protocolos UDP e TCP. Aplicações e serviços Invocação remota, comunicação indirecta Este capítulo Comunicação inter-‐processos: sockets, passagem de mensagens, mulMcast e redes sobrepostas Camadas de Middleware UDP e TCP Ricardo Mendão Silva [email protected] Comunicação Inter-processos Introdução • Como já vimos nas aulas práMcas, a camada de transporte do modelo TCP/IP e OSI assenta principalmente sobre dois protocolos: UDP e TCP. • O UDP fornece uma abstracção no método de passagem de mensagens entre processos – o modo mais simples de comunicação inter-‐processos. • Com UDP torna-‐se possível um processo remeter uma única mensagem para outro processo, denominando-‐se estas mensagens de datagrama. • Como vimos nos exercícios práMcos, os datagramas são enviados sobre sockets. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Introdução • Por outro lado, temos trabalhado sobre TCP, numa perspecMva orientada à ligação. • O TCP fornece abstracção sobre um fluxo de dados bidireccional entre pares de processos. • Ao contrário do UDP, no TCP não existe a noção de mensagens, sendo os dados transmiMdos em fluxo. Estas streams suportam um sistema produtor-‐consumidor, onde o produtor produz conteúdo e o consumidor consome o mesmo. • Os dados transmiMdos são recebidos por um buffer, que o consumidor vai lendo. • O consumidor fica em espera até haver dados no fluxo para consumir. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Introdução • Ao longo deste capítulo vamos abordar no terceiro ponto os métodos de passar e representar dados e estruturas de dados entre processos. • No ponto 4 abordaremos a comunicação mulMcast. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Outline • Introdução • A API para os protocolos de internet • Representação e empacotamento de dados externos • Comunicação mul$cast Coulouris G., Dollimore J., Kindberg T., Blair, G.,(2011), Distributed Systems: Concepts and Design (5th EdiMon), Addison-‐Wesley, ISBN: 978-‐0132143011 (Capítulo 4) Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet Modelo OSI Modelo TCP/IP 7. Aplicação 6. Apresentação Aplicação 5. Sessão 4. Transporte Transporte 3. Rede Internet 2. MAC Acesso à rede 1. Física Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • CaracterísHcas da comunicação inter-‐processos • A passagem de mensagens entre um par de processos pode ser suportada por duas operações: send e receive. • Para comunicar, um processos envia uma mensagem para um qualquer desMno, enquanto que outro processo no desMno encarrega-‐se de receber essa mensagem. • Este mecanismo envolve a comunicação de dados do processo transmissor para o processo receptor, podendo envolver algum Mpo de sincronismo entre os dois processos. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • CaracterísHcas da comunicação inter-‐processos • Uma fila é associada a cada desMno. Os processos transmissores provocam a adição de mensagens na fila do desMnatário, enquanto que os processos nos receptores removem as mensagens da fila local. • Comunicação síncrona ou assíncrona: • Na comunicação síncrona, ambos os processos sincronizam a cada mensagem. Neste caso tanto as acções de send como receive são operações bloqueadoras. • Na comunicação assíncrona o envio (send) não é uma operação bloqueadora, ou seja, a transmissão realiza-‐se em paralelo com a execução normal do processo que transmite. O recepção, por sua vez, pode ser bloqueadora ou não. Caso não seja, terão de exisMr mecanismos que noMfiquem que o buffer de entrada está a ser preenchido. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • CaracterísHcas da comunicação inter-‐processos • DesHnos de mensagem: • As mensagens, nos protocolos Internet, são enviadas para para <endereço internet:porto local>. • Um porto local é desMno de uma mesagem num computador, idenMficado por um inteiro unsigned de 16 bits. • Uma porta tem apenas um receptor (excepto para mulMcast), podendo ter diversos emissores. • Os processos podem uMlizar múlMplas portas para comunicar. Os servidores normalmente publicitam as suas portas para que os clientes se possam ligar. • Se os clientes uMlizam o IP fixo do servidor para acederem a determinado serviço, obriga a que esse IP não seja alterado. Em alternaMva, o uso de um sistema de nomes fixos, associado a IP dinâmico, permite implementar transparência na localização. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • CaracterísHcas da comunicação inter-‐processos • Fiabilidade: • A fiabilidade é traduzida ao nível da comunicação em termos de validade e integridade. • Um serviço de mensagens ponto-‐a-‐ponto pode ser dito válido, sempre que as mensagens têm garanMas de entrega, considerando um limite máximo de pacotes perdidos. • O mesmo serviço é considerado integro se as mensagens chegar ao desMno não-‐corrompidas e sem duplicações. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • CaracterísHcas da comunicação inter-‐processos • Ordenação: • Algumas aplicações requerem que as mensagens sejam entregues na ordem pela qual foram enviadas (sender order). • A entrega de mensagens fora de ordem é considerado uma falha por certas aplicações. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Sockets Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Sockets • Para um processo receber mensagens, deve conter um socket vinculado a uma porta e pelo menos a um endereço de internet da máquina. • Um mesmo socket pode ser uMlizado para enviar e receber dados. • Um processo pode vincular mais do que uma porta, mas a mesma porta não pode ser parMlhada por mais do que um processo. • No entanto, qualquer processo pode enviar mensagens para qualquer porta. • Cada socket é associado com um protocolo especifico: UDP ou TCP. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Sockets • Java API • Como as mensagens são enviadas via UDP ou TCP, para um IP de desMno, o Java fornece uma classe que representa o endereço de internet, denominada de InetAddress. • Os uMlizadores desta classe referem-‐se às máquinas pelo hostname registado no DNS (Domain Name Server). • Por exemplo: • InetAddress server = InetAddress.getByName(server.sdp.ual.pt); • Esta classe pode causar a excepção UnknownHostExcep$on caso o nome inserido não seja válido. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Datagramas UDP • Um datagrama enviado via UDP é transmiHdo do processo emissor para o processo receptor sem qualquer noHficação de recepção ou re-‐envios. • Se falhas ocorrerem a mensagem pode não chegar. • Para enviar um datagrama o processo deve primeiro criar um socket e vincula-‐lo a um endereço e uma porta local. • O cliente vincula o seu socket a qualquer porta que esteja disponível. • O método receive retorna o IP e o porto do emissor, permiMndo ao cliente enviar uma resposta. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Datagramas UDP • A comunicação via datagramas apresenta alguns problemas: • Tamanho das mensagens: obriga a definir um tamanho máximo para o buffer, que pode não ser suficiente. • Bloqueio: normalmente o receive é uma acção bloqueadora, que pode levar ao bloqueio do processo se não for devidamente implementada (threads e/ ou Mmeouts). • Timeouts: um receive bloqueia o processo à espera de um datagrama. No entanto, o servidor pode ter crashado ou o datagrama pode-‐se ter perdido e o cliente fica eternamente bloqueado. Os sockets fornecem Mmeouts para controlar o tempo de bloqueio. • Receber de qualquer um: o método receive não especifica a origem da mensagem, podendo receber de qualquer servidor. O receive devolve o IP e porto do emissor de modo a poder comunicar de volta. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Datagramas UDP – Modelo de falhas • Os datagramas sofrem de: • Omissão de falhas: as mensagens podem ser descartadas ocasionalmente, seja por erros no checksum, seja por que não existe espaço nos buffers de envio ou recepção. • Ordenação: as mensagens podem ser entregues fora de ordem. • As aplicações que uMlizam UDP devem garanMr a fiabilidade de comunicação no nível aplicacional (TCP/IP). Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Datagramas UDP – USO • Em certos serviços é aceitável o uso de um serviço que falha ocasionalmente. • Ex: • DNS é suportado sobre UDP. • VOIP é suportado sobre UDP. • O UDP é atracMvo pois não adiciona overhead na comunicação, causado por mensagens de acks ou syncs. Existem três fontes primárias de overhead: • A necessidade de guardar informação de estado na fonte e desMno • A transmissão de mensagens extra • A latência para o emissor Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Datagramas UDP – Java API • A API do Java fornece duas classes, nomeadamente: • DatagramPacket – classe que contem o array de bytes com a mensagem, o tamanho da mesma, o IP e porto do socket de desMno. Encapsula o datagrama transmiMdo ou a transmiMr. • DatagramSocket – classe que suporta o socket para enviar e receber datagramas UDP. Despoleta a excepção SocketExcepMon sempre que ocorre algum erro. Inclui os seguintes métodos: Ricardo Mendão Silva • send e receive – UMlizados para transmiMr datagrmas entre pares de processos. O argumento no send é um DatagramPacket devidamente preenchido com a mensagem e o desMno. O argumento no receive é um DatagramPacket vazio, que será preenchido com a mensagem e os dados do emissor. Despoletam a excepção IOExcepMon. • setSoTimeout – define um Mmeout para o receive e despoleta a excepção InterruptedIOExcep$on. • Connect – uMlizado para ligar a porto e endereço remoto. [email protected] Comunicação Inter-processos API Internet • Fluxo TCP • A API do TCP fornece uma abstracção a um fluxo de bytes a parMr do qual os dados podem lidos ou para o qual podem ser escritos. • As seguintes caracterísMcas são escondidas pela abstração do fluxo: • Tamanho de mensagens: a aplicação decide a quanMdade de dados que escreve no fluxo. • Mensagens perdidas: O TCP uMliza um esquemas de noMficação de recepção. Se o receptor não noMficar a recepção dentro de um determinado tempo, o emissor re-‐transmite o pacote. • Controlo do fluxo: o TCP controla o fluxo de dados, considerando a velocidade de escrita e leitura da stream. Se o servidor escreve demasiado rápido e o cliente não consegue ler tudo, o protocolo bloqueia o servidor temporariamente. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Fluxo TCP • As seguintes caracterísMcas são escondidas pela abstração do fluxo (conMnuação): • Duplicação de mensagens e ordenação: cada mensagem está devidamente idenMficada e associada a um IP, permiMndo detectar mensagens duplicadas e re-‐ordenar. • DesHno da mensagem: O TCP estabelece uma ligação antes de iniciar a transmissão de dados. Para isso existe uma acção de connect e accept. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Fluxo TCP • Sempre que uma ligação é estabelecida, o protocolo assume que um elemento desempenha o papel de servidor, enquanto que o outro elemento desempenha o papel de cliente. • O papel do cliente envolve a tarefa de criar um socket num qualquer porto e executar um connect, requerendo ligação a um determinado servidor, idenMficando o respecMvo IP e porto. • O papel do servidor envolve criar um socket à escuta, vinculado numa porta e esperar pelos pedidos de ligação dos clientes. • Sempre que um cliente é aceite, o servidor cria um novo socket para lidar com esse fluxo, deixando o socket vinculado ao porto livre para atender outros clientes. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Fluxo TCP • O par de sockets no cliente e servidor está ligado por um par de fluxos, um para enviar e outro para receber. Assim, cada socket tem um InputStream e um OutputStream. • Sempre que uma aplicação fecha um socket, quaisquer dados que estejam no buffer de saída são enviados, com a noMficação de que o socket foi fechado. • A comunicação TCP tem alguns problemas: • Correspondência de dados: os dois processos devem acordar quanto ao Mpo de dados transmiMdos, para evitar leituras erradas. • Bloqueio: os dados escritos para a stream são manMdos numa fila até serem lidos. Sempre que o receptor não tenha dados para ler, fica bloqueado. Sempre que emissor pretenda emiMr, mas o buffer do receptor contem mais dados do que o protocolo permite, também este é bloqueado. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Fluxo TCP • A comunicação TCP tem alguns problemas (conMnuação): • Threads: quando um servidor aceita uma ligação, normalmente cria uma nova thread para lidar com essa ligação. O importante de uMlizar uma thread por ligação é que deste modo cada thread pode bloquear à espera de qualquer resposta, sem afectar os outros clientes. Num ambiente onde não é possível implementar threads são necessários mecanismos complexos para garanMr a flexibilidade do sistema ao servir múlMplos clientes. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Fluxo TCP – Modelos de falhas • Para garanMr a integridade, as streams TCP uMlizam checksums para detectar e rejeitar pacotes corrompidos e as sequências de números para detectar e rejeitar pacotes duplicados. • Para garanMr a validade, o TCP uMliza Mmeouts e retransmissões para lidar com a perda de pacotes. • No entanto, se o número de pacotes perdidos aumenta consideravelmente ou o fluxo fica congesMonado, o emissor não vai receber acks e vai declarar a ligação interrompida. Neste caso existem dois problemas: 1. O processo não disMngue se a interrupção foi devido a falha de rede ou do processo no outro extremo. 2. O processo não consegue saber se as úlMmas mensagens enviadas foram recebidas. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Fluxo TCP – USO • Existem inúmeros serviços de TCP, muitos deles com portas reservadas. • Ex: • HTTP – Hypertext Transfer Protocol é uMlizado na comunicação entre os web browsers e os web servers. • FTP – File Transfer Protocol permite listar directorias remotas e copiar ficheiros entre máquinas. • Telnet – fornece acesso via terminal a máquinas remotas. • SMTP – Simple mail transfer Protocol é uMlizado para enviar e-‐mails entre computadores. Ricardo Mendão Silva [email protected] Comunicação Inter-processos API Internet • Fluxo TCP – Java API • A implementação do TCP em Java é fornecido através das classes ServerSocket e Socket. • ServerSocket – é a classe uMlizada pelo servidor, permiMndo criar um socket, vinculado a um porto, e escutar por ligações de clientes. O ServerSocket usa o método accept quando recebe um pedido de connect, criando um instância do objecto Socket, uMlizado depois na comunicação. • Socket – é a classe uMlizada por um par de processos com ligação entre si. Os clientes criam um Socket especificando o hostname DNS e o porto do servidor. Este construtor não só cria o socket como também faz o connect. Pode despoletar as excepções UnknownHost ExcepMon ou IOExcepMon. O Socket fornece os métodos getInputStream e getOutputStream para aceder às duas streams criadas. Estes métodos devolvem respecMvamente uma instância abstracta InputStream e OutputStream. Pode-‐se estes outputs para diferentes Mpos de inputs e outputs, como por exemplo, DataInputStream e DataOutputStream. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Outline • Introdução • A API para os protocolos de internet • Representação e empacotamento de dados externos • Comunicação mul$cast Coulouris G., Dollimore J., Kindberg T., Blair, G.,(2011), Distributed Systems: Concepts and Design (5th EdiMon), Addison-‐Wesley, ISBN: 978-‐0132143011 (Capítulo 4) Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • A informação guardada nos programas em execução encontra-‐se sobre a forma de estruturas de dados, sejam elas estruturas em C ou conjuntos de objectos interligados noutras linguagens mais de alto nível. • No entanto, a informação conMda nas mensagens são simples arrays de bytes. • Como tal, independentemente do método de comunicação, as estruturas de dados devem ser converMdas para arrays de bytes, transmiMdas e depois montadas novamente do lado do receptor. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Essa informação pode conter vários Mpos de dados, Mpos esses que nem sempre são interpretados da mesma forma pelas diferentes plataformas. • Por exemplo, os inteiros e as virgulas-‐flutuantes podem ser interpretados de diferentes formas. • Quanto aos inteiros existem duas formas de interpretação: • Big-‐ending: os bytes mais significaMvos estão no inicio. • Lixle-‐ending: os bytes mais significaMvos estão no final. • Os caracteres também eles apresentam diferentes codificações, com variações entre ASCII (UTF-‐8), UTF-‐16 ou mesmo UTF-‐32, para representar cada idioma. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Para resolver a questão da codificação, podem ser uMlizadas as seguintes técnicas: • Os valores são converMdos para um formato externo, previamente acordado e reconverMdos para o formato local na recepção. • Os valores são enviados no formato do emissor, com a indicação de qual é esse formato, e o receptor converte-‐os depois para o seu formato, se necessário. • Para além disso, para suporta RMI ou RPC, os dados passados por argumento ou devolvidos pelo método, devem também eles serem possíveis de conversão seguindo um formato acordado. A um formato acordado para representar estruturas de dados e valores primiMvos chama-‐se representação de dados externos. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Empacotamento é o processo de pegar num conjunto de dados e empacotá-‐los num formato possível de transmissão. • Desempacotamento é o processo oposto, que ocorre na recepção. • O empacotamento consiste na tradução de estruturas de dados e valores primiMvos numa representação de dados externa. • Três abordagens alternaMvas vão ser apresentadas: • Representação dados em CORBA • Serialização de objectos em Java • XML – Extensible Markup Language Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • CORBA Common Data RepresentaMon (CDR) • CORBA CDR é capaz de representar todos os Mpos de dados que podem ser uMlizados como argumentos e Mpos de retorno nas invocações remotas em CORBA. • Inclui 15 Mpos primiMvos: • Short (16 bits), long (32 bits), unsigned short, unsigned long, float (32 bits), double (64 bits), char, boolean, octet (8 bits) e any (qq Mpo) • CDR define representações para big e lixle-‐ending. • Inclui 6 Mpos compostos: • Sequência, string, array, struct, enumerated, union • As primiMvas que consitutem um Mpo composto são adicionadas a uma sequência de bytes por uma ordem parMcular. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • CORBA Common Data RepresentaMon (CDR) • Considere-‐se o empacotamento da seguinte estrutura, os dados {‘Silva’,’Lisboa’,1984} index 4 bytes struct Person{ string name; string place; unsigned long year; }; Ricardo Mendão Silva 0-‐3 5 Tamanho string 4-‐7 “Silv” “Silva” 8-‐11 “a____” 12-‐15 6 Tamanho string 16-‐19 “Lisb” “Lisboa” 20-‐23 “ao__” 24-‐27 1984 unsigned long [email protected] Comunicação Inter-processos Representação e empacotamento • Java Object SerializaMon • No Java RMI, tanto os objectos como as primiMvas podem passar como argumento ou serem retornados pelos métodos invocados. Um objecto é uma instância de um classe Java, que para poder ser empacotado para transmissão deve implementar a interface Serializable. public class Person implements Serializable { private String name; private String place; private int year; public Person(String n, String p, int y){ this.name = n; this.place = p; this.year = y; } …. } Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Java Object SerializaMon • A desserialização é o acto oposto, ou seja, construir o objecto a parMr da sua serialização. • Para que tal seja possível é adicionada informação sobre a classe na serialização. • Os dados guardados são o nome da classe e um ID, que altera quando ocorrem alterações maiores na classe. • Com esse ID, o processo que desserializa a classe, verifica se tem a versão correspondente da mesma. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Java Object SerializaMon • Como os objectos podem referenciar outros objectos, no acto de serialização, todos os objectos envolvidos são serializados. • Deste modo garante-‐se que todas as dependências necessárias na desserialização, estão incluídas. À referência serializada denomina-‐ se handle. • Se um objecto é referencia mais que uma vez, este só é serializado uma vez, uMlizando-‐se o handle correspondente, sempre que necessário. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Java Object SerializaMon • Para serializar e desserializar cada objecto deve-‐se criar uma instância da classe ObjectoutputStream e invocar o método writeObject e da classe ObjectInputStream e invocar o método readObject, respecMvamente. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Java Object SerializaMon -‐ reflecMon • O Java suporta reflecMon, ou seja, a capacidade de quesMonar as propriedades da classe, tais como nomes e Mpos de variáveis e métodos. • ReflecMon permite serializar e desserializar de modo genérico, sem obrigar a que gere um empacotamento especifico para cada objecto. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Extensible Markup Language (XML) • O XML é uma linguagem markup que foi definida pelo World Wide Web ConsorMum (W3C) para uso genérico na Web. • Os items XML são marcados com strings (markups). Essas tags são uMlizadas para descrever a estrutura lógica dos dados e para associar pares de atributos-‐valor com estruturas lógicas. • O XML é uMlizado para permiMr que os clientes comuniquem com os web services e para definir interfaces e outras propriedades também nos web services. • O XML é “extensible” uma vez que os uMlizadores podem definir as suas próprias tags. No entanto, se o objecMvo é uMlizar o XML por várias aplicações, o formato deve ser acordado previamente. Por exemplo, os clientes normalmente uMlizam mensagens SOAP para comunicar com os web services. SOAP é um formato de XML cujas tags estão publicadas para uso pelos web services e clientes. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Extensible Markup Language (XML) • O XML é consMtuído por elementos e atributos. • Os elementos correspondem a um conjunto de dados conMdos entre tags de abertura e fecho. <nome> …</nome> • Os atributos são valores que podem ser associados nas tags de abertura. <nome id=“123”> …</nome> <pessoa id=“456”> <nome>Silva</nome> <local>Lisboa</local> <ano>1984</ano> </pessoa> Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Extensible Markup Language (XML) • Um ficheiro XML deve estar bem formatado, ou seja, garanMr que todas as regras de preenchimento estão cumpridas. Regras básicas referem-‐se por exemplo ao fecho de tags ou à existência de uma tag root, na qual todas as restantes estão incluídas. • Um ficheiro bem formato é lido facilmente. Se um parser tentar ler um ficheiro mal formato dará erro imediatamente. • Se alguma parte do ficheiro não deve ser incluída no parser, uMliza-‐ se o CDATA. <local><![CDATA [Lisboa]]></place> Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Extensible Markup Language (XML) • Cada ficheiro XML deve ter um prologo na primeira linha. O prologo deve especificar pelo menos a versão do XML em uso. • Para além disso, pode especificar a codificação ASCII em uso ou se o documento é um documento isolado ou depende de definições externas. <?XML version=“1.0” encoding=“UTF-‐8” standalone=“yes”’> Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Extensible Markup Language (XML) -‐ namespaces • Um namespace XML é um conjunto de nomes para uma colecção de Mpos e atributos referenciados por um URL. • Qualquer outro documento XML pode uMlizar o namespace XML, referenciando somente o seu URL. • Ex: <pessoa pes:id=“123456” xmlns:pes=hxp://www.autonoma.pt/pes> <pes:nome>Silva</pes:nome> <pes:local>Lisboa</pes:local> <pes:ano>1984</pes:ano> </pessoa> Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Extensible Markup Language (XML) -‐ schemas • Um schema define os elementos e atributos que podem aparecer num documento, como estão organizados, ordenados e em que número e ainda quando um elemento está vazio ou pode incluir texto. • Para cada elemento define o Mpo e o valor por defeito. <xsd:schema xmlns:xsd=URL da definição do schema> <xsd:element name=“pessoa” type=“personType”/> <xsd:complexType name=“personType”> <xsd:sequence> <xsd:element name=“nome” type=“xs:string”/> <xsd:element name=“local” type=“xs:string”/> <xsd:element name=“year“ type=“xs:posiMveInteger”/> </xsd:sequence> <xsd:atribute name=“id” type=“xs:posiMveInteger”/> </xsd:complextType> </xsd:schema> Ricardo Mendão Silva [email protected] Comunicação Inter-processos Representação e empacotamento • Extensible Markup Language (XML) • APIs XML estão disponíveis na maioria das linguagens permiMndo rapidamente realizar o parse ou gerar XML a parMr de qualquer objecto e/ou dados. • Na web o XML começa a ser largamente subsMtuído por uma solução mais leve, o JSON – Javascript Object NotaMon www.json.org, também este com um amplo suporte de serialização e parsing de objectos. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Outline • Introdução • A API para os protocolos de internet • Representação e empacotamento de dados externos • Comunicação mulHcast Coulouris G., Dollimore J., Kindberg T., Blair, G.,(2011), Distributed Systems: Concepts and Design (5th EdiMon), Addison-‐Wesley, ISBN: 978-‐0132143011 (Capítulo 4) Ricardo Mendão Silva [email protected] Comunicação Inter-processos Comunicação Multicast • A comunicação ponto-‐a-‐ponto entre um servidor e um cliente, pode ser muito limitada quando é necessário comunicar para um grupo, ou seja, ponto-‐a-‐mulM-‐ponto. • Considere-‐se o caso do trabalho práMco, onde o servidor de chat deve enviar em tempo real a lista de parMcipantes ligados a cada cliente. • Neste caso, a implementação de um mecanismo de comunicação mulMcast é mais apropriado, do que enviar a mesma mensagem n vezes, sendo n o número de clientes ligados. • Existem vários protocolos de mulMcast, sendo o mais básico o flooding, que não apresenta quaisquer garanMas. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Comunicação Multicast • As mensagens mulMcast fornecem uma boa infraestrutura para sistemas distribuídos com as seguintes caracterísMcas: 1. Tolerância a falhas com base na replicação de serviços: um serviço replicado consiste num grupo de servidores. Um pedido de um cliente é mulMcast para o grupo de servidores. Se um falha, outros garantem o serviço. 2. Descoberta de serviços em redes espontâneas: mensagens mulMcast podem ser uMlizadas por clientes e servidores para localizar serviços de descoberta, de modo a registar os serviços das suas interfaces e/ou procurar interfaces de outros serviços. 3. Melhor performance via replicação de dados: os dados são replicados para aumentar a performance de um serviço. Cada vez que os dados mudam, os novos valores são mulMcast para os processos que gerem as replicas. 4. Propagação de eventos: sempre que eventos são despoletados o mulMcast dos mesmos aos interessados é mais eficiente que comunicar individualmente com cada processo. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Comunicação Multicast • IP mulMcast • IP mulMcast é montado em cima do Internet protocol, ou seja, do IP. • Tradicionalmente os pacotes IP estão endereçados à hosts únicos, através do IP e do porto. • Com IP mulMcast torna-‐se possível transmiMr um simples pacote IP para um conjunto de computadores que foram um grupo mulMcast. • O emissor não conhece nem as idenMdades dos receptores nem o tamanho do grupo. • Um grupo mulMcast é idenMficado por um endereço IP de classe D, ou seja, cujo primeiros 4 bits são 1110 em IPv4. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Comunicação Multicast • IP mulMcast • Ao nível aplicacional o IP mulMcast só está disponível via UDP. • A aplicação efectua mulMcast enviando datagramas para um endereço classe D e um porto único. • A mesma aplicação pode pertencer a um grupo mulMcast fazendo com que o seu socket pertença ao grupo. • Ao nível IP, um computador pertence a um grupo mulMcast, quando um ou mais processos contêm sockets que pertencem ao grupo. • Quando as mensagens chegam ao computador, são reencaminhadas para todos os sockets que se juntaram ao endereço mulMcast especifico. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Comunicação Multicast • IP mulMcast – Java API • O java fornece uma interface para IP mulMcast através da classe MulHcastSocket, que é uma sub-‐classe da DatagramSocket. • Esta classe fornece dois construtores, um que permite receber um porto especifico e outro que não especifica qualquer porto. • Fornece o método joinGroup para juntar a um grupo mulMcast no porto definido. • Fornece o método leaveGroup para sair do grupo. Ricardo Mendão Silva [email protected] Comunicação Inter-processos Comunicação Multicast Ricardo Mendão Silva [email protected] Dúvidas e Questões Ricardo Mendão Silva [email protected] Ricardo Mendão Silva [email protected]
Documentos relacionados
sistemas distribuidos e paralelos
• Assim, o nome cliente e servidor diz respeito ao papel que se
desempenha em determinada operação.
Ricardo Mendão Silva
