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

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

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

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

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

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

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

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

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

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

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

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

Arquitectura híbrida para publicação e subscrição de informação na Internet

Arquitectura híbrida para publicação e subscrição de informação na Internet Arquitectura híbrida para publicação e subscrição de informação na Internet Mário L. J. R. Guimarães 1, Luís E. T. Rodrigues 2 1 Faculdade de Ciências da Universidade de Lisboa, 1749 Lisboa {mljrg@yahoo.com}

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

Algoritmo Distribuído com abordagem em cache cooperativo

Algoritmo Distribuído com abordagem em cache cooperativo Algoritmo Distribuído com abordagem em cache cooperativo Pedro Paulo Simões Freitas, Ricardo Augusto Rabelo PPGCC - Programa de Pós-Graduação em Ciência da Computação UFOP - Universidade Federal de Ouro

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

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

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

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

Implementação de um Algoritmo para Busca em Redes Peer-to-Peer

Implementação de um Algoritmo para Busca em Redes Peer-to-Peer Implementação de um Algoritmo para Busca em Redes Peer-to-Peer André Panisson, Maria Janilce Bosquiroli Almeida, Liane Margarida Tarouco, Lisandro Zambenedetti Granville Universidade Federal do Rio Grande

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

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

Uma Arquitetura P2P Baseada na Hierarquia do Endereçamento IP

Uma Arquitetura P2P Baseada na Hierarquia do Endereçamento IP Uma Arquitetura P2P Baseada na Hierarquia do Endereçamento IP Marcos Madruga 1, Thaís Batista 2, Luiz Affonso Guedes 1 1 Departamento de Engenharia da Computação e Automação (DCA) Universidade Federal

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

5 NOVA PROPOSTA DE TOLERÂNCIA À FALHA DOS AGENTES DE MOILIDADE

5 NOVA PROPOSTA DE TOLERÂNCIA À FALHA DOS AGENTES DE MOILIDADE 5 NOVA PROPOSTA DE TOLERÂNCIA À FALHA DOS AGENTES DE MOILIDADE Neste capítulo será descrita uma nova a proposta de tolerância à falha dos Agentes Estrangeiros e uma outra proposta para os Agentes de Origem,

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

8 Bibliografia. ACEAUME, E. et al. On The Formal Specification of Group Membership Services. INRIA, 1995, 15 p. Relatório Técnico TR95-1534.

8 Bibliografia. ACEAUME, E. et al. On The Formal Specification of Group Membership Services. INRIA, 1995, 15 p. Relatório Técnico TR95-1534. Bibliografia 88 8 Bibliografia ACEAUME, E. et al. On The Formal Specification of Group Membership Services. INRIA, 1995, 15 p. Relatório Técnico TR95-1534. AMBRIOLA, V.; TORTORA, G. Advances in Software

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

9º Congresso de Pós-Graduação GERENCIAMENTO DE CONSULTAS EM DATA WAREHOUSE DISTRIBUÍDO EM NUVEM

9º Congresso de Pós-Graduação GERENCIAMENTO DE CONSULTAS EM DATA WAREHOUSE DISTRIBUÍDO EM NUVEM 9º Congresso de Pós-Graduação GERENCIAMENTO DE CONSULTAS EM DATA WAREHOUSE DISTRIBUÍDO EM NUVEM Autor(es) ORLANDO PEREIRA SANTANA JUNIOR Orientador(es) MARINA TERESA PIRES VIEIRA 1. Introdução A informaçã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

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

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

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

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

Redes de Computadores

Redes de Computadores Redes de Computadores Camada de Rede Roteamento IP RIP OSPF e BGP Slide 1 Roteamento Determinar o melhor caminho a ser tomado da origem até o destino. Se utiliza do endereço de destino para determinar

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

MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT. Fatores Tecnológicos, Estratégicos e Organizacionais

MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT. Fatores Tecnológicos, Estratégicos e Organizacionais MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT 15.565 Integração de Sistemas de Informação: Fatores Tecnológicos, Estratégicos e Organizacionais 15.578 Sistemas de Informação Global:

Leia mais

Backbones Ad Hoc. Aluno: Eduardo Hargreaves Orientador: Luís Felipe M. de Moraes Coppe/UFRJ - Programa de Engenharia de Sistemas e Computação

Backbones Ad Hoc. Aluno: Eduardo Hargreaves Orientador: Luís Felipe M. de Moraes Coppe/UFRJ - Programa de Engenharia de Sistemas e Computação Backbones Ad Hoc Aluno: Eduardo Hargreaves Orientador: Luís Felipe M. de Moraes Coppe/UFRJ - Programa de Engenharia de Sistemas e Computação Estrutura do Trabalho Motivações MBN TBONE Conclusões Motivações

Leia mais

Processamento Distribuído de Eventos Complexos (CEP)

Processamento Distribuído de Eventos Complexos (CEP) Processamento Distribuído de Eventos Complexos (CEP) Gustavo Baptista Departamento de Informática, PUC- Rio gbaptista@inf.puc- rio.br Resumo. Complex Event Processing (CEP) é uma tecnologia emergente para

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

Push Technologies. Caixa Postal 10.011 CEP 86057-970 Londrina PR Brasil. sean.alvarenga@gmail.com, brunozarpelao@uel.br

Push Technologies. Caixa Postal 10.011 CEP 86057-970 Londrina PR Brasil. sean.alvarenga@gmail.com, brunozarpelao@uel.br Push Technologies Sean Carlisto de Alvarenga 1, Bruno Bogaz Zarpelão 1 1 Departamento de Computação Universidade Estadual de Londrina (UEL) Caixa Postal 10.011 CEP 86057-970 Londrina PR Brasil sean.alvarenga@gmail.com,

Leia mais

Universidade Federal de Pernambuco. Refinamento do AnalyserPX para tráfego Multigigabit

Universidade Federal de Pernambuco. Refinamento do AnalyserPX para tráfego Multigigabit Universidade Federal de Pernambuco GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA 2 0 1 1. 1 Refinamento do AnalyserPX para tráfego Multigigabit Proposta de Trabalho de Graduação Aluno Wesley

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

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

Prototipação de um cache DNS Pró-Ativo usando Publish/Subscribe em Redes P2P

Prototipação de um cache DNS Pró-Ativo usando Publish/Subscribe em Redes P2P Anais 45 Prototipação de um cache DNS Pró-Ativo usando Publish/Subscribe em Redes P2P TiagoRigo Guasti 1, Rodolfoda Silva Villaça 1, HélcioBezerra de Mello 1 1 Departamento deengenhariasecomputação (DECOM)

Leia mais

Estrutura Message Brokers

Estrutura Message Brokers Estrutura Message Brokers Amadeu Dias amadeu@di.fc.ul.pt O que são Message Brokers O Porquê! Arquitectura Geral Aspectos a ter em conta Referências O que são Message Brokers Middleware MOM específico:

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

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

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

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

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

Seleção Baseada em Preço dos Melhores e Piores Provedores de Serviço em Rede de Sobreposição de Serviços Par-a-Par

Seleção Baseada em Preço dos Melhores e Piores Provedores de Serviço em Rede de Sobreposição de Serviços Par-a-Par Seleção Baseada em Preço dos Melhores e Piores Provedores de Serviço em Rede de Sobreposição de Serviços Par-a-Par Renato Balestrin Júnior 1, Adriano Fiorese 1 1 Departamento de Ciência da Computação (DCC)

Leia mais

Implementação de um Mecanismo de Indexação para Consultas Avançadas em DHT

Implementação de um Mecanismo de Indexação para Consultas Avançadas em DHT Implementação de um Mecanismo de Indexação para Consultas Avançadas em DHT Tarciana Dias da Silva, Ramide Dantas, Djamel Sadok Centro de Informática Universidade Federal de Pernambuco (UFPE) Caixa Postal

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

Uma Nova Classificação para Arquiteturas de Redes Peer-to-Peer

Uma Nova Classificação para Arquiteturas de Redes Peer-to-Peer 416 IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 6, DECEMBER 2006 Uma Nova Classificação para Arquiteturas de Redes Peer-to-Peer G. S. B. do Carmo, J. S. Barbar, Membro, IEEE e F. B. Coelho Resumo--As

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

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

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

Cada cliente, necessariamente, sempre deve estar conectado a um Broker, e somente um;

Cada cliente, necessariamente, sempre deve estar conectado a um Broker, e somente um; Universidade Federal do Espírito Santo Departamento de Informática Estruturas de Dados I (INF09292) 1o Trabalho Prático Período: 2015/2 Profa Patrícia Dockhorn Costa Email: pdcosta@inf.ufes.br Data de

Leia mais

REDES ESAF. leitejuniorbr@yahoo.com.br 1 Redes - ESAF

REDES ESAF. leitejuniorbr@yahoo.com.br 1 Redes - ESAF REDES ESAF 01 - (ESAF - Auditor-Fiscal da Previdência Social - AFPS - 2002) Um protocolo é um conjunto de regras e convenções precisamente definidas que possibilitam a comunicação através de uma rede.

Leia mais

ATIVIDADE 1. Definição de redes de computadores

ATIVIDADE 1. Definição de redes de computadores ATIVIDADE 1 Definição de redes de computadores As redes de computadores são criadas para permitir a troca de dados entre diversos dispositivos estações de trabalho, impressoras, redes externas etc. dentro

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

Protocolos de roteamento RIP e OSPF

Protocolos de roteamento RIP e OSPF Roberto Néia Amaral et al. 75 Roberto Néia Amaral (Mestre) Curso de Ciência da Computação - Universidade Tuiuti do Paraná Ciro de Barros Barbosa (Doutor) Curso de Ciência da Computação - Universidade Tuiuti

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

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

Troca de Mensagens Sistemas Fracamente Acoplados

Troca de Mensagens Sistemas Fracamente Acoplados Troca de Mensagens Sistemas Fracamente Acoplados Distribuição Geográfica distribuição também administrativa limites de tempo de comunicação desconhecidos conexão e desconexão frequentes número grande de

Leia mais

Otimizando Requisições de Conteúdo em Redes Par-a-Par Sobre Redes Ad Hoc

Otimizando Requisições de Conteúdo em Redes Par-a-Par Sobre Redes Ad Hoc Otimizando Requisições de Conteúdo em Redes Par-a-Par Sobre Redes Ad Hoc Diego Neves da Hora 1, Daniel Fernandes Macedo 2,1, José Marcos S. Nogueira 1, Guy Pujolle 2 {dnhora,damacedo,jmarcos}@dcc.ufmg.br,guy.pujolle@rp.lip6.fr

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

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

Avaliação de um Serviço para Gerenciamento de Entidades Físicas em Aplicações Ubíquas

Avaliação de um Serviço para Gerenciamento de Entidades Físicas em Aplicações Ubíquas Avaliação de um Serviço para Gerenciamento de Entidades Físicas em Aplicações Ubíquas Rodolfo Antunes 1, Cristiano Costa 2, Jorge Barbosa 2, Cláudio Geyer 1, Adenauer Yamin 3 1 UFRGS Universidade Federal

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

Ciência de Computadores Sistemas Distribuídos e Móveis

Ciência de Computadores Sistemas Distribuídos e Móveis Ciência de Computadores Sistemas Distribuídos e Móveis Lista de Exercícios Data: 4 de Novembro de 2013 Questões sobre o capítulo 1, Tanenbaum & van Steen: Fundamentos 1) Explique o significado de transparência,

Leia mais

Cap. 02 Arquiteturas de Sist. Distribuídos

Cap. 02 Arquiteturas de Sist. Distribuídos Cap. 02 Arquiteturas de Sist. Distribuídos 2.1 Estilos Arquiteturais 2.2 Arquiteturas de Sistemas Distribuídos 2.2.1 Arquiteturas Centralizadas 2.2.2 Arquiteturas Descentralizadas 2.2.3 Arquiteturas Híbridas

Leia mais

Capítulo VI Telecomunicações: Redes e Aplicativos

Capítulo VI Telecomunicações: Redes e Aplicativos Capítulo VI Telecomunicações: Redes e Aplicativos Uma rede nada mais é do que máquinas que se comunicam. Estas máquinas podem ser computadores, impressoras, telefones, aparelhos de fax, etc. Se interligarmos

Leia mais

Descoberta de Recursos em Grades Computacionais Utilizando Estruturas P2P

Descoberta de Recursos em Grades Computacionais Utilizando Estruturas P2P Descoberta de Recursos em Grades Computacionais Utilizando Estruturas P2P Vladimir Rocha, Marco A. S. Netto, Fabio Kon 1 Departamento de Ciência da Computação Instituto de Matemática e Estatística Universidade

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

Protocolos de gerenciamento

Protocolos de gerenciamento Protocolos de gerenciamento Os protocolos de gerenciamento têm a função de garantir a comunicação entre os recursos de redes homogêneas ou não. Com esse requisito satisfeito, operações de gerenciamento

Leia mais

Arquiteturas Orientadas a Serviços ESB. Enterprise Service Bus. Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos

Arquiteturas Orientadas a Serviços ESB. Enterprise Service Bus. Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos ESB Enterprise Service Bus Prof. Ricardo J. Rabelo DAS5316 Integração de Sistemas Corporativos Resumo Introdução Definição Problemas atuais e Vantagens Evolução do ESB ESB versus EAI, MOM, Workfow, SOA

Leia mais

Armazenamento distribuído de dados e checkpointing de aplicaçõesparalelasemgradesoportunistas

Armazenamento distribuído de dados e checkpointing de aplicaçõesparalelasemgradesoportunistas Armazenamento distribuído de dados e checkpointing de aplicaçõesparalelasemgradesoportunistas Autor:RaphaelY.deCamargo 1 Orientador:Prof.Dr.FabioKon 1 1 DepartamentodeCiênciadaComputação Instituto de Matemática

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

Desenvolvendo Aplicações de Rastreamento e Comunicação Móvel usando o Middleware SDDL

Desenvolvendo Aplicações de Rastreamento e Comunicação Móvel usando o Middleware SDDL 1084 31 o Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos SBRC 2013 Desenvolvendo Aplicações de Rastreamento e Comunicação Móvel usando o Middleware SDDL Igor Vasconcelos, Rafael Vasconcelos,

Leia mais

Middleware Orientado a Mensagens Visão Geral Comunicação Gerenciamento de Filas Padrões e Produtos 1 Middleware Orientado a Mensagens RPC/RMI é inadequado para comunicação em alguns cenários de aplicação

Leia mais

Extensão do WEKA para Métodos de Agrupamento com Restrição de Contigüidade

Extensão do WEKA para Métodos de Agrupamento com Restrição de Contigüidade Extensão do WEKA para Métodos de Agrupamento com Restrição de Contigüidade Carlos Eduardo R. de Mello, Geraldo Zimbrão da Silva, Jano M. de Souza Programa de Engenharia de Sistemas e Computação Universidade

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

Lightweight Super-Peers: Um modelo de Super-Peers para Redes DHT

Lightweight Super-Peers: Um modelo de Super-Peers para Redes DHT SBRC 2007 - Desempenho em Sistemas P2P 971 Lightweight Super-Peers: Um modelo de Super-Peers para Redes DHT Marcos Madruga, Thaís Batista, Rodrigo Araújo, Luiz Affonso Guedes Departamento de Informática

Leia mais

Banco de Dados Distribuídos

Banco de Dados Distribuídos A imagem não pode ser exibida. Talvez o computador não tenha memória suficiente para abrir a imagem ou talvez ela esteja corrompida. Reinicie o computador e abra o arquivo novamente. Se ainda assim aparecer

Leia mais

Diagrama de Estrutura Composta

Diagrama de Estrutura Composta Diagramas da UML Diagrama de Estrutura Composta Diagrama de Casos de Uso Indicação: Análise de Requisitos Permite descobrir os requisitos funcionais do sistema Fornece uma descrição clara e consistente

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

Pg. Autoria. Versão atual V10, nov 2008 C. Geyer. Sistemas de Arquivos Distribuídos: DFS. Projeto de. Sistemas de Arquivos Distribuídos (DFS) Súmula

Pg. Autoria. Versão atual V10, nov 2008 C. Geyer. Sistemas de Arquivos Distribuídos: DFS. Projeto de. Sistemas de Arquivos Distribuídos (DFS) Súmula Autoria 1 versão Alunos de disciplina do PPGC Sistemas de Arquivos Distribuídos: DFS Versão atual V10, nov 2008 C. Geyer Sistemas Distribuidos Sistema de Arquivos Distribuídos 1 Sistemas Distribuidos Sistema

Leia mais

AULA 03 REVISÃO DOS CONCEITOS TRABALHADOS ANTERIORMENTE. Os MMOs ou MMOGs (Massive Multiplayer Online Games Jogos Multijogador On-Line Massivos).

AULA 03 REVISÃO DOS CONCEITOS TRABALHADOS ANTERIORMENTE. Os MMOs ou MMOGs (Massive Multiplayer Online Games Jogos Multijogador On-Line Massivos). AULA 03 REVISÃO DOS CONCEITOS TRABALHADOS ANTERIORMENTE 1. MMOS E SUAS SUBCATEGORIAS Os MMOs ou MMOGs (Massive Multiplayer Online Games Jogos Multijogador On-Line Massivos). O termo massivo refere-se ao

Leia mais

Arquitecturas de Sistemas. Arquitecturas Descentralizadas de Sistemas

Arquitecturas de Sistemas. Arquitecturas Descentralizadas de Sistemas Arquitecturas de Sistemas Centralizadas Descentralizadas Híbridas Arquitecturas Descentralizadas de Sistemas Dividir aplicações cliente-servidor em três camadas (interface, processamento, dados): distribuição

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor

Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática /

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

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

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

Middleware Orientado a Mensagens (MOM)

Middleware Orientado a Mensagens (MOM) Middleware Orientado a Mensagens Visão Geral RPC/RMI é inadequado para comunicação em alguns cenários de aplicação Cliente e servidor precisam estar ativos durante a comunicação Implica em espera para

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