Serviços de Notificação de Eventos Baseados em Publish/Subscribe

Tamanho: px
Começar a partir da página:

Download "Serviços de Notificação de Eventos Baseados em Publish/Subscribe"

Transcrição

1 Serviços de Notificação de Eventos Baseados em Publish/Subscribe Bruno Oliveira Silvestre 4 de julho de Introdução O modelo de comunicação publish/subscribe é baseado na troca assíncrona de mensagens, conhecidas como eventos. Ele consiste de um conjunto de clientes que publicam esses eventos (produtores), os quais são encaminhados para clientes que registraram interesse em recebê-los (consumidores). Além do assincronismo, esse modelo oferece o desacoplamento entre o produtores e o consumidores de eventos, dando mais flexibilidade e extensibilidade às aplicações que utilizam esse modelo, pois a inclusão de novos produtos e consumidores se torna simples [1, 2, 3, 4]. Alguns sistemas fornecem ainda a possibilidade de persistência dos eventos, permitindo que um cliente que não esteja ativo no momento possa recebê-los posteriormente [2, 3]. A implementação de um serviço de notificação de eventos utilizando publish/ subscribe pode seguir um abordagem centralizada onde um único elemento é responsável por manter o registro de interesse dos consumidores e por disseminar os eventos que são gerados. Essa arquitetura, apesar da simplicidade, apresenta problemas de escalabilidade, sendo inviável para ser adotado com uma grande-escala de clientes conectados. Um modelo distribuído para o serviço consiste de um conjunto de servidores interconectadores, cada um responsável por prover serviços para uma parte dos clientes. A eficiência desse modelo depende de como os servidores estão interligados, como os eventos são propagados e a estratégia de processamento dos interesses dos consumidores [1]. Neste trabalho serão apresentados quatro serviços de notificação de eventos baseados em publish/subscribe que adotam um modelo distribuído. O objetivo é mostrar as estratégias adotadas por cada um deles para alcançar escalabilidade na disseminação em larga-escala de eventos. 1

2 A forma como os consumidores selecionam que tipo de eventos querem receber pode variar. Os quatro serviços a seguir permitem que a seleção seja feita através de filtros que são aplicados sobre o conteúdo dos dos eventos. Esses filtros são passados na hora em que o cliente efetua uma subscrição no sistema. A seção 2 apresenta os sistemas SIENA, Rebeca, Meghdoot e Terpstra et al. Na seção 3 são apresentados comentários finais sobre os sistemas. 2 Serviços de Notificação Publish/Subscribe Nesta seção apresentaremos quatro serviços de notificação distribuídos baseados em conteúdo, com diferentes abordagens de arquiteturas de interligação dos servidores e formas de propagação das notificações de eventos. 2.1 SIENA O SIENA [5, 1] é um sistema de notificação de eventos que adota uma estrutura de servidores interconectados que propagam as notificações e servem de ponto de acesso, através dos quais os clientes podem registrar seus interesses e receber as notificações de eventos. Esses clientes são divididos em duas categorias, os objetos de interesse, que são as fontes de eventos, e as partes interessadas, que consomem as notificações. A figura 1 ilustra a arquitetura geral do sistema. Figura 1: Serviço de notificação SIENA. Em geral as partes interessadas não desejam receber todo os tipos de eventos que estão sendo propagados na rede. Ao se registrarem em um servidor para receber eventos, os clientes informam filtros que serão aplicados às notificações. Apenas as notificações que casam com esses filtros são repassadas aos clientes. 2

3 O SIENA também permite que os objetos de interesse anunciem quais os tipos de eventos eles geram, possibilitando que o sistema utilize essa informação em conjunto com os filtros para otimizar o repasse dos eventos ao cliente. Com o objetivo de usar a rede de forma mais eficiente, o SIENA adota uma entrega seletiva, empregando algoritmos de roteamento baseados no conteúdo das notificações, nos filtros das partes interessadas, nos anúncios dos objetos de interesse e na forma como os servidores estão conectados. O objetivo é enviar os dados apenas para os servidores que possuem clientes com interesse nessas informações, seguindo o caminho mais curto possível. Quando um cliente se registra, o servidor necessita propagar pela rede o interesse do cliente em um dado tipo de evento (filtro) para que os demais servidores possam encaminhar esses eventos até o ponto de acesso, e assim, até o cliente. No entanto, se os interesses de todos os clientes forem propagados, haveria um grande tráfego de mensagens de controle. Para reduzir o número de propagações, o sistema dissemina apenas os filtros mais gerais que englobam filtros mais específicos. Por exemplo, suponha que o sistema seja empregado para notificar os valores dos ações de uma bolsa e que três clientes, A, B e C, registram interesse em receber notificações sobre o valor das ações de uma mesma empresa. Seja o filtro de A valor>10, o de B valor>12 e o de C valor>15. Neste caso, apenas o filtro de A é propagado para os demais servidores, pois ele engloba os filtros de B e C. Os servidores no SIENA podem estar interligados seguindo duas configurações primárias, que podem ser combinadas gerando configurações híbridas: hierárquica e peer-to-peer. A estrutura hierárquica utiliza o conceito de cliente/servidor para a propagação das notificação, e na abordagem peer-to-peer os servidores estão conectados na forma de um grafo não direcionado. Os detalhes sobre cada uma delas são descritos a seguir. Hierárquica Na estrutura hierárquica os servidores são dispostos como um grafo orientado, como mostra a figura 2. O protocolo utilizado para a comunicação entre clientes e servidores e entre servidores é o mesmo, ou seja, um dado servidor não sabe distinguir se as notificações estão sendo enviadas ou recebidas de um outro servidor ou de um cliente. Isso pode ser visto como a extensão do modelo centralizado de notificação pois não há um protocolo diferenciado entre os servidores. Com essa disposição, os servidores se comunicam apenas com o seus pais e com os seus filhos, reduzindo o número interação entre os nós da rede. Quando um servidor recebe um pedido de subscrição de um cliente, ele primeiro verifica se esse cliente já realizou anteriormente uma subscrição usando um 3

4 Figura 2: Topologia hierárquica do SIENA. filtro mais abrangente que o atual. Nesse caso o pedido é simplesmente descartado. Caso contrário, duas possibilidades podem ocorrer: (i) o filtro existe no servidor, mas o cliente não está relacionado ao mesmo, ou (ii) é um novo filtro. Se o filtro já existe, o servidor apenas adiciona o cliente na lista de nós a serem notificados quando um evento relacionado for recebido. Perceba que quando o servidor já possui o filtro, não há nenhuma propagação do mesmo, ou seja, não há troca de mensagens entre os servidores da rede para atualização do roteamento dos eventos. A propagação só ocorre quando o filtro introduzido é mais abrangente que os demais já registrados, e mais, ela é enviada apenas para o pai. Para exemplificar, a figura 3 mostra um servidor S 1, que já havia propagado o interesse valor>15 do cliente C 1 para o pai S 2, recebendo o pedido de subscrição de C 2 contendo o filtro valor>10. Como o filtro de C 2 é mais abrangente que o filtro de C 1, S 1 comunica S 2 de que o filtro anterior não cobre o interesse de todos os cliente de S 1 e que um novo filtro ( valor>10 ) deve ser utilizado. Da mesma forma que um cliente afeta a relação de filtros de um servidor, um servidor pode afetar a relação de outro servidor. O tratamento dado a uma propagação entre servidores é o mesmo dado à subscrição entre clientes e servidores. Assim, no exemplo anterior, a propagação do novo filtro para S 2 pode ocasionar em uma propagação desse filtro para o pai de S 2, desde que esse filtro seja mais abrangente que os já registrados. Esse processo pode continuar até atingir a raiz da árvore onde ele é interrompido, pois a raiz não propaga os interesses de seus filhos. As notificações são encaminhadas para os nós filhos (clientes e servidores) de acordo com os filtros registrados. Quando um servidor recebe a publicação de 4

5 Figura 3: Propagação de subscrição na estrutura hierárquica. um evento vindo de um objeto de interesse, ele verifica quais de seus filhos estão interessados em tal evento e notifica-os. Entretanto, como os filtros são propagados somente para os pais até eventualmente atingir a raiz, um servidor em um ramo da árvore pode desconhecer os interesses de clientes em outro ramo. Dessa forma, o servidor deve propagar o evento para seu pai, que propaga para seus filhos e seu pai, e assim por diante, até que um ancestral comum com os interessados seja atingido. Então, esse ancestral propaga o evento pelo ramo onde os clientes se encontram. Por exemplo, na figura 3, se o cliente C 3 estiver interessados em eventos gerados por C 2, S 1 não possui tal conhecimento. Mas, ao receber a propagação os eventos de C 2 vindas de S 1, S 2 identifica o interesse de C 3 e notifíca-o. Quando um cliente não deseja mais receber notificações de um dado tipo de evento ele deve comunicar ao servidor. O SIENA permite que o cliente cancele mais de uma subscrição de uma só vez. Ao solicitar o cancelamento, o cliente fornece ao seu ponto de acesso um filtro que será usado para identificar todos os registros a serem removidos, da seguinte forma: o servidor procura todos os filtros registrados que são cobertos pelo filtro do cancelamento e retira o cliente de todas as listas de notificações associadas com esses filtros. Caso algum filtro fique com sua lista de notificações vazia, ele é removido do servidor. O fato de remover filtros de um servidor pode alterar o esquema de propagação de eventos na árvore. Ao cancelar um filtro, o servidor deve verificar se o filtro não foi o propagado para o pai. Nesse caso, o servidor deve comunicar o seu pai de que o filtro antigo não é mais utilizado e que um novo filtro (se houver) deve ser utilizado. Isso pode causar um efeito em cadeia pois o pai também deve verificar se o filtro a ser substituído foi propagado. Como exemplo, se na figura 3 o cliente C 2 cancelar o seu interesse por eventos cujo valor seja maior que 10, o servidor S 1 deve remover o filtro, pois apenas C 2 estava relacionado com o mesmo, e deve 5

6 comunicar S 2 de que o novo filtro é valor>15. Peer-to-Peer Na arquitetura peer-to-peer os servidores que fazem parte do serviço de notificação são interligados formando um grafo não dirigido, como mostra a figura 4(a). Entretanto, mesmo admitindo que mais de um caminho possa ligar dois servidores, os mecanismos de seleção e entrega do SIENA se baseiam na árvore geradora mínima do grafo, reduzindo as ligações entre servidores a um grafo acíclico (figura 4(b)). Figura 4: Estrutura peer-to-peer do SIENA. Aparentemente, o SIENA designa o termo peer-to-peer para uma rede não estrutura, considerando estáticos os membros da rede. O processo de tratamento dado às subscrições estende o processo do modelo hierárquico, sendo que a principal diferença é como são definidos os vizinhos para os quais serão propagadas as subscrições. Assim, quando um servidor recebe uma subscrição (seja de um cliente ou de uma propagação), se o filtro já estiver registrado no servidor ou for menos abrangente que um filtro submetido anteriormente, o processo se dá da mesma maneira que na arquitetura hierárquica. Contudo, se o servidor não possui o filtro, ele registra-o e verifica a necessidade de propaga-lo para seus vizinhos. Para definir quais servidores devem receber a propagação, avaliada-se a seguinte expressão vizinhos NPAG( f ) f f propagado( f ) (1) onde f é o filtro da subscrição. NPAG representa os vizinhos que não participam da árvore geradora mínima ou que já receberam a propagação de f. O último termo indica o conjunto dos vizinhos por onde foram propagados filtros f mais abrangentes que f. 6

7 O algoritmo de notificação de eventos e de cancelamento de subscrição da arquitetura peer-to-peer são similares aos empregados pela hierárquica. Quando um objeto de interesse publica um evento, o seu ponto de acesso verifica quais de seus clientes estão interessados em tal evento e notificando-os. Ele também propaga o evento para os vizinhos que registraram interesse, que realizarão o mesmo procedimento. Assim, o evento é disseminado por toda a rede de servidores até atingir as partes interessadas. Como visto anteriormente, os clientes selecionam as subscrições a serem canceladas através de um filtro, isto é, todos as subscrições do cliente que são abrangidas por esse filtro são removidas do ponto de acesso. Após remover as subscrições, o servidor deve reavaliar a expressão (1). Isso pode acarretar na mudança do filtro que deve ser propagado ou no conjunto de vizinhos que devem receber as notificações. Caso haja mudança, o servidor interage com seus vizinhos para manter consistente o caminho de propagação, atualizando ou cancelando os interesses por eventos. Um aprimoramento que pode ser introduzido nesta arquitetura é o anúncio de eventos. Os objetos de interesses anunciam aos seus pontos de acesso quais os tipos de eventos que são gerados, com isso, os servidores podem usar as informações dos anúncios como limitadores para a propagação das subscrições, isto é, um servidor só propaga os interesses por eventos para os vizinhos que possuem objetos de interesse geradores de tal tipo de evento. Para que os servidores saibam quais os tipos de evento gerados por cada cliente, os anúncios são propagados pela rede segundo uma expressão semelhante à expressão (1). A diferença é que em vez de utilizar o filtro da subscrição, é utilizado o tipo de evento que é gerado pelo objeto de interesse. A fórmula de propagação de subscrição foi alterada para utilizar os anúncios na derivação dos vizinhança de propagação, sendo ela (vizinhos NPAG( f ) f f propagado( f )) f a anunciadores(a) (2) onde anunciadores fornece um conjunto de vizinhos que realizaram anúncios a, que casam com o filtro f. 2.2 Rebeca Rebeca [2, 6] é um serviço de notificação com suporte a variados algoritmos de roteamento baseados no conteúdo da notificação e em anúncios. Ele conta com implementações em JAVA e Microsoft.Net. A infra-estrutura do serviço consiste de um conjunto de brokers interconectados, divididos em duas categorias: brokers locais, que servem de ponto de acesso para os clientes, e roteadores, responsáveis por propagar as notificações pela rede. 7

8 A implementação descrita em [2] considera a interconexão dos brokers em forma de árvore (figura 5), citando como trabalho futuro uma implementação que considera a possibilidade de ciclos na conexão dos roteadores. Figura 5: Interligação dos brokers no Rebeca. As notificações são compostas de um conjunto de atributos, definidos como o par (nome, valor), como por exemplo, {(tipo, StockQuote), (nome, Infineon ), (preço, 45,00)}. Uma das vantagens do Rebeca é o uso de uma arquitetura que permite o desenvolvimento de outros tipos de algoritmos de roteamento das notificações. Em sua avaliação inicial, cinco algoritmos de roteamento foram acoplados ao sistema: flooding, baseado em filtros simples, baseado em identidade de filtros, baseado em cobertura de filtros e baseado em fusão de filtros [2]. O algoritmo de flooding é o mais simples, os brokers apenas propagam por toda rede a publicação de um evento realizado por um dos clientes do serviço, não realizando nem um tipo de otimização na entrega. Os demais algoritmos adotam filtros para estabelecer o caminho de entrega das notificações. No algoritmo baseado em filtros simples, quando um ponto de acesso recebe uma subscrição, o respectivo filtro de interesse é propagado para todos os brokers da rede. Assim, todos os brokers sabem os interesses de todos os clientes. Essa técnica, apesar de simples, apresenta desvantagem quando o número de subscrições é alto, pois a tabela de rotas de cada broker possuirá muitas entradas, dificultando a localização dos nós para os quais a notificação deve encaminhada. O cancelamento de uma subscrição se dá propagando o pedido pela rede e cada um dos brokers retira de sua tabela de rotas a entrada referente ao cancelamento. 8

9 O roteamento baseado em identidade de filtros segue o mesmo princípio utilizado no filtro simples, mas evita a propagação de filtros que sejam iguais, na tentativa de reduzir o fluxo na rede. Esse algoritmo é uma particularidade do algoritmo baseado em cobertura de filtros, o qual é idêntico ao utilizado pela arquitetura peer-to-peer do SIENA. Assim, em vez de considerar se um filtro mais abrangente já foi propagado, o roteamento baseado em identidade de filtro verifica se um filtro igual foi propagado. A fusão de filtros tem por objetivo reduzir o números de entradas na tabela de roteamento dos brokers. Esse algoritmo é montado sobre o algoritmo baseado em cobertura de filtros e tenta unificar filtros de interesses por diferente eventos em um único filtro, tornando a avaliação de uma notificação mais rápida. Uma das dificuldades é encontrar um filtro que consiga substituir os demais filtros sem perder ou adicionar notificações na hora da avaliação. Empregar a fusão considerando filtros com o mesmo destino facilita a definição do filtro equivalente. Como exemplo, suponha que um cliente C tenha efetuado uma subscrições em seu ponto de acesso com o filtro F 1. Quando o cliente efetua uma nova subscrição com o filtro F 2, o ponto de acesso realiza a fusão de ambos os filtros, criando um filtro substituto F 3, e o propaga para os vizinhos. Lembrando que este algoritmo é uma camada sobre o algoritmo baseado em cobertura de filtros, os vizinhos tomam F 3 como uma subscrição mais abrangente e o utilizam na hora de selecionar quais notificações devem ser propagadas para C. Assim, o filtro F 1, referente à primeira subscrição, poderá ser descartado pelos brokers (exceto o ponto de acesso) caso ele não esteja sendo usado como rota para outro cliente. Os pontos de acesso devem armazenar todos os filtros de seus clientes e suas respectivas fusões para serem capazes de desfazer o processo no caso de um cliente cancelar uma ou mais subscrições cujos filtros foram usados em uma fusão. Deve-se propagar para os vizinhos o cancelamento do filtro derivado da fusão bem como os filtros que não removidos para que as rotas sejam mantidas. Rebeca também disponibiliza o mecanismo de anúncio, onde os clientes anunciam quais os tipos de eventos que eles geram. Como no SIENA, os anúncios são usados para otimizar a propagação das subscrições, ou seja, as subscrições serão propagadas pelas subredes da arquitetura onde exista um cliente que anunciou tipos de eventos relacionados com o filtro da subscrição. Essa estratégia visa diminuir o número de mensagens de controle na rede. Vale destacar que esse mecanismo não se aplica ao algoritmo de flooding. O modelo tradicional de publish/subscribe não permite que novos clientes tenham acesso a notificações já publicadas. Rebeca estende esse modelo permitindo que os clientes solicitem notificações antigas. Quando um cliente realiza uma subscrição, ele pode informar ao serviço que as notificações dadas a partir de uma certa data sejam publicadas novamente. No entanto, o sistema deve garantir que apenas o novo cliente receba essas notificações. 9

10 O armazenamento do histórico das notificações pode seguir duas estratégias. Na primeira, as próprias fontes de eventos gerenciam os seus históricos. A segunda e mais complexa abordagem é encarregar os brokers de gerenciar o histórico, poupando os clientes. Contudo, a medida que os brokers vão encaminhando as notificações para o cliente, o serviço deve se certificar de que notificações repetidas não estejam sendo repassadas. Isso pode ocorrer pois os brokers armazenam as notificações que trafegaram por ele. Assim, ao propagar uma notificação pela rede, mais de um broker pode tê-la armazenado. 2.3 Meghdoot O Meghdoot [7] emprega uma abordagem diferente do SIENA e do Rebeca para tratar as subscrições e o roteamento das notificações. O serviço é baseado em uma arquitetura peer-to-peer, onde cada nó é ser um ponto de acesso para o sistema e também um roteador de notificações. A definição de onde as subscrições são armazenadas é dada através do uso de tabelas hash distribuídas [8]. Normalmente, sistemas baseados em peer-to-peer são desenvolvidos para suportar uma maior flexibilidade, modularidade e escalabilidade. Um dos desafios nesse caso é distribuir a carga de tratamento das subscrições e da entrega dos eventos. O serviço emprega um esquema de atributos para gerenciar as tabelas hash. Um atributo é definido como uma tupla (Nome: Tipo, Min, Max), onde Min e Max definem o intervalo de valores que o atributo pode assumir, por exemplo, (preço: float, 0.0, 50.0). O Meghdoot constrói um espaço lógico com 2n dimensões, sendo n o número de atributos do esquema, e mapeia as subscrições e notificações nesse espaço para determinar quais clientes devem ser notificados. Dado um esquema{a 1, A 2,.., A n }, as dimensões 2i 1 e 2i do espaço correspondem ao intervalo [Min i, Max i ] do atributo A i, para 1 i n. Considerando um esquema {(preço: float, 0.0, 50.0)} temos um espaço com duas dimensões, cujo intervalo de cada uma delas é [0.0, 50.0], como mostra a figura 6. Após a definição, o espaço é particionado em zonas, de acordo com o número de nós que compões a rede. A figura 6 apresenta o espaço divido em cinco zonas. Cada nó fica responsável por uma zona e, por conseguinte, pelas subscrições nela mapeada, sendo que a definição da zona correspondente a subscrição é dada através do filtro utilizado. Um filtro tem a seguinte forma F= (l 1 A 1 h 1 ) (l 2 A 2 h 2 )... (l n A n h n ), ou seja, restringe um intervalo para cada um dos atributos. A igualdade é alcançada fazendo com que l e h sejam iguais ao valor desejado. Caso o cliente omita um dos atributos na criação do filtro, l e h assumem respectivamente os valores Min e Max do atributo ausente, definidos no esquema. 10

11 Figura 6: Exemplo de espaço de 2 dimensões usado pelo Meghdoot. As subscrições representam um ponto no espaço lógico dado pelas coordenadas l 1, h 1, l 2, h 2,..., l n, h n, onde l e h são extraídos do filtro. Assim, quando um cliente realiza um subscrição, esta deve ser encaminhada para o nó responsável pela zona que contém o ponto equivalente à essa subscrição. Esse nó ficará encarregado de notificar o cliente quando ocorrer um evento que satisfaça o filtro de interesse. Pela forma como o ponto é estabelecido, as subscrição sempre são mapeadas para as zonas acima do hiperplano diagonal. As zonas abaixo do hiperplano são usadas no roteamento das subscrições e das notificações. Por exemplo, considerando o espaço bidimensional da figura 7, as subscrições seriam mapeadas na região sombreada. Figura 7: Área de mapeamento das subscrições. 11

12 Os nós possuem conhecimento apenas de quem são os responsáveis pelas áreas vizinhas as suas. Quando uma subscrição é recebida por um nó, este identifica a zona a qual a subscrição pertence. Caso não seja a sua zona, o nó deve efetuar o seu roteamento da subscrição, encaminhando-a para o vizinho mais próximo da zona destino. Assim, a subscrição vai sendo encaminhada até atingir a zona correta. Da mesma forma que uma subscrição, os eventos também são mapeados em pontos no espaço para determinar quais clientes devem ser notificados. Seja um evento E = {A 1 = v 1, A 2 = v 2,..., A n = v n }, o ponto relativo a ele é p = c 11, c 12, c 21, c 22,...,c n1, c n2, onde c i1 e c i2 assumem o valor do atributo A i pertencente ao evento, por exemplo, c 11 = v 1 e c 12 = v 1. Entretanto, como o sistema de notificação assume que um evento pode não conter todos os atributos descritos no esquema, c i1 e c i2 assumem os valores Min e Max do atributo A i, caso este seja omitido no evento. Para identificar quais clientes devem ser notificados, o Meghdoot avalia a seguinte propriedade i {1, 2,...,n} l i c i1 c i2 h i (3) considerando um filtro F= (l 1 A 1 h 1 ) (l 2 A 2 h 2 )... (l n A n h n ) de um subscrição e um ponto P= c 11, c 12, c 21, c 22,..., c n1, c n2 do evento. Contudo, o sistema não avalia todas as subscrições do espaço quando um evento é publicado. De acordo com a formulação apresentada, num espaço de 2n dimensões, as subscrições que casam com um evento residem na região hiper retangular compreendida pelos pontos Min 1, c 11, Min 2, c 21,..., Min n, c n1 e c 12, Max 1, c 22, Max 2,..., c n2, Max n. Para ilustrar, a figura 8 mostra um espaço de 2 dimensões onde a região sombreada contém as subscrições que casam com o evento p={ preço=10.0}. Da mesma forma que as subscrições, uma notificação deve ser roteada para sua zona correspondente para que possa ser processada, neste caso, para que os clientes interessados no evento possam ser identificados e notificados. O processo de roteamento é idêntico ao roteamento de uma subscrição: o nó encaminha a notificação para o vizinho mais próximo da zona destino. Após atingir a zona designada e o nó responsável notificar os devidos clientes, a notificação deve ser propagadas pelas zonas que possuem interseção com a região hiper retangular referente a essa notifica, pois também podem haver clientes nessas zonas que estejam interessados no evento. Por exemplo, na figura 8, o nó responsável pela zona A recebe a publicação do evento que deve ser encaminhada para a zona Z. A notificação é então encaminhada através das zonas B e C até Z. Os clientes mapeados em Z e que estão interessados no evento são notificados (subscrições pertencentes à área sombreada de Z). O evento é então propagado para X e depois Y para que os clientes mapeadas naquelas zonas possam ser notificados. 12

13 Figura 8: Roteamento de uma notificação de evento. Essa modelagem baseada no esquema dos atributos para identificar a posição da subscrição e do evento no espaço é penalizada quando há muitos nós interessados em um evento, o que leva a concentração de uma grande quantidade de subscrições em uma única zona. Um efeito semelhante ocorre quando um mesmo tipo de evento é publicado freqüentemente por diversos clientes. O balanceamento da carga entre os nós é alcançado através da divisão e replicação de zonas. A divisão de uma zona visa reduzir o número de subscrições que um nó da rede peer-to-peer deve gerenciar. A estratégia de replicação de zona é mais aplicável quando ocorre uma grande quantidade de publicações de um mesmo evento, ou eventos muito parecidos. Isso faz com que um determinado conjunto de zonas gerem um grande fluxo de notificações para os clientes, sobrecarregando os nós responsáveis. Quando um evento está sendo propagado, os vizinhos de uma zona replicada podem selecionar qual das réplicas ficará responsável em notificar os clientes, utilizando, por exemplo, um esquema de round robing. A divisão de uma zona ou a criação de uma réplica ocorrem geralmente quando novos membros se juntam a rede. O sistema decide, baseado na carga atual, se uma zona já existente será divida em duas partes, ficando o novo membro responsável por uma delas, ou se uma réplica será gerada. 2.4 Terpstra et al. Terpstra et al. [9] propuseram um sistema de notificação peer-to-peer baseado na arquitetura de comunicação do Chord [10] juntamente com os conceitos de cobertura e fusão de filtros do Rebeca [2]. Nessa arquitetura os nós são clientes e 13

14 pontos de acesso ao mesmo tempo, ou seja, eles participam do sistema provendo acesso a outros clientes, mas também realizam suas próprias subscrições e notificam eventos. Um dos objetivos é obter um sistema mais tolerável à falhas, adicionando na arquitetura caminhos variados de roteamento, diferente do que é feito no modelo peer-to-peer do SIENA e no Rebeca, que utilizam uma árvore geradora mínima como caminho de propagação. Isso é obtido seguindo o modelo de comunicação do Chord. O Chord foi desenvolvido para mapear chaves em nós da redes de forma a localizá-las eficientemente. Ele emprega um esquema de funções hash consistentes que distribuem os nós em um espaço circular ordenado de tamanho 2 m. A posição de cada nó no círculo é dado pelo valor de retorno da função de hash aplicada ao nó esse valor é conhecido como chave do nó. Uma chave qualquer K irá residir no nó N, ou seja, N será responsável por essa chave, caso o valor da chave K seja igual ao da chave de N ou N é o nó sucessor. Considerando o espaço circular, o nó sucessor de uma chave é o primeiro nó no sentido horário após a chave. A figura 9 ilustra um espaço circular com dez nós, armazenando cinco chaves. Figura 9: Espaço circular do Chord. O Chord adota uma estratégia de que um nó N da rede mantém uma tabela de informações sobre um conjunto menor de nós. Os membros desse conjunto são os nós responsáveis pela chaves (n+2 i 1 ), onde n é o valor da chave de N e 1 i m. Assim, quando N deseja localizar uma chave K e esta não está sob a responsabilidade de um dos nós de sua tabela, N delega a busca para um nó N da tabela a seleção é baseada no valor de K [10]. Caso não saiba a localização da chave, N também pode delegar o pedido para um dos integrantes 14

15 de sua tabela. Isso prossegue até que K seja encontrada. A figura 10 mostra o processo de localização de K54, onde ocorrem duas delegações. Figura 10: Localização de uma chave no Chord. Seguindo esse esquema de delegação, o Chord tem um funcionamento semelhante às tabelas hash distribuídas utilizadas pelo Meghdoot, sendo os nós do sistemas responsáveis por partes do espaço circular. Terpstra et al. empregaram esse conceito para definir as árvores de propagação das subscrições. Cada árvore é montada tendo como raiz o nó que publica o evento. Esse nó raiz propaga o evento para os nós com chaves (n+2 i 1 ) pertencentes à tabela de localização, que demonstraram interesse pelo evento. Isso pode ser visto como se a raiz delegasse para esses nós a responsabilidade de divulgar o evento dentro de um subespaço. Nessa divulgação, o nó responsável pelo subespaço pode delegar a entrega do evento para outros nós também pertencentes ao subespaço. Como exemplo, na figura 11(a) podemos ver um nó N publicando um evento que é propagado por todo o espaço circular, considerando que todos os nós estão interessados no evento. A propagação do evento também pode ser vista como uma árvore, como mostra a figura 11(b). Se considerarmos cada nó n do sistema, percebemos que existem n árvores diferentes, ou seja, dependendo do nó que publica o notificação, esta será roteada por caminhos distintos. Este sistema de notificação emprega o algoritmo de fusão de filtros do Rebeca, e da mesma forma que ocorre na divulgação dos eventos, cada nó possui um caminho diferente para propagar as subscrições. Consideremos que o nó N deseja efetuar uma subscrição para receber um determinado tipo de evento e que o filtro é mais abrangente que os das subscrições anteriores. N propaga sua subscrição no caminho inverso que uma notificação 15

16 Figura 11: Propagação das notificações de um nó. faria até atingi-lo. Para isso, além de N manter a tabela de quais nós ele deve notificar quando um evento ocorre, N também deve possuir uma tabela T contendo quais nós notificam-no. Então, N unifica os seus filtros mais abrangentes e propaga o resultado para os nós da tabela T. Estes atualizam o interesse de N e, baseados na cobertura de filtros, analisam a necessidade de propagar para seus responsáveis o interesse de N. O processo termina quando todos os caminhos para atingir N sejam atualizados. A figura 12 mostra um exemplo de todos os caminhos percorridos por uma subscrição para um dado N da rede. Figura 12: Propagação das subscrições de um nó. 16

17 3 Comentários Finais Neste trabalho foram apresentadas as arquiteturas do SIENA, Rebeca, Meghdoot e Terpstra et al., bem como suas estratégias para prover um serviço de notificação de eventos de grande-escala. O modelo hierárquico do SIENA, ao propagar os filtro apenas para os pais, gera um número menor de mensagens de controle para manter os interesses dos consumidores, comparado com o modelo peer-to-peer. Por outro lado, quando o número de publicações aumenta, os servidores dos níveis mais altos da hierarquia lidam com um grande número de eventos, comprometendo o desempenho. Nesse caso o modelo peer-to-peer se mostra mais eficiente. Tanto o SIENA como o Rebeca empregam algoritmos de cobertura de filtros para designar a propagação dos eventos. O Rebeca disponibiliza ainda mais três outros algoritmos de roteamento e uma arquitetura extensível que permite o acoplamento de novos algoritmos sem afetar o funcionamento do sistema. O Rebeca também implementa o histórico de notificações, o que possibilita que os clientes recuperem eventos publicados anteriormente. Essa funcionalidade é comumente empregada por aplicações que se baseiam em contexto ou que que necessitam do estado atual para seu funcionamento. Meghdoot utiliza uma arquitetura peer-to-peer, com entradas e partidas de servidores, e um esquema de tabelas hash distribuídas que mapeia subscrições e eventos em zonas de um espaço lógico. Os testes mostraram que o seu algoritmo de roteamento baseado em zonas utiliza poucos nós da infra-estrutura do sistema até que o evento seja notificado aos interessados [7]. O Meghdoot também provê dois mecanismos de balanceamento de carga que consistem em divisão e replicação das zonas. No Rebeca e no SIENA há apenas um caminho de propagação, o que pode levar ao particionamento da rede caso um dos servidores da arquitetura falhe. O sistema desenvolvido por Terpstra et al. utiliza conceitos do Chord para definir caminhos diferenciados de propagação das subscrições e dos eventos na tentativa de reduzir os dados no caso de falha de um dos membros da rede. Alguns trabalhos estão avaliando o uso de serviços de notificação empregando publish/subscribe para comunicação com dispositivos móveis, cujos requisitos casam com as características do modelo publish/subscribe, principalmente o assincronismo e o desacoplamento [11, 12, 13]. Referências [1] Antonio Carzaniga, David S. Rosenblum, and Alexander L. Wolf. Design and evaluation of a wide-area event notification service. ACM Trans. Com- 17

18 put. Syst., 19(3): , [2] Gero Mühl. Large-Scale Content-Based Publish/Subscribe Systems. PhD thesis, Darmstadt University of Technology, [3] Patrick Th. Eugster, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. The many faces of publish/subscribe. ACM Comput. Surv., 35(2): , [4] The Gryphon Team. Achieving scalability and throughput in a publish/subscribe system. Technical report, IBM Research Report, February [5] Antonio Carzaniga, David S. Rosenblum, and Alexander L. Wolf. Achieving scalability and expressiveness in an internet-scale event notification service. In PODC 00: Proceedings of the 19th annual ACM symposium on Principles of distributed computing, pages , New York, NY, USA, ACM Press. [6] Gero Mühl, Andreas Ulbrich, Klaus Herrmann, and Torben Weis. Disseminating information to mobile clients using publish-subscribe. IEEE Internet Computing, 8(3):46 53, May [7] Abhishek Gupta, Ozgur D. Sahin, Divyakant Agrawal, and Amr El Abbadi. Meghdoot: content-based publish/subscribe over p2p networks. In Proceedings of the 5th ACM/IFIP/USENIX international conference on Middleware, pages , New York, NY, USA, Springer-Verlag New York, Inc. [8] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and Scott Schenker. A scalable content-addressable network. In SIGCOMM 01: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, pages , New York, NY, USA, ACM Press. [9] Wesley W. Terpstra, Stefan Behnel, Ludger Fiege, Andreas Zeidler, and Alejandro P. Buchmann. A peer-to-peer approach to content-based publish/subscribe. In DEBS 03: Proceedings of the 2nd international workshop on Distributed event-based systems, pages 1 8, New York, NY, USA, ACM Press. [10] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan. Chord: A scalable peer-to-peer lookup service for internet applications. In SIGCOMM 01: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, pages , New York, NY, USA, ACM Press. 18

19 [11] Mauro Caporuscio, Antonio Carzaniga, and Alexander L. Wolf. Design and evaluation of a support service for mobile, wireless publish/subscribe applications. IEEE Transactions on Software Engineering, 29(12): , December [12] Ludger Fiege, Felix C.Gartner, Oliver Kasten, and Andreas Zeidler. Supporting mobility in content-based publish/subscribe middleware. In Proceedings of Middleware 2003, pages , [13] Yongqiang Huang and Hector Garcia-Molina. Publish/subscribe in a mobile environment. Wirel. Netw., 10(6): ,

3 Arquitetura do Sistema

3 Arquitetura do Sistema 3 Arquitetura do Sistema Este capítulo irá descrever a arquitetura geral do sistema, justificando as decisões de implementação tomadas. Na primeira seção iremos considerar um conjunto de nós interagindo

Leia mais

Chord. Tecnologias de Middleware. Fernando Martins - fmp.martins@gmail.com

Chord. Tecnologias de Middleware. Fernando Martins - fmp.martins@gmail.com Chord Tecnologias de Middleware 2006/2007 Fernando Martins - fmp.martins@gmail.com Tópicos Objectivo Motivação Peer-To-Peer Chord Descrição Geral Características Distintivas Comparação DNS Modelo do Sistema

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Arquiteturas Capítulo 2 Agenda Estilos Arquitetônicos Arquiteturas de Sistemas Arquiteturas Centralizadas Arquiteturas Descentralizadas Arquiteturas

Leia mais

Peer-to-Peer. Introdução. Motivação. Definição. Definição. Definição. Everton Flávio Rufino Seára Murilo R. de Lima

Peer-to-Peer. Introdução. Motivação. Definição. Definição. Definição. Everton Flávio Rufino Seára Murilo R. de Lima Introdução Peer-to-Peer Everton Flávio Rufino Seára Murilo R. de Lima Peer-to-Peer (P2P) é a base da operação de sistemas distribuídos como SETI@home e Kazaa; caracterizada por compartilhamento direto

Leia mais

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido Arquitetura Roteiro Arquitetura Tipos de Arquitetura Centralizado Descentralizado Hibrido Questionário 2 Arquitetura Figura 1: Planta baixa de uma casa 3 Arquitetura Engenharia de Software A arquitetura

Leia mais

PEER DATA MANAGEMENT SYSTEM

PEER DATA MANAGEMENT SYSTEM PEER DATA MANAGEMENT SYSTEM INTRODUÇÃO, INFRA-ESTRUTURA E MAPEAMENTO DE ESQUEMAS AGENDA Data Management System Peer Data Management System P2P Infra-estrutura Funcionamento do PDMS Mapeamento de Esquemas

Leia mais

Uma API Pub/Sub para Aplicações Móveis Sensíveis ao Contexto

Uma API Pub/Sub para Aplicações Móveis Sensíveis ao Contexto Uma API Pub/Sub para Aplicações Móveis Sensíveis ao Contexto Gustavo Baptista, Markus Endler, Hana Rubinsztejn Pontifícia Universidade Católica do Rio de Janeiro (PUC-RJ) R. Marquês de São Vicente, 225

Leia mais

O que são DNS, SMTP e SNM

O que são DNS, SMTP e SNM O que são DNS, SMTP e SNM O DNS (Domain Name System) e um esquema de gerenciamento de nomes, hierárquico e distribuído. O DNS define a sintaxe dos nomes usados na Internet, regras para delegação de autoridade

Leia mais

Diego Takashi Sato Pollyanna Fernandes Moreira SISTEMAS DISTRIBUÍDOS PROFESSOR VAGNER SACRAMENTO

Diego Takashi Sato Pollyanna Fernandes Moreira SISTEMAS DISTRIBUÍDOS PROFESSOR VAGNER SACRAMENTO Um serviço escalável de busca P2P para aplicações da Internet Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan MIT Laboratory for Computer Science Diego Takashi Sato Pollyanna

Leia mais

Definição São sistemas distribuídos compostos de nós interconectados, aptos a se auto-organizar em topologias de rede, com o intuito de compartilhar

Definição São sistemas distribuídos compostos de nós interconectados, aptos a se auto-organizar em topologias de rede, com o intuito de compartilhar Redes Peer-to-Peer Redes Peer-to to-peer Arquitetura de Redes P2P Integridade e Proteção Redes Peer-to-Peer (P2P) São sistemas distribuídos nos quais os membros da rede são equivalentes em funcionalidade

Leia mais

O Padrão Arquitetural Auto-Adaptável

O Padrão Arquitetural Auto-Adaptável MAC5715 - Tópicos Avançados em POO O Padrão Arquitetural Auto-Adaptável Raphael Y. de Camargo e Carlos Alexandre Queiroz 30 de outubro de 2003 1 Intenção O padrão auto-adaptável permite o desenvolvimento

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Roteamento IP Redes de Computadores Objetivo Conhecer o modelo de roteamento da arquitetura TCP/IP Entender os conceitos básicos de algoritmo, métrica, tabela e protocolos de roteamento

Leia mais

Sistemas Distribuídos. Introdução

Sistemas Distribuídos. Introdução Sistemas Distribuídos Introdução Definição Processos Um sistema distribuído é um conjunto de computadores independentes, interligados por uma rede de conexão, executando um software distribuído. Executados

Leia mais

Aplicações P2P. André Lucio e Gabriel Argolo

Aplicações P2P. André Lucio e Gabriel Argolo Aplicações P2P André Lucio e Gabriel Argolo Tópicos Internet Peer-to-Peer (Introdução) Modelos (Classificação) Napster Gnutella DHT KaZaA Razões para o Sucesso da Internet Capacidade de interligar várias

Leia mais

Definição São sistemas distribuídos compostos de nós interconectados, aptos a se auto-organizar em topologias de rede, com o intuito de compartilhar

Definição São sistemas distribuídos compostos de nós interconectados, aptos a se auto-organizar em topologias de rede, com o intuito de compartilhar Redes Peer- Redes Peer- (P2P) São sistemas distribuídos nos quais os membros da rede são equivalentes em funcionalidade Permitem que os pares compartilhem recursos diretamente, sem envolver intermediários

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Curso de Tecnologia em Redes de Computadores Disciplina: Redes I Fundamentos - 1º Período Professor: José Maurício S. Pinheiro Material de Apoio IV TOPOLOGIAS

Leia mais

Redes de Computadores I Conceitos Básicos

Redes de Computadores I Conceitos Básicos Redes de Computadores I Conceitos Básicos (11 a. Semana de Aula) Prof. Luís Rodrigo lrodrigo@lncc.br http://lrodrigo.lncc.br 2011.02 v1 2011.11.03 (baseado no material de Jim Kurose e outros) Algoritmos

Leia mais

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim Redes TCP/IP alexandref@ifes.edu.br Camada de Redes (Continuação) 2 Camada de Rede 3 NAT: Network Address Translation restante da Internet 138.76.29.7 10.0.0.4 rede local (ex.: rede doméstica) 10.0.0/24

Leia mais

2 Fundamentação Conceitual

2 Fundamentação Conceitual Fundamentação Conceitual 19 2 Fundamentação Conceitual Este capítulo apresenta alguns conceitos importantes que são utilizados ao longo do trabalho. Primeiramente, é apresentado o Session Initiation Protocol

Leia mais

Tópicos Especiais em Redes de Telecomunicações

Tópicos Especiais em Redes de Telecomunicações Tópicos Especiais em Redes de Telecomunicações Redes definidas por software e Computação em Nuvem Prof. Rodrigo de Souza Couto Informações Gerais Prof. Rodrigo de Souza Couto E-mail: rodsouzacouto@ieee.org

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Basedos na Web Capítulo 12 Agenda Arquitetura Processos Comunicação Nomeação Sincronização Consistência e Replicação Introdução

Leia mais

Roteamento e Comutação

Roteamento e Comutação Roteamento e Comutação Design de Rede Local Design Hierárquico Este design envolve a divisão da rede em camadas discretas. Cada camada fornece funções específicas que definem sua função dentro da rede

Leia mais

Aula 7 Protocolos de roteamento:

Aula 7 Protocolos de roteamento: Aula 7 Protocolos de roteamento: Roteamento Estático; Roteamento dinâmico. Camada de rede A camada de rede está relacionada à transferência de pacotes da origem para o destino. Para que se chegue ao destino,

Leia mais

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros Em geral sistemas seguem um estilo, ou padrão, de organização estrutural Os estilos diferem: nos tipos de componentes que usa na maneira como os componentes interagem com os outros (regras de interação)

Leia mais

Resumo. Introdução História Caracteristicas Exemplos Arquitetura Distribuição Vertical vs Distribuição Horizontal Segurança Conclusão

Resumo. Introdução História Caracteristicas Exemplos Arquitetura Distribuição Vertical vs Distribuição Horizontal Segurança Conclusão Peer 2 Peer (P2P) Resumo Introdução História Caracteristicas Exemplos Arquitetura Distribuição Vertical vs Distribuição Horizontal Segurança Conclusão O que é P2P? Introdução Tipo de arquitetura de rede

Leia mais

Conceito de Rede e seus Elementos. Prof. Marciano dos Santos Dionizio

Conceito de Rede e seus Elementos. Prof. Marciano dos Santos Dionizio Conceito de Rede e seus Elementos Prof. Marciano dos Santos Dionizio Conceito de Rede e seus Elementos O conceito de rede segundo Tanenbaum é: um conjunto de módulos processadores capazes de trocar informações

Leia mais

Gerência de Redes. Arquitetura de Gerenciamento. filipe.raulino@ifrn.edu.br

Gerência de Redes. Arquitetura de Gerenciamento. filipe.raulino@ifrn.edu.br Gerência de Redes Arquitetura de Gerenciamento filipe.raulino@ifrn.edu.br Sistema de Gerência Conjunto de ferramentas integradas para o monitoramento e controle. Possui uma interface única e que traz informações

Leia mais

CAPÍTULO 12 CONCLUSÃO

CAPÍTULO 12 CONCLUSÃO CAPÍTULO 12 CONCLUSÃO Existe somente um avanço. A hora mais escura da noite é o prenúncio do alvorecer. Nos dias sombrios de inverno, prosseguem incessantemente os preparativos para a primavera. Tudo que

Leia mais

Tópicos Especiais em Redes de Telecomunicações

Tópicos Especiais em Redes de Telecomunicações Tópicos Especiais em Redes de Telecomunicações Redes definidas por software e Computação em Nuvem Prof. Rodrigo de Souza Couto PARTE 1 REDES DEFINIDAS POR SOFTWARE (SDN) 2 Bibliografia Esta aula é baseada

Leia mais

Tabela de roteamento

Tabela de roteamento Existem duas atividades que são básicas a um roteador. São elas: A determinação das melhores rotas Determinar a melhor rota é definir por qual enlace uma determinada mensagem deve ser enviada para chegar

Leia mais

BlackBerry Mobile Voice System

BlackBerry Mobile Voice System BlackBerry Mobile Voice System Comunicações móveis unificadas O BlackBerry Mobile Voice System (BlackBerry MVS) leva os recursos do telefone do escritório aos smartphones BlackBerry. Você pode trabalhar

Leia mais

CAPÍTULO 7 O SERVIÇO DOS AGENTES

CAPÍTULO 7 O SERVIÇO DOS AGENTES CAPÍTULO 7 O SERVIÇO DOS AGENTES A inteligência... é a capacidade de criar objetos artificiais, especialmente ferramentas para fazer ferramentas. ( Henri Bergson) O serviço dos agentes surge como uma prestação

Leia mais

Equipamentos de Rede. Prof. Sérgio Furgeri 1

Equipamentos de Rede. Prof. Sérgio Furgeri 1 Equipamentos de Rede Repetidor (Regenerador do sinal transmitido)* Mais usados nas topologias estrela e barramento Permite aumentar a extensão do cabo Atua na camada física da rede (modelo OSI) Não desempenha

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

Roteamento em Redes de Computadores

Roteamento em Redes de Computadores Roteamento em Redes de Computadores José Marcos Câmara Brito INATEL - Instituto Nacional de Telecomunicações INATEL - Instituto Nacional de Telecomunicações 01/08/00 1 Introdução Objetivo Tipos de rede

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Arquiteturas Ponto a Ponto

Sistemas Distribuídos: Conceitos e Projeto Arquiteturas Ponto a Ponto Sistemas Distribuídos: Conceitos e Projeto Arquiteturas Ponto a Ponto Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.deinf.ufma.br

Leia mais

Prof. Wilton O. Ferreira Universidade Federal Rural de Pernambuco UFRPE 1º Semestre / 2012

Prof. Wilton O. Ferreira Universidade Federal Rural de Pernambuco UFRPE 1º Semestre / 2012 Prof. Wilton O. Ferreira Universidade Federal Rural de Pernambuco UFRPE 1º Semestre / 2012 As redes de computadores possibilitam que indivíduos possam trabalhar em equipes, compartilhando informações,

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

BlackBerry Mobile Voice System

BlackBerry Mobile Voice System BlackBerry Mobile Voice System BlackBerry Mobile Voice System Comunicações móveis unificadas O Mobile Voice System ( MVS) foi projetado para unificar os recursos do telefone fixo aos smartphones e às redes

Leia mais

Conceitos sobre TCP/IP. Endereços IP (Internet Protocol) Introdução

Conceitos sobre TCP/IP. Endereços IP (Internet Protocol) Introdução Conceitos sobre TCP/IP Endereços IP (Internet Protocol) Introdução O uso de computadores em rede e, claro, a internet, requer que cada máquina tenha um identificador que a diferencie das demais. Para isso,

Leia mais

Sistemas de Nomes Planos

Sistemas de Nomes Planos Sistemas de Nomes Planos November 2, 2009 Sumário Sistemas de Nomes Planos e DHTs Chord Sistemas de Nomes Planos Tipicamente, sistemas de nomes à escala da Internet usam nomes estruturados hierarquicamente.

Leia mais

Tecnologia de Redes de Computadores - aula 5

Tecnologia de Redes de Computadores - aula 5 Tecnologia de Redes de Computadores - aula 5 Prof. Celso Rabelo Centro Universitário da Cidade 1 Objetivo 2 3 4 IGPxEGP Vetor de Distância Estado de Enlace Objetivo Objetivo Apresentar o conceito de. Conceito

Leia mais

Um Arcabouço open source em Python para DBC com

Um Arcabouço open source em Python para DBC com Um Arcabouço open source em Python para DBC com Suporte à Evolução Dinâmica não Antecipada Yguaratã C. Cavacanti 1, Hyggo Oliveira de Almeida 1, Evandro Costa 2 1 Instituto de Computação Universidade Federal

Leia mais

Arquitetura dos Sistemas de Informação Distribuídos

Arquitetura dos Sistemas de Informação Distribuídos Arquitetura dos Sistemas de Informação Distribuídos Quando se projeta um sistema cuja utilização é destinada a ser feita em ambientes do mundo real, projeções devem ser feitas para que o sistema possa

Leia mais

09/06/2011. Profª: Luciana Balieiro Cosme

09/06/2011. Profª: Luciana Balieiro Cosme Profª: Luciana Balieiro Cosme Revisão dos conceitos gerais Classificação de redes de computadores Visão geral sobre topologias Topologias Barramento Anel Estrela Hibridas Árvore Introdução aos protocolos

Leia mais

Aula 21: Roteamento em Redes de Dados

Aula 21: Roteamento em Redes de Dados Aula : Roteamento em Redes de Dados Slide Redes de Pacotes Comutados Mensagens dividas em Pacotes que são roteados ao seu destino PC PC PC Rede de Pacotes PC PC PC PC Buffer Pacote Comutado Slide Roteamento

Leia mais

Gerenciamento de Redes

Gerenciamento de Redes Gerenciamento de Redes As redes de computadores atuais são compostas por uma grande variedade de dispositivos que devem se comunicar e compartilhar recursos. Na maioria dos casos, a eficiência dos serviços

Leia mais

Uma Abordagem Híbrida Cliente-Servidor e Peer-to-Peer para Distribuição de Fluxos Multímidia

Uma Abordagem Híbrida Cliente-Servidor e Peer-to-Peer para Distribuição de Fluxos Multímidia 4º Workshop de Peer-to-Peer 11 Uma Abordagem Híbrida Cliente-Servidor e Peer-to-Peer para Distribuição de Fluxos Multímidia Samuel L. V. Mello, Elias P. Duarte Jr. 1 Universidade Federal do Paraná Departamento

Leia mais

Sistemas Distribuídos. Nomeação. Nazareno Andrade. Universidade Federal de Campina Grande 02/2008

Sistemas Distribuídos. Nomeação. Nazareno Andrade. Universidade Federal de Campina Grande 02/2008 Sistemas Distribuídos Nomeação Nazareno Andrade Universidade Federal de Campina Grande 02/2008 Fundamentos Coordenando processos Construíndo sistemas Sistemas construídos 2 Fundamentos Coordenando processos

Leia mais

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2014

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2014 MC714 Sistemas Distribuídos 2 semestre, 2014 Nomeação Nomeação Compartilhar recursos, identificar entidades de maneira única, fazer referência a localizações... Resolução de nomes Espaço de nomes e implementação

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos Aula II Prof. Rosemary Silveira F. Melo Arquitetura de Sistemas Distribuídos Conceito de Arquitetura de Software Principais elementos arquiteturais

Leia mais

BlackBerry Mobile Voice System Versão: 5.0 Service pack: 1. Visão geral técnica e dos recursos

BlackBerry Mobile Voice System Versão: 5.0 Service pack: 1. Visão geral técnica e dos recursos BlackBerry Mobile Voice System Versão: 5.0 Service pack: 1 Visão geral técnica e dos recursos SWD-1031491-1025120324-012 Conteúdo 1 Visão geral... 3 2 Recursos... 4 Recursos para gerenciar contas de usuário

Leia mais

MPLS MultiProtocol Label Switching

MPLS MultiProtocol Label Switching MPLS MultiProtocol Label Switching Cenário Atual As novas aplicações que necessitam de recurso da rede são cada vez mais comuns Transmissão de TV na Internet Videoconferências Jogos on-line A popularização

Leia mais

Packet Tracer 4.0: Overview Session. Conceitos e práticas

Packet Tracer 4.0: Overview Session. Conceitos e práticas Packet Tracer 4.0: Overview Session Conceitos e práticas Processo de Flooding ou Inundação envia informações por todas as portas, exceto aquela em que as informações foram recebidas; Cada roteador link-state

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS Arquiteturas www.pearson.com.br capítulo 2 slide 1 2.1 Estilos Arquitetônicos Formado em termos de componentes, do modo como esses componentes estão conectados uns aos outros, dos dados trocados entre

Leia mais

Transferindo a carga da autenticação remota dos servidores

Transferindo a carga da autenticação remota dos servidores Transferindo a carga da autenticação remota dos servidores Visão Geral Há três etapas usadas pela maioria dos computadores para proteger o acesso a operações, aplicativos e dados sensíveis: A identificação

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Nomes, Identificadores, Endereços Nomeação Simples Capítulo 5 Agenda Nomes, Identificadores e Endereços Definição Nomeação Simples Soluções Simples

Leia mais

CAMADA DE REDES. Fabrício de Sousa Pinto

CAMADA DE REDES. Fabrício de Sousa Pinto CAMADA DE REDES Fabrício de Sousa Pinto Introdução 2 Está relacionada a transferência de pacotes da origem para o destino. Pode passar por vários roteadores ao longo do percurso Transmissão fim a fim Para

Leia mais

Um Sistema de Arquivos Compartilhado em Nível de Usuário Baseado em Tabelas Hash Distribuídas

Um Sistema de Arquivos Compartilhado em Nível de Usuário Baseado em Tabelas Hash Distribuídas Um Sistema de Arquivos Compartilhado em Nível de Usuário Baseado em Tabelas Hash Distribuídas Pedro Eugênio Rocha, Luiz Carlos Erpen de Bona Departamento de Informática Universidade Federal do Paraná Caixa

Leia mais

APOSTILA DE REDES DE COMPUTADORES PARTE - III

APOSTILA DE REDES DE COMPUTADORES PARTE - III APOSTILA DE REDES DE COMPUTADORES PARTE - III 1 REDE DE COMPUTADORES III 1. Introdução MODELO OSI ISO (International Organization for Standardization) foi uma das primeiras organizações a definir formalmente

Leia mais

Interconexão redes locais (LANs)

Interconexão redes locais (LANs) Interconexão redes locais (LANs) Descrever o método de funcionamento dos dispositivos bridge e switch, desenvolver os conceitos básicos de LANs intermediárias, do uso do protocolo STP e VLANs. Com o método

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO Santa Maria, 01 de Novembro de 2013. Revisão aula passada Projeto de Arquitetura Decisões de projeto de Arquitetura

Leia mais

EXEMPLO: Processo para atualização da hora Processo para monitoramento da necessidade de proteção de tela. Figura 4-1 - Exemplo

EXEMPLO: Processo para atualização da hora Processo para monitoramento da necessidade de proteção de tela. Figura 4-1 - Exemplo 4 PROCESSOS Os primeiros sistemas operacionais permitiam que apenas um processo fosse executado por vez. Dessa maneira, este processo tinha todo o sistema computacional a sua disposição. Os atuais sistemas

Leia mais

Cap 01 - Conceitos Básicos de Rede (Kurose)

Cap 01 - Conceitos Básicos de Rede (Kurose) Cap 01 - Conceitos Básicos de Rede (Kurose) 1. Quais são os tipos de redes de computadores e qual a motivação para estudá-las separadamente? Lan (Local Area Networks) MANs(Metropolitan Area Networks) WANs(Wide

Leia mais

SISTEMAS DISTRIBUIDOS

SISTEMAS DISTRIBUIDOS 1 2 Caracterização de Sistemas Distribuídos: Os sistemas distribuídos estão em toda parte. A Internet permite que usuários de todo o mundo acessem seus serviços onde quer que possam estar. Cada organização

Leia mais

Capítulo 10 - Conceitos Básicos de Roteamento e de Sub-redes. Associação dos Instrutores NetAcademy - Julho de 2007 - Página

Capítulo 10 - Conceitos Básicos de Roteamento e de Sub-redes. Associação dos Instrutores NetAcademy - Julho de 2007 - Página Capítulo 10 - Conceitos Básicos de Roteamento e de Sub-redes 1 Protocolos Roteáveis e Roteados Protocolo roteado: permite que o roteador encaminhe dados entre nós de diferentes redes. Endereço de rede:

Leia mais

Todos os arquivos.c e.h criados (exigido código muito bem documentado!). O makefile.

Todos os arquivos.c e.h criados (exigido código muito bem documentado!). O makefile. Universidade Federal do Espírito Santo Departamento de Informática Estruturas de Dados I (INF09292) 1o Trabalho Prático Período: 2014/2 Profa Patrícia Dockhorn Costa Email: pdcosta@inf.ufes.br Data de

Leia mais

Interconexão de Redes Parte 3. Prof. Dr. S. Motoyama

Interconexão de Redes Parte 3. Prof. Dr. S. Motoyama Interconexão de Redes Parte 3 Prof. Dr. S. Motoyama Protocolo de configuração dinâmica de host - DHCP DHCP proporciona uma estrutura para passar informação de configuração aos hosts (de maneira dinâmica

Leia mais

SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 3 - ARQUITETURA DE SISTEMAS DISTRIBUÍDOS 1 INTRODUÇÃO Considerando que os Sistemas Distribuídos são constituídos de vários processadores, existem diversas formas de organizar o hardware de tais

Leia mais

unesp UNIVERSIDADE ESTADUAL PAULISTA

unesp UNIVERSIDADE ESTADUAL PAULISTA unesp UNIVERSIDADE ESTADUAL PAULISTA Administração de Redes TCP/IP Roteamento: Sistemas Autônomos e EGP Prof. Dr. Adriano Mauro Cansian adriano@ieee.org UNESP - IBILCE - São José do Rio Preto 2001 1. Introdução

Leia mais

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013 MC714 Sistemas Distribuídos 2 semestre, 2013 Virtualização - motivação Consolidação de servidores. Consolidação de aplicações. Sandboxing. Múltiplos ambientes de execução. Hardware virtual. Executar múltiplos

Leia mais

5.2 MAN s (Metropolitan Area Network) Redes Metropolitanas

5.2 MAN s (Metropolitan Area Network) Redes Metropolitanas MÓDULO 5 Tipos de Redes 5.1 LAN s (Local Area Network) Redes Locais As LAN s são pequenas redes, a maioria de uso privado, que interligam nós dentro de pequenas distâncias, variando entre 1 a 30 km. São

Leia mais

Arquitetura de Rede de Computadores

Arquitetura de Rede de Computadores TCP/IP Roteamento Arquitetura de Rede de Prof. Pedro Neto Aracaju Sergipe - 2011 Ementa da Disciplina 4. Roteamento i. Máscara de Rede ii. Sub-Redes iii. Números Binários e Máscara de Sub-Rede iv. O Roteador

Leia mais

Arquitetura de uma Rede JXTA

Arquitetura de uma Rede JXTA Page 1 of 6 Redes de Proteção SP Produtos de Rede Confiança e credibilidade. fone Produtos TrendNet: qualidade, (011) 6197-0707 garantia e ótimo custo/benefício. www.tudoderedesdeprotecao.com.br http://www.trendware.com.br

Leia mais

Arquitetura do Protocolo da Internet. Aula 05 - Protocolos de Roteamento. Prof. Esp. Camilo Brotas Ribeiro cribeiro@catolica-es.edu.

Arquitetura do Protocolo da Internet. Aula 05 - Protocolos de Roteamento. Prof. Esp. Camilo Brotas Ribeiro cribeiro@catolica-es.edu. Arquitetura do Protocolo da Internet Aula 05 - Protocolos de Roteamento Prof. Esp. Camilo Brotas Ribeiro cribeiro@catolica-es.edu.br Revisão Roteamento; Gateway; Tabelas de Roteamento; Slide 2 de 82 Rotas?!

Leia mais

Introdução ao Modelos de Duas Camadas Cliente Servidor

Introdução ao Modelos de Duas Camadas Cliente Servidor Introdução ao Modelos de Duas Camadas Cliente Servidor Desenvolvimento de Sistemas Cliente Servidor Prof. Esp. MBA Heuber G. F. Lima Aula 1 Ciclo de Vida Clássico Aonde estamos? Page 2 Análise O que fizemos

Leia mais

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING http://www.uniriotec.br/~tanaka/tin0036 tanaka@uniriotec.br Bancos de Dados Distribuídos Conceitos e Arquitetura Vantagens das Arquiteturas C/S (em relação

Leia mais

Módulo 8. Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados

Módulo 8. Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados Módulo 8 Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados 1 Roteamento IP (Internet Protocol) 2 Roteamento IP 3 Roteamento IP Tarefa executada pelo protocolo

Leia mais

Fundamentos de Redes de Computadores. Elementos de Redes Locais

Fundamentos de Redes de Computadores. Elementos de Redes Locais Fundamentos de Redes de Computadores Elementos de Redes Locais Contexto Implementação física de uma rede de computadores é feita com o auxílio de equipamentos de interconexão (repetidores, hubs, pontos

Leia mais

Prof. Samuel Henrique Bucke Brito

Prof. Samuel Henrique Bucke Brito - Roteamento www.labcisco.com.br ::: shbbrito@labcisco.com.br Prof. Samuel Henrique Bucke Brito Roteamento Roteamento é a técnica que define por meio de um conjunto de regras como os dados originados em

Leia mais

3 Gerenciamento de Mobilidade

3 Gerenciamento de Mobilidade Gerenciamento de Mobilidade 38 3 Gerenciamento de Mobilidade A Internet não foi originalmente projetada para suportar a mobilidade de dispositivos. A infra-estrutura existente e o conjunto dos principais

Leia mais

Evolução na Comunicação de

Evolução na Comunicação de Evolução na Comunicação de Dados Invenção do telégrafo em 1838 Código Morse. 1º Telégrafo Código Morse Evolução na Comunicação de Dados A evolução da comunicação através de sinais elétricos deu origem

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

3 Ferramenta de Simulação

3 Ferramenta de Simulação 3 Ferramenta de Simulação Para definir a ferramenta de simulação a ser utilizada para implementação do protocolo HIP e para coleta dos resultados de simulação com uso desse protocolo, realizou-se um estudo

Leia mais

Rede de Computadores II

Rede de Computadores II Slide 1 Técnicas para se alcançar boa qualidade de serviço Reserva de recursos A capacidade de regular a forma do tráfego oferecido é um bom início para garantir a qualidade de serviço. Mas Dispersar os

Leia mais

IGMP - Internet Group Management Protocol

IGMP - Internet Group Management Protocol IGMP - Internet Group Management Protocol Introdução A entrega Multicast IP é seletiva: apenas estações interessadas podem receber tráfego dirigido a um dado grupo. Almejando implementar essas árvores

Leia mais

Collaboration Map Collaboration Map. Figura 6.1: Arquitetura da aplicação

Collaboration Map Collaboration Map. Figura 6.1: Arquitetura da aplicação 6 Estudo de caso A utilização de um modelo de componentes orientado a serviços possibilita a construção de aplicações por meio da conexão entre componentes em tempo de execução. O middleware Kaluana utiliza-se

Leia mais

A Camada de Rede. A Camada de Rede

A Camada de Rede. A Camada de Rede Revisão Parte 5 2011 Modelo de Referência TCP/IP Camada de Aplicação Camada de Transporte Camada de Rede Camada de Enlace de Dados Camada de Física Funções Principais 1. Prestar serviços à Camada de Transporte.

Leia mais

Arquitetura de SGBD. Prof. Antonio Almeida de Barros Junior

Arquitetura de SGBD. Prof. Antonio Almeida de Barros Junior Arquitetura de SGBD Prof. Antonio Almeida de Barros Junior Agenda Caracterização de SGBDs SGBDs Centralizados SGBDs Cliente-Servidor SGBDs Distribuídos Homogêneos Multi-SGBDs Heterogêneos SGBDs Paralelos

Leia mais

REDES DE COMPUTADORES. Camada de Rede. Prof.: Agostinho S. Riofrio

REDES DE COMPUTADORES. Camada de Rede. Prof.: Agostinho S. Riofrio REDES DE COMPUTADORES Camada de Rede Prof.: Agostinho S. Riofrio Agenda 1. Introdução 2. Funções 3. Serviços oferecidos às Camadas superiores 4. Redes de Datagramas 5. Redes de Circuitos Virtuais 6. Comparação

Leia mais

On Scalability of Software-Defined Networking

On Scalability of Software-Defined Networking On Scalability of Software-Defined Networking Bruno dos Santos Silva bruno.silva@ic.uff.br Instituto de Computação IC Universidade Federal Fluminense UFF 24 de Setembro de 2015 B. S. Silva (IC-UFF) On

Leia mais

Introdução a computação móvel. Middlewares para Rede de Sensores sem Fio. Uma avaliação na ótica de Adaptação ao Contexto

Introdução a computação móvel. Middlewares para Rede de Sensores sem Fio. Uma avaliação na ótica de Adaptação ao Contexto Introdução a computação móvel Monografia: Middlewares para Rede de Sensores sem Fio Uma avaliação na ótica de Adaptação ao Contexto Adriano Branco Agenda Objetivo do trabalho O que é uma WSN Middlewares

Leia mais

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos MÓDULO 7 Modelo OSI A maioria das redes são organizadas como pilhas ou níveis de camadas, umas sobre as outras, sendo feito com o intuito de reduzir a complexidade do projeto da rede. O objetivo de cada

Leia mais

Roteamento e Comutação

Roteamento e Comutação Roteamento e Comutação Uma estação é considerada parte de uma LAN se pertencer fisicamente a ela. O critério de participação é geográfico. Quando precisamos de uma conexão virtual entre duas estações que

Leia mais

3. Comunicação em Sistemas Distribuídos

3. Comunicação em Sistemas Distribuídos 3. Comunicação em 3.1.Troca de mensagens As mensagens são objetos de dados cuja estrutura e aplicação são definidas pelas próprias aplicações que a usarão. Sendo a troca de mensagens feita através de primitivas

Leia mais

Descoberta de Domínio Conceitual de Páginas Web

Descoberta de Domínio Conceitual de Páginas Web paper:25 Descoberta de Domínio Conceitual de Páginas Web Aluno: Gleidson Antônio Cardoso da Silva gleidson.silva@posgrad.ufsc.br Orientadora: Carina Friedrich Dorneles dorneles@inf.ufsc.br Nível: Mestrado

Leia mais