Tecnologias relacionadas a XML - PUC-Rioendler/courses/Mobile/Monogra… · Web viewPor...

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO

CENTRO TÉCNICO CIENTÍFICO

DEPARTAMENTO DE INFORMÁTICA

PROGRAMA DE MESTRADO

ES T R A T É G I A S P A R A CA C H I N G E M RE D E S MÓ V E I S

Disciplina: Introdução a Computação Móvel

Aluno: Ronaldo Luiz Conde PereiraProfessor: Markus Endler

Rio de Janeiro, Brasil, Janeiro de 2002

Conteúdo

1 . I n t r o d u ç ã o ............................................................................................2

2 . O B J E T I V O S D E C A C H E ..........................................................................5

3 . O B J E T I V O D O T R A B A L H O .................................................................1 6

4 . R E D E S M Ó V E I S P O R D I F U S Ã O D E M E N S A G E N S ......................1 7

4 . 1 E S T R A T É G I A S P A R A E N T R E G A D E M E N S A G E N S ................................1 8

4 . 2 C A C H I N G E D I F U S Ã O ..............................................................................1 8

4 . 3 G E R Ê N C I A D E C A C H E E M S I S T E M A S P O R D I F U S Ã O .........................1 9

4.3.1 POLÍT ICAS DE ATUALIZAÇÃO DE CACHE ................................................19

4.3.2 BUSCA ANTECIPADA ..............................................................................20

4 . 4 A T U A L I Z A Ç Ã O D E C A C H E E M S I S T E M A S D I F U S Ã O ...........................2 1

5 . R E D E S M Ó V E I S A D H O C ..................................................................2 4

5 . 1 O P E R A Ç Ã O D E R O T E A M E N T O ................................................................3 0

5 . 2 O T I M I Z A Ç Ã O C O M O U S O D E C A C H E ..................................................3 1

6 . C O N C L U S Ã O ...........................................................................................3 7

7 . R e f e r ê n c i a s B i b l i o g r á fi c a s .....................................................3 9

Estratégias para Caching em Redes Móveis Ronaldo Luiz Conde Pereira

Introdução 2

1. I N T R O D U Ç Ã O

O desenvolvimento nos últimos anos das telecomunicações e da informática, unido à necessidade do homem de estar cada vez mais informado esteja onde estiver, tem provocado que as redes sem fio sejam a próxima geração nas redes de computadores. As redes sem fio/móveis, surgem como a quarta revolução na computação, antecedida pelos centros de processamento de dados na década de sessenta, o surgimento dos terminais nos anos setenta e das redes de computadores na década de oitenta.

A evolução conjunta da comunicação sem fio e da tecnologia da informática busca atender muitas das necessidades do mercado: serviços de celulares, redes locais sem fio, transmissão de dados via satélite, TV, rádio modems, sistemas de navegação, base de dados geográfica, etc.

A combinação da comunicação sem fio com a mobilidade de computadores criou novos problemas nas áreas de informática e telecomunicações, em especial: redes de computadores, sistemas operacionais, otimização, sistemas de informação, banco de dados, dentre outras.

Embora as redes de computadores atuais, sejam elas locais ou a rede mundial, ofereçam acesso às fontes de informações, não conseguimos obter algum benefício desse acesso até que cheguemos em algum ponto familiar - seja em casa, no escritório, ou na escola. Entretanto, a variedade crescente dos dispositivos wireless que oferecem conectividade tal como Personal Digital Assistant (PDA’s), handhelds, e telefones celulares digitais, estão começando a mudar nossas percepções de redes de computadores. Para compreenderemos o contraste entre a realidade atual de conectividade e as possibilidades futuras, consideremos a transição para a mobilidade que ocorreu na telefonia nos últimos 20 anos. Uma transição análoga no domínio das redes, da dependência em pontos fixos

Introdução 3

de conexão à flexibilidade permitida pela mobilidade, apenas começou.

Computadores e redes móveis ou computação nômade não devem ser confundidos com computadores e redes portáteis que temos hoje. Em redes móveis, as atividades computacionais não podem ser interrompidas quando o usuário muda o ponto de conexão do computador móvel à rede. Ao invés disto, toda reconexão necessária ocorre automaticamente e sem interatividade. Computadores verdadeiramente móveis oferecem muitas vantagens. O acesso confiável a rede a qualquer momento, em qualquer lugar nos ajudará a livrarmo-nos dos laços que nos ligam a nossos atuais desktops. Considere como os telefones celulares deram as pessoas à liberdade nova em realizar seu trabalho. Fazer um exame completo em um ambiente computacional significa verificar se este tem o potencial não apenas de estender a flexibilidade para a nova tecnologia mas mudar fundamentalmente os procedimentos existentes hoje no trabalho. Ter a rede disponível quando nos movemos dar-nos-á as ferramentas necessárias aos ambientes computacionais em todo lugar que estivermos. Isto é especialmente conveniente em um ambiente wireless LAN do escritório, onde os limites entre pontos de conexão não sejam rígidos e frequentemente sejam invisíveis.

A evolução das redes móveis diferirá da telefonia em alguns aspectos importantes. Os endpoints de uma conexão telefônica são tipicamente seres humanos; as aplicações em computadores provavelmente envolvem interações entre máquinas sem intervenção humana. Exemplos óbvios disto são computadores móveis em aviões, navios e em automóveis. As redes móveis podem também vir a depender da posição geográfica em que se encontram os dispositivos móveis, tal como em sistemas de posicionamento global por satélite (GPS).

Uma outra diferença pode ser a taxa de adoção. Passaram-se muitos anos até que os telefones móveis tornaram-se baratos e leves o bastante para serem vistos como convenientes. Devido os dispositivos computacionais móveis wireless tais como PDA’s e pocket organizers já terem encontrado

Introdução 4

a aceitação de usuários, os computadores móveis podem tornar-se populares muito mais rapidamente.

A Fig.1 ilustra uma rede móvel clássica.

Fig.1 – Rede móvel clássica

Objetivos do Cache 5

2. O B J E T I V O S D E C A C H E

Podemos dizer que cache é um armazenamento local de mensagens de resposta. Uma definição solta do caching é o movimento do conteúdo da rede para mais perto dos usuários, movimentação esta que pode ter sido originada pelo protocolo de comunicação, por aplicações ou pelo Sistema Operacional. Assim, podemos colocar em cache informações coletadas por diferentes ferramentas.

As primeiras experiências e medidas de caching demonstraram o potencial de uma redução significativa no número de bytes transferidos e, por vias de conseqüências, o aumento do throughput da rede. Por necessidades inerentes e para controle próprio os caches começaram a armazenar uma série de informações associadas aos objetos de tráfego, como tipo de conteúdo, tamanho e tempo médio entre modificações destes objetos. Desta forma aspectos como coerência do cache e da remessa de respostas em cache para hosts móveis tornaram-se extremamente importantes.

Os objetivos do caching são reduzir

a latência experimentada pelo usuário móvel entre o momento do pedido inicial à rede e o momento em que a resposta é exibida pelo agente do usuário;

a carga sobre a rede, que pode ser uma rede local ou remota, evitando a transmissão repetida da mesma resposta, utilizando-se de hosts intermediários;

a carga no servidor de origem, tendo um intermediário no caminho entre o host móvel e o servidor para tratar dos pedidos.

O primeiro deles normalmente é o objetivo mais citado do caching. A redução da latência percebida pelo usuário móvel possui implicações


importantes não apenas para a experiência do usuário na rede, mas também para desenvolvedores de conteúdo. Os estudos mostraram que, quando o usuário recebe mensagens rapidamente de um servidor, ele costuma gastar mais tempo neste servidor. Muito usuário ainda possui conexões com largura de banda relativamente pequena com a rede. A obtenção da informação desejada rapidamente aumenta a expectativa do usuário para obter mais informações do mesmo servidor rapidamente.

O segundo objetivo afeta principalmente a rede, mas possui um efeito colateral interessante. A transferência apenas das informações necessárias (ou seja, evitando a retransmissão de conteúdo que o usuário poderia ter obtido mais perto do local do host móvel) reduz o congestionamento geral na rede. A redução do congestionamento ocasiona um desempenho melhor para todos os que usam a rede, pois menos pacotes são perdidos e existe menos necessidade de retransmissão, resultante da perda de pacotes.

O terceiro objetivo significa que um servidor de origem pode lidar com mais pedidos de um conjunto diversificado de hosts móveis. O maior número de pedidos tratados é refletido não apenas na camada de aplicação, mas também na camada de transporte.

Todos os participantes na troca de mensagens da rede podem se beneficiar com o caching. Os usuários finais lucram bastante com o caching, pois sua latência na obtenção de uma resposta é reduzida, melhorando sua experiência na utilização da rede. Uma fração significativa dos cancelamentos que ocorrem durante uma sessão do usuário móvel normalmente é o resultado de uma frustração do usuário em não obter respostas rapidamente. A largura de banda desperdiçada como resultado de dados redundantes transmitidos na rede de forma repetida é muito grande. Como o congestionamento é visto em vários pontos na rede, a redução do tráfego torna-se benéfica. Os benefícios para a rede são dois: somente os dados necessários atravessam a rede, e existe largura de banda disponível para outros dados. A distância do cache


ao usuário móvel também é um fato significativo na medição do benefício de um cache para o usuário. Um cache muito próximo do usuário poderia reduzir significativamente a latência percebida pelo usuário, em comparação com um cache mais perto do servidor de origem.

Examinamos os diversos componentes do atraso na busca de um recurso e seu impacto sobre o usuário, a rede e o servidor de origem. Um recurso em cache no usuário móvel ou em um proxy (intermediário) perto deste usuário reduz o atraso para trazer a resposta a este usuário. A noção de trazer o conteúdo para mais perto do usuário é uma tentativa de reduzir vários dos componentes do atraso na obtenção de uma resposta. Do ponto de vista de um usuário, os componentes do atraso na busca de um recurso são afetados pelos seguintes fatores:

A conectividade de rede do usuário móvel ao seu servidor de comunicação (consideraremos como servidor de comunicação ou estação rádio base o host wired ao qual o host móvel está conectado) e a conexão entre este e o resto da rede.

O congestionamento na rede e a largura de banda disponível no percurso entre o usuário e o servidor de origem.

A carga sobre o servidor de origem.

O tempo para a geração da resposta.

O tempo para a apresentação da resposta.

Esses fatores de atraso traçam o percurso de um pedido enviado de um host móvel para o servidor de origem, até que a resposta seja apresentada de volta ao host móvel. A seguir, examinamos o impacto do caching sobre cada um desses fatores de atraso.

Conectividade da rede - A conectividade entre um host móvel e o seu servidor de comunicação está sujeita a mais variabilidades do que os atrasos deste com o resto da rede, considerando-se que este está


conectado com o resto da rede de forma wired. Se o conteúdo é trazido para mais perto do servidor de comunicação, pode haver algum grau de previsibilidade na latência experimentada pelo usuário. Se a velocidade de conexão entre o servidor de comunicação do usuário e o resto da rede for alta, as respostas são trazidas rapidamente para a extremidade da rede. No entanto, se a conectividade com o resto da rede for lenta, a mudança da resposta para a extremidade da rede, pode dominar a latência geral experimentada pelo usuário. Como um impacto secundário, se a conexão entre o servidor de comunicação do usuário e o servidor de origem cair no momento do pedido, um cache no servidor de comunicação pode ser capaz de satisfazer o pedido. A resposta pode estar desatualizada, mas, dependendo da resposta, isso pode não ser um fator sério. Isso deve ser temperado pelo fato de que muitas das respostas podem ser personalizadas e, assim, não estar disponíveis no cache do servidor de comunicação.

Questões de congestionamento de rede e largura de banda - A redução do número de hops pode melhorar o throughput geral entre o host móvel e o servidor onde se localiza as informações. Se o TCP for o mecanismo de transporte de suporte para a rede, então as reduções no tempo de ida e volta (RTT) melhoram o throughput. O throughput do TCP é inversamente proporcional ao RTT. Menos hops também podem reduzir a probabilidade de que a transferência esteja sujeita aos caprichos do atraso no congestionamento de ponta a ponta. Como já vimos anteriormente, mais pacotes na rede podem causar o congestionamento e levar a perdas de pacote. Os pacotes perdidos precisam ser retransmitidos. Se houver uma diminuição na utilização da rede como resultado do caching, o restante dos dados na rede pode ser transmitido mais rapidamente. O emissor do TCP pode aumentar o tamanho da janela de congestionamento para usar a rede em sua capacidade plena.

Carga no servidor de origem - O servidor de origem também pode se beneficiar com o caching. A carga sobre o servidor de origem pode ser reduzida se o caching de recursos solicitados com freqüência resultar em


menos pedidos para o servidor de origem. O servidor de origem é capaz de lidar com os pedidos de mais usuários individuais sem ter que enfileirar as conexões em nível de transporte (por exemplo, a fila accept do TCP) ou atrasar o processamento dos pedidos da rede. O servidor de origem migra a tarefa de atender aos pedidos para outros servidores auxiliadores vizinhos - os proxies com caching. O servidor de origem também pode manter conexões persistentes com menos clientes de entrada, e essas conexões podem permanecer abertas por mais tempo. O tempo para se gerar respostas redundantes é eliminado, deixando mais tempo para o servidor realizar outras tarefas.

Tempo para gerar a resposta - O tempo para se gerar a resposta aos pedidos pode ser reduzido, dependendo do arquivo do servidor da rede. Se menos recursos do servidor (ou seja, ciclos de CPU) forem gastos tratando dos pedidos recebidos, mais recursos poderiam ser dedicados à geração da resposta. Se a geração da resposta fosse uma fração significativa da latência geral experimentada pelos usuários e o caching a evitasse completamente, esse componente do atraso poderia ser o mais significativo. Além disso, se a arquivo do servidor da rede serializasse o tratamento dos pedidos, a geração de uma resposta longa afetaria negativamente o tratamento dos outros pedidos na mesma conexão.

Apresentação da resposta - Um agente cliente precisa analisar a resposta. O tempo para se apresentar o recurso pelo agente cliente não pode ser realmente reduzido pelo caching, a menos que a versão inteira do pedido esteja na memória volátil do agente cliente.

Fora às questões de atraso, o caching possui ramificações financeIras. O caching reduz a carga dentro de um backbone do servidor de comunicação. Pode ser mais barato comprar caches do que aumentar a capacidade dentro de um backbone. A largura de banda que foi liberada como resultado do caching pode permitir que um servidor de comunicação aceite clientes adicionais dentro da infra-estrutura existente.


Um cache pode decidir se uma resposta pode ir para o cache com base em dois fatores: requisitos relacionados ao protocolo de comunicação e o conteúdo em consideração. As considerações de caching específicas do protocolo exigem que um cache obedeça a várias diretivas com relação à possibilidade de cache de uma mensagem. Os requisitos específicos do conteúdo tratam de questões que são desligadas das questões de protocolo. Estes requisitos são afetados pelos requisitos comerciais de um cache e pelas diretrizes que afetam a freqüência da revalidação do cache - verificando se uma resposta em cache ainda está atualizada. As diretrizes, por sua vez, podem ser afetadas pelos atributos da mensagem, como tamanho ou tipo de conteúdo.

Um cache da rede bem-comportado precisa suportar as restrições impostas pelo protocolo de comunicação. Os padrões destes protocolos definem regras simples para as respostas que podem ir para o cache; o método do pedido, os campos de cabeçalho do pedido, o status da resposta e os cabeçalhos da resposta precisam indicar que a resposta pode ir para o cache. Uma restrição da parte de qualquer um deles impede o caching da resposta.

Algumas respostas incluem informações específicas do recurso a partir do servidor de origem, o que pode impedir o caching da mensagem. Tais informações são de dois tipos: informação de permissão de cache e diretivas de cache. Se a resposta incluir informações de permissão de cache, a decisão de uso do cache deve ser controlada por isso.

Os objetivos em conflito das várias partes envolvidas no caching eram conhecidos dos desenvolvedores de protocolos. Os padrões dos protocolos podem não servir como uma solução ideal para todas as partes envolvidas nas transações. No entanto, os projetistas dos protocolos focalizam o aumento da transparência semântica no caching enquanto oferecem controle a todas as partes envolvidas nas transações.

Um cache pode ter seu próprio conjunto de regras para decidir sobre a permissão de cache de uma resposta, separado das restrições do


protocolo. Em outras palavras, só porque uma resposta pode ser colocada em cache não significa que ela estará no cache. As mensagens podem ser grandes, geradas dinamicamente, tudo isso afetando a possibilidade do caching de uma mensagem. A diretriz de cache pode ser controlada por fatores que não sejam restrições do protocolo, como os atributos de uma mensagem. Por exemplo, a freqüência com que os caches revalidam os recursos com o servidor de origem pode ser ditada por suas diretrizes sobre a duração da permissão de cache dos recursos. No outro extremo, se um provedor de cache for contabilizado com base no número de bits que ele oferece aos usuários, ele pode optar por ignorar as marcas de hora da última modificação e enviar as respostas completas em vez de simplesmente enviar 304 Not Modified. Um cache compartilhado pode não querer colocar em cache as respostas às consultas contendo informações personalizadas.

Os caches podem levar em consideração o overhead do armazenamento e não colocar grandes recursos em cache, embora tenham permissão para o caching. Se uma mensagem for muito grande, muitos objetos podem ter que ser retirados do cache. Em termos de latência, o custo para se apanhar recursos menores dos respectivos servidores de origem pode ser maior do que o custo de obtê-los por um cache. Assim, um cache poderia decidir não manter objeto maior. Por outro lado, uma resposta maior em cache, se solicitada algumas vezes de clientes por trás do cache, pode gerar economias significativas em termos de largura de banda. Por exemplo, suponha que uma nova versão de um software esteja disponível na rede. Esse recurso é grande e provavelmente será solicitado com muita freqüência. O caching desse recurso geraria benefícios significativos. Parte do motivo é que alguns provedores de serviço precisam contabilizar com base no número total de bits que eles baixam e prefeririam, em vez disso, usar um cache e baixar o recurso apenas uma vez.

Muitos caches abrem mão do caching de todas as respostas de scripts, supondo que os parâmetros das consultas provavelmente não serão usados novamente. Até mesmo decidir se uma resposta foi gerada como


resultado da chamada de um script é baseado em uma heurística. A suposição básica no caching é de que a mesma resposta provavelmente será gerada no futuro, e o pedido por tal resposta pode ocorrer no futuro próximo. Um script poderia disparar um cálculo que provavelmente retorna um resultado diferente a cada vez, em comparação com um pedido de um recurso estático, que muda com muito pouca freqüência. No entanto, a presença da informação de permissão de cache em uma resposta dinâmica, pode indicar que o recurso realmente pode ser mantido em cache. Muitas consultas costumam resultar na mesma resposta, e alguns caches já levam isso em consideração. Isso é verdade principalmente no contexto dos utilitários de pesquisa, onde um grande número de consultas são para termos de pesquisa isolados e normalmente para o mesmo termo. Além disso, em geral, nem sempre é possível saber se a resposta retomada foi gerada dinamicamente ou não.

O mito de que as respostas para consultas a dados gerados dinamicamente não devem ser colocadas em cache parece estar desaparecendo. Outra categoria de resposta que pode ser vista como não-candidata ao caching são as respostas que incluem dados moldados a um usuário específico. Por exemplo, as respostas com informações de cookie não são consideradas como candidatas ao caching pelos proxies, pois se espera que sejam diferentes a cada usuário. Mas várias mensagens com cookies ainda podem ser candidatas ao caching se retomarem a mesma resposta para diferentes valores de cookie [1]. Observe que alguns tipos de conteúdo que normalmente são considerados candidatos ao caching (por exemplo, imagens - formatos GIF ou JPEG) podem realmente incluir dados personalizados ou não ter informações de atualização, fazendo com que não passem pelo cache.

A decisão de usar o cache é afetada pela taxa de mudança dos recursos. Vários recursos mudam com pouca freqüência ou nunca mudam. Alguns exemplos de recursos que podem nunca mudar são cópias eletrônicas de livros. Alguns recursos estáticos podem mudar por um período de tempo. As home pages dos usuários mudam periodicamente sem qualquer


freqüência específica. Assim, o exame da taxa de mudança de um recurso é uma medição válida para se decidir à permissão para o caching. Uma antiga heurística para se decidir sobre a permissão para o caching de um recurso era a hora da última modificação de um recurso. A suposição era de que, se um recurso não tinha sido modificado por um longo tempo, também era menos provável que mudasse no futuro próximo. Isso tornava o recurso um melhor candidato ao caching. Se um recurso fosse realmente mantido em cache, a hora da última modificação também era usada na decisão de quando revalidar a resposta em cache. Por outro lado, essa técnica também assumia que, se um recurso tivesse sido modificado recentemente, haveria uma probabilidade maior de que ele mudaria novamente em breve. Assim, um recurso provavelmente não permanecerá no cache por muito tempo. Ao mesmo tempo, a natureza constantemente mutável de um recurso poderia indicar um alto interesse no recurso e, assim, uma taxa de acesso mais alta, o que favorece o caching do recurso. Como o benefício geral do caching vem principalmente do número de vezes que um recurso em cache é realmente acessado, a taxa de acesso de um recurso deve ser considerada nas decisões sobre o caching.

A carga sobre um cache também pode ter um impacto na decisão sobre o caching de uma resposta. Por exemplo, um cache muito ocupado poderia atender aos acertos do cache, mas simplesmente encaminhar as faltas de cache e não armazenar as respostas para essas faltas.

Os caches são encontrados em agentes clientes e em qualquer um ou até mesmo em todos os intermediários da rede entre o agente do usuário e o servidor de origem. Normalmente, um cache está localizado em um proxy, além de um browser. Faz sentido usar o cache em vários locais, e não apenas em um único local:

Um cache do browser pode evitar ter que apanhar novamente páginas que o usuário examinou durante a mesma sessão. No entanto, um cache do browser não aproveita os recursos solicitados freqüentemente por outros usuários no mesmo ambiente local.


Um proxy com caching pode ajudar a dezenas ou centenas de usuários. Um cache do browser, no entanto, pode armazenar um conjunto razoável de respostas recebidas recentemente por um tempo maior do que um proxy com caching. Um proxy com caching, sendo um recurso compartilhado por centenas de usuários, pode ter que remover algumas respostas mais cedo do que um cache do browser.

Um cache de campus pode ajudar vários caches com localização geográfica dispersa dentro deste campus.

Perto, em uma ou mais entidades administrativas. Um cache regional pode agrupar um conjunto de caches de entidades administrativas e ajudar a reduzir os custos em regiões que possuem altas taxas de movimentação de dados. A cada passo geográfico fora do cliente, existe uma penalidade adicional no desempenho, mesmo quando existe um acerto no cache.

Exemplos: Como exemplo de utilização de alguma das estratégias de cache podemos citar sobre o tema Modelos de Computação Móvel, no modelo client/agent/server, utilizando-se caching no agente podemos minimizar os longos percursos na rede e assim reduzir o tempo de resposta da aplicação. Ainda sobre o mesmo tema, no modelo client/intercept/server, um cache local pode ser utilizado no client-side do agente para satisfazer as necessidades de dados do cliente durante as desconexões. Falhas de cache devem ser enfileiradas neste client-side para serem satisfeitas no momento da reconexão.

Objetivo do Trabalho 15

3. O B J E T I V O D O T R A B A L H O

Apesar do número de objetos que podemos armazenar em cache assim como da diversidade de opções para a localização deste cache, o objetivo fundamental deste trabalho é expor as estratégias de cache utilizadas em duas tecnologias de redes móveis específicas, quais sejam, Redes Móveis por Difusão de Mensagens e Redes Móveis Ad Hoc, no que diz respeito aos algoritmos de difusão e roteamento, respectivamente, para as mesmas.

Redes Móveis por Difusão de Mensagens 16

4. R E D E S M Ó V E I S P O R D I F U S Ã O D E M E N S A G E N S

Em sistemas cliente/servidor tradicionais, dados são enviados sob demanda através de requisições pedidas ao servidor pelo cliente. Assim, a transferência de informações é feita pelo provedor das informações para o usuário a partir de uma requisição deste usuário. Esta forma de entrega de dados é chamada de pull-based [2].

Outra forma de fazer a transferência dos dados entre um usuário e o provedor das informações é a partir do provedor. O objetivo desse serviço é permitir que uma pessoa receba informações relacionadas com assuntos pré-determinados, continuamente. Para isso, o computador do usuário deve estar “sintonizado” com o equipamento servidor de informações, através de uma aplicação cliente para receber informações sempre atualizadas.

Num ambiente de computação móvel, as estações de suporte à mobilidade, que ficam na rede fixa, podem ser usadas para fazer transmissão de dados na modalidade difusão (broadcast) para os clientes móveis. Esta modalidade provê o mecanismo necessário para uma nova forma de entrega de dados chamada de push-based. Nesta modalidade o servidor transmite dados repetidamente para os clientes móveis de sua célula sem que haja requisições específicas. Os clientes, por sua vez, monitoram a difusão de mensagens e aceitam somente os dados que devem ser processados pelo computador móvel.

4 . 1 E S T R A T É G I A S P A R A E N T R E G A D E M E N S A G E N S

A entrega de dados na modalidade pushbased é mais adequada em casos onde a informação deve ser transmitida para um grande número de


clientes móveis e haja interseção de interesses. Desta forma, o servidor na rede fixa não fica sobrecarregado com pedidos de requisições e não envia várias mensagens individuais que teriam que ser transmitidas em sistemas pullbased. Outra característica importante da entrega de mensagens pushbased é a sua escalabilidade já que o desempenho não depende do número de clientes recebendo mensagens.

Uma das limitações desta modalidade é que os clientes recebem as informações sequencialmente. Isto significa que um cliente deve monitorar o canal de comunicação até que apareça o dado desejado. Isto aumenta a latência de acesso à informação que é proporcional ao tamanho do banco de dados ou da quantidade de informações a serem transmitidas num “lote”.

4 . 2 C A C H I N G E D I F U S Ã O

Em sistemas baseados em disseminação, as técnicas de caching e difusão (broadcasting) podem ser usadas conjuntamente. Os clientes podem manter numa memória cache dados mais prováveis de serem usados, diminuindo assim a dependência com o servidor que transmite informações de acordo com uma prioridade. É importante ressaltar que o servidor tenta otimizar a difusão de dados para um conjunto de clientes com necessidades diferentes. Essas necessidades podem ainda variar ao longo do tempo. Logo, para um cliente específico a difusão de dados pode não ser ótima e a técnica de caching pode melhorar o desempenho de acesso às informações. A técnica de difusão pode ser usada também para atualizar a memória cache em qualquer sistema cliente/servidor independentemente da modalidade de transmissão de dados, ou seja, difusão, entrega sob demanda ou uma combinação das duas modalidades.


4 . 3 G E R Ê N C I A D E C A C H E E M S I S T E M A S P O R D I F U S Ã O

Protocolos de gerência de cache propostos para sistemas tradicionais são baseados no princípio de entrega de dados sob demanda. Essas técnicas devem ser revistas para sistemas baseados em difusão para computação móvel.

4 . 3 . 1 P O L Í T I C A S D E A T U A L I Z A Ç Ã O D E C A C H E

Em sistemas de gerência de memória cache, os clientes mantêm na memória os dados que têm mais probabilidade de serem acessados para melhorar a taxa de acerto de cache (cache hit ratio). Geralmente nesses sistemas, quando ocorre a substituição de uma página devido a uma ausência de dado na memória cache, o custo para obter a nova página é considerado constante e não é computado no processo de atualização. Em sistemas difusão, o custo para substituir uma página depende do intervalo de tempo que se deve esperar para obter o novo dado. Logo, devese considerar esse custo em políticas de atualização de páginas.

Em sistemas de disseminação que usam discos difusão, cada cliente deve manter as páginas que têm maior probabilidade de acesso comparado com suas frequências de difusão. Um método simples de substituição de páginas proposto por Acharya et al. [3] é o PIX (P Inverse X) que considera este princípio. O método PIX substitui a página residente na memória cache que tem a menor razão entre a probabilidade de acesso P e a frequência de difusão X. O problema deste método é que requer um conhecimento das probabilidades de acesso, o que geralmente é difícil de obter, e as frequências de difusão de todos os dados armazenados na memória cache. Além disso, para cada substituição é necessário comparar todos os valores obtidos de PIX.


4 . 3 . 2 B U S C A A N T E C I P A D A

Um cliente pode armazenar antecipadamente na sua memória cache páginas que ainda serão acessadas. Em sistemas distribuídos tradicionais, a busca antecipada (prefetching) de páginas, que potencialmente serão usadas pelo cliente, causa um aumento na carga do servidor e na subrede de comunicação. Em sistemas baseados em disseminação o impacto é somente nos recursos locais do cliente já que os itens a serem buscados antecipadamente estão presentes na difusão.

Uma estratégia simples de busca antecipada é o tagteam [4]. Suponhamos que um cliente está interessado em acessar os dados d1 e d2 com a mesma probabilidade e só possui uma página disponível para armazená-los. d1 é copiado para a memória cache ao aparecer numa difusão e fica armazenado até d2 ser transmitido quando d1 é substituído pelo valor de d2.

Estes princípios são usados para propor uma heurística de busca antecipada chamada de PT. Esse é um método dinâmico que calcula o valor PT de cada dado recebido na difusão com os itens que estão armazenados naquele momento na memória cache. O valor de PT é dado pelo produto da probabilidade P de acesso à página e o período de tempo T para a página aparecer novamente numa difusão. O método compara o item com o menor valor de PT na memória cache com o valor de PT do dado recebido. Se este último for maior, então há uma substituição. Note que uma implementação eficiente deste método pode ser feita usando uma fila de prioridades que evita consultar o valor de PT de cada dado na memória. Observe também que o valor de PT é dinâmico já que o valor de T varia. Por outro lado, o valor de PIX usado na política de atualização de cache permanece estático durante o período de difusão.

Uma outra abordagem de busca antecipada de dados é apresentada por [5] para sistemas de entrega de teletexto na modalidade difusão. Nessa abordagem, cada página transmitida contém uma lista das páginas mais prováveis de serem requisitadas pelo cliente. Ao requisitar uma página p o


cliente também recebe os primeiros d itens da lista que estão associados com p, onde d é o tamanho da memória cache em páginas.

4 . 4 A T U A L I Z A Ç Ã O D E C A C H E E M S I S T E M A S D I F U S Ã O

Nestes sistemas, o servidor pode usar o esquema de difusão para informar os clientes sobre atualizações de dados em suas memórias cache. Em [6] estuda-se o problema de atualização da memória cache por um servidor de forma assíncrona e síncrona. Na forma assíncrona, o servidor transmite uma notificação de invalidação para um dado tão logo o seu valor seja alterado. Na forma síncrona, as notificações são transmitidas periodicamente. Isto significa que o cliente tem que receber a notificação para decidir se os dados na memória cache são válidos ou não.

A informação enviada numa notificação de invalidação pode variar. Por exemplo, pode conter o valor do item atualizado ou apenas a identificação e timestamp da última atualização sem o seu valor, principalmente no caso de dados armazenados em apenas alguns clientes. No caso do valor não ser incluído na notificação, o cliente deve remover o item da memória cache.

Em [6] temos três estratégias de atualização da memória cache de forma síncrona. Na estratégia de difusão de timestamp (TS), a notificação contém o timestamp de cada dado atualizado nos últimos w segundos. Na estratégia de amnestic terminals (AT) o servidor transmite somente os identificadores dos itens que mudaram desde a última notificação. Na estratégia de signature, o servidor envia uma assinatura que é um checksum calculado sobre os valores de vários itens através de técnicas de compressão de dados. Como era de se esperar, a aplicabilidade de cada uma dessas estratégias depende do tempo que um cliente permanece no modo doze. Clientes que normalmente ficam conectados são chamados de “viciados em trabalho” (workaholic) enquanto que clientes que ficam normalmente desconectados são chamados de


“dorminhocos” (sleepers). A estratégia de assinatura é mais apropriada para clientes sleepers que ficam longos períodos desconectados. A estratégia AT é melhor para um workaholic e a TS é mais vantajosa quando o número de consultas é maior que a taxa de atualizações e os clientes não são workaholics.

Em [7] verifica-se um método de atualização de forma assíncrona baseado em sequências de bits. Nesse método, a notificação é organizada como um conjunto de pares onde o primeiro elemento é um bit e o segundo é o timestamp. Cada bit na sequência representa um item no banco de dados. Um bit 1 indica que o item correspondente foi atualizado no instante dado pelo timestamp e o bit 0 indica que o dado não foi alterado. Neste método é mostrado que o algoritmo tem um desempenho consistente quando a taxa de atualização e os tempos de desconexão dos clientes variam. O algoritmo pode ser empregado para grandes bancos de dados alterandose a granularidade do bit. A idéia é associar um bit a um conjunto de dados alterados raramente ao invés de um único item.

Um problema importante é como atualizar os dados numa memória cache quando o cliente desconectado perde uma notificação. Neste caso, os métodos síncronos são melhores que os assíncronos já que os clientes precisam apenas se sintonizar periodicamente para receber uma notificação ao invés de escutar continuamente o canal. Se o cliente permanecer desconectado por um período maior que o de difusão todos os dados armazenados na memória cache podem ter que ser descartados a menos que alguma verificação seja feita. Uma alternativa é agrupar os dados e enviar para o servidor uma identificação do grupo junto com o timestamp. O problema é que uma única atualização invalida todo o grupo. Como solução, temos em [8] uma proposta de eliminar do conjunto os itens que estão atualizados no momento de validar o grupo.

Redes Móveis Ad Hoc 22

5. R E D E S M Ó V E I S A D H O C

Hosts móveis e hardware para redes wireless estão se tornando largamente disponíveis e um trabalho extensivo tem sido feito recentemente para integrar estes elementos em redes tradicionais tais como a Internet. Frequentemente, entretanto, os usuários móveis poderão querer se comunicar em situações que nenhuma infra-estrutura fixa estará disponível, seja por não ser economicamente prático ou fisicamente possível fornecer a infra-estrutura necessária ou porque a conveniência da situação não permite sua instalação. Em tais situações, uma coleção de hosts móveis com interfaces wireless de rede, pode dar forma a uma rede provisória sem a necessidade de toda uma infra-estrutura fixa tradicional ou uma administração centralizada. Este tipo de rede wireless é conhecido como uma rede wireless ad hoc [9], como podemos ver ilustrada na Fig.2.

Fig.2 - Comparação entre duas topologias de rede móvel (BSA – Basic Set Area ou área de cobertura)

Em tal ambiente, faz-se necessário que um host móvel solicite ajuda de outros hosts no envio de um pacote a seu destino, devido à escala limitada de transmissões wireless de cada host móvel.

No caso da existência de somente dois hosts, localizados próximos um do outro, estarem envolvidos na rede ad hoc, nenhum protocolo de

a) Rede estruturada

Sistema de

Distribuição

BSA 2

BSA 1

pontos de acesso (PA)

b) Rede ad hoc


roteamento ou decisão de rota é necessário. Em muitas redes ad hoc, apesar de que dois hosts que querem se comunicar não estarem dentro de seus limites de transmissão wireless, poderiam fazê-lo se outro(s) host(s) entre eles participar(em) da rede e estiver(em) disposto(s) a enviar pacotes para eles. Por exemplo, na rede ilustrada na Fig.4, o host móvel C não está dentro do limite de transmissão wireless do host A (indicado pelo círculo em torno de A) e o host A não está dentro do limite de transmissão wireless do host C. Se A e C desejarem trocar pacotes, pode ser que, neste caso, solicitem os serviços do host B para enviar pacotes para eles, desde que B esteja dentro da sobreposição entre o limite de A e o limite de C. Certamente, o problema de roteamento em uma rede ad hoc real pode ser mais complicado do que este exemplo sugere, devido às características não uniformes inerentes da propagação de comunicações wireless e devido à possibilidade que alguns ou todos os host envolvidos poderem se movimentar em qualquer momento.

Os protocolos de roteamento em redes wireless convencionais geralmente usam ou o algoritmo do vetor de distância ou o algoritmo de roteamento link state, sendo que ambos necessitam de alertas a serem enviados periodicamente via broadcast por cada roteador. Além de seu uso em redes wired, o algoritmo básico do vetor de distância foi adaptado também para este protocolo de referência de redes wireless ad hoc, essencialmente tratando cada host móvel como um roteador [10, 11, 12].

Este capítulo descreve a otimização ou seja, a estratégia de memória cache utilizada, de um protocolo de roteamento usado como referência para redes ad hoc que usa preferivelmente o roteamento dinâmico na fonte dos pacotes entre os hosts que querem se comunicar. O roteamento na fonte é uma técnica de roteamento em que o remetente de um pacote determina a seqüência completa dos nós através dos quais os pacotes devem ser enviados; o remetente informa explicitamente esta rota no cabeçalho do pacote, identificando cada hop pelo endereço do próximo nó, que irá desta forma transmitir o pacote ao host destino. O protocolo


aqui apresentado como referência, foi projetado explicitamente para o uso no ambiente wireless de uma rede ad hoc. Não há nenhum alerta periódico no roteamento do protocolo. Ao contrário, quando um host necessita uma rota para um outro host, ele determina dinamicamente uma baseado na informação cached e nos resultados de um protocolo route discovery, como podemos ver ilustrado na Fig.3.

Fig.3 – Protocolo route discovery

Acreditamos que este protocolo de roteamento dinâmico na fonte oferece um número de vantagens potenciais sobre protocolos de roteamento convencionais tais como o vetor de distância para redes ad hoc. Primeiramente, ao contrário dos protocolos de roteamento convencional, este protocolo não roteia nenhuma mensagem periódica de alerta, reduzindo desse modo os custos gerais na largura de banda da rede, particularmente durante os períodos em que quase nenhum movimento significativo de hosts está ocorrendo. A carga da bateria também é conservada no host móvel, não emitindo alertas tampouco necessitando recebe-los (desde que o host possa reduzir seu uso de energia colocando-se no estado sleep ou standby quando não estiver ocupado com outra tarefa). Por outro lado, o roteamento por vetor de distancia ou por link


state precisam continuar enviando alertas mesmo quando nenhuma mudança ocorreu, de modo que outros hosts móveis continuem a considerar aquelas rotas ou links de rede como sendo válidas. Além disso, muitos dos links entre os roteadores vistos pelo algoritmo de roteamento podem ser redundantes [10]. As redes wired geralmente são configuradas explicitamente para ter somente um (ou um número pequeno) de roteadores conectando duas redes quaisquer. Diferentemente, não temos nenhum link explícito em uma rede ad hoc e toda a comunicação é realizada por transmissão de broadcast. Os caminhos redundantes em um ambiente wireless aumentam desnecessariamente o tamanho dos routing updates que devem ser emitidos sobre a rede, e aumenta o overhead da CPU necessário para processar cada update e acrescentar as novas rotas.

F I G . 4 - U M A R E D E A D H O C S I M P L E S C O M T R Ê S H O S T S M Ó V E I S

Além disso, protocolos de roteamento convencionais baseados no link state ou nos algoritmos do vetor de distância podem acrescentar algumas rotas que não serão utilizadas. Em um ambiente wireless, a transmissão da rede entre dois hosts não trabalha necessariamente igualmente bem em ambos os sentidos, devido à diferença na propagação ou aos padrões de interferência diferindo em torno dos dois hosts [13, 14]. Por o exemplo, com o roteamento do vetor de distância, mesmo que um host possa receber um alerta de roteamento de um outro host móvel, os pacotes que

A B C


ele deveria transmitir de volta para este mesmo host para reencaminhamento, podem não ser capazes de alcançá-lo. O protocolo hora tomado como referência não requer transmissões entre hosts para trabalhar bidirecionalmente.

Finalmente, os protocolos convencionais de roteamento não são projetados para o tipo dinâmico de mudanças da topologia que podem estar presente em redes ad hoc. Em redes convencionais, as ligações entre roteadores ocasionalmente são perdidas ou restabelecidas e em algumas vezes o custo de um enlace pode mudar devido ao congestionamento, mas os roteadores não se movimentam dinamicamente. Em um ambiente com hosts móveis operando como roteadores, mudar para novas e estáveis rotas, depois que tais mudanças dinâmicas na topologia da rede ocorreram, podem ser lentas, particularmente com algoritmos do vetor da distância [15]. Esse protocolo dinâmico de roteamento na fonte pode adaptar-se rapidamente às mudanças tais como a mobilidade dos hosts, com a vantagem de não requerer nenhum custo extra ao protocolo de roteamento durante os períodos em que tais mudanças não ocorrem.

Assumimos como sendo verdadeiro o fato de que todos os hosts que desejam se comunicar com outros hosts dentro da rede ad hoc estão dispostos a participar inteiramente nos protocolos da rede. Em particular, cada host que participa da rede deve também estar disposto a enviar pacotes para outros hosts. Verificamos o número de hops necessários para que um pacote alcance, de qualquer host situado em uma das extremidades da rede, a um outro host situado no extremo oposto. Chamamos isso de diâmetro da rede. Por o exemplo, o diâmetro da rede ad hoc descrita na Fig.5 é 02 (dois). Assumimos que o diâmetro de uma rede ad hoc será pequeno mas podendo frequentemente ser maior que 01 (um).

Os hosts dentro da rede ad hoc podem mover-se em qualquer momento sem aviso, mas nós assumimos que a velocidade deste movimento é


moderado com relação à latência de transmissão do pacote e o limite de transmissão wireless particular da rede em uso. Assumimos que os hosts não se movem de forma tão contínua e rápida, a respeito de necessitarem fazer flooding de cada pacote como única alternativa de protocolo possível de roteamento.

Supomos que os hosts podem permitir um modo de recebimento promíscuo em sua interface de rede wireless, fazendo com que o hardware entregue cada pacote recebido ao software de driver de rede sem filtragem prévia, baseado no endereço de destino. Embora não requeiramos esta facilidade, é comum nos hardwares atuais de LAN, mídias que dão suporte a broadcast em redes wireless e algumas de nossas otimizações fazem um exame das vantagens delas. O uso da modalidade promíscua aumenta os custos de software no processador central, mas acreditamos que a velocidade das redes wireless é o fator mais limitante ao desempenho em sistemas atuais e futuros. Acreditamos que porções do protocolo são também apropriadas para execução diretamente no hardware ou dentro de uma interface de rede programável para evitar esse overhead na CPU.

5 . 1 O P E R A Ç Ã O D E R O T E A M E N T O

Para enviar pacotes a um outro host, o remetente constrói um source route no cabeçalho do pacote, fornecendo o endereço de cada host na rede através dos quais o pacote deve ser enviado a fim alcançar o host destino. Este transmite então o pacote pela sua rede wireless ao primeiro hop identificado na rota. Quando um host recebe um pacote, se este host não for o destino final do pacote, transmite simplesmente o pacote ao hop seguinte identificado na rota (cabeçalho do pacote). Uma vez que o pacote alcance seu destino final, ele será entregue ao protocolo da camada de rede naquela host.


Cada host móvel que participa na rede ad hoc mantém um route cache no qual ele armazena as rotas que “aprendeu”. Quando um host envia um pacote a um outro host, o remetente primeiramente verifica seu route cache para uma rota de destino. Se esta rota for encontrada, o remetente usa esta rota para transmitir o pacote. Se nenhuma rota for encontrada, o remetente pode tentar descobrir uma usando o protocolo route discovery. Enquanto espera a route discovery para completar a operação, o host pode continuar seu processamento normal, podendo enviar e receber pacotes com outros hosts. O host pode bufferizar o pacote original a fim transmiti-lo quando a rota for “aprendida” do route discovery, ou pode rejeitar o pacote, confiando nos protocolos das camadas mais altas para retransmiti-lo se houver necessidade. Cada entrada no route cache tem associado com ela um período de expiração, depois do qual ela é suprimida do cache.

Quando um host estiver usando alguma rota fonte, ele monitora a corretude da operação dessa rota. Por o exemplo, se o remetente, o destino, ou algum dos outros hosts nomeados como hops ao longo de uma operação de roteamento, tiver se movimentado para fora dos limites de transmissão wireless do hop seguinte ou precedente ao longo da rota, a rota não será mais usada para alcançar o destino. Uma rota também não será mais usada se alguns dos hosts ao longo da rota falharem ou forem desligados. Esta monitoração da corretude da operação no uso de uma rota nós chamamos de route maintenance. Quando a route maintenance detecta um problema com uma rota em uso, a route discovery pode ser usada outra vez para identificar uma nova rota que encaminhe os pacotes corretamente até o destino.

5 . 2 O T I M I Z A Ç Ã O C O M O U S O D E C A C H E

Os dados no route cache do host podem ser armazenados em qualquer formato, sendo que as rotas ativas em seu cache formam uma árvore de rotas, enraizada neste host, a outros hosts na rede ad hoc. Por exemplo, a


Fig.5 mostra uma rede ad hoc com cinco hosts móveis, na qual o host móvel A completou primeiro o route discovery para o host móvel D e armazenou em seu cache a rota para D via B e C. Desde que os hosts B e C estejam na rota para D, o host A também “aprende” a rota para estes dois hosts em sua route discovery para D. Se mais tarde ele executar um route discovery e “aprender” a rota de E através B e C, ele poderá representá-la no seu route cache com a adição de um novo hop simples de C para E. Caso exista a possibilidade e A “aprenda”, este poderá alcançar C com um único hop (sem a necessidade de passar por B). A pode usar esta nova rota para C, para encurtar também as rotas para D e E em seu route cache.

B-C-D

Fig.5 - Um exemplo de rede ac hoc ilustrando o uso de route cache

Um host pode adicionar entradas a seu route cache quantas vezes ele “aprender” novas rotas. No caso particular, quando um host enviar um pacote de dados como um hop intermediário na rota deste pacote, o host de envio é capaz de observar a rota inteira do pacote. Assim, por exemplo, quando o host B envia pacotes de A para D, B pode adicionar as

A

F E

B C D


informações da rota deste pacote a seu próprio route cache. Se um host enviar um pacote route reply, pode também adicionar as informações da rota do registro que está sendo retornado neste route reply, a seu próprio route cache. Finalmente, como todas as transmissões da rede wireless são via broadcast, um host pode ser capaz de configurar sua interface de rede em modo de recebimento promíscuo, e então adicionar a seu route cache as informações de rota de qualquer pacote de dados ou de route reply que ele possa “ouvir”.

Um host pode usar seu route cache para evitar propagar um pacote route request recebido de um outro host. Neste caso, suponha que um host receba um pacote route request para o qual ele não é o alvo e ainda não está preenchido o registro da rota no pacote, e ainda, o par (initiator address, request id) não seja encontrado em sua lista de pedidos recentemente alcançados; se o host tiver uma entrada no route cache para o alvo do pedido, pode adicionar esta cached route ao registro acumulado da rota no pacote, e pode retornar esta rota em um pacote route reply ao remetente sem propagar (rebroadcasting) o route request. Assim, para o exemplo, se o host móvel F necessitar enviar um pacote ao host móvel D, iniciará uma route discovery e difundirá (broacast) um pacote route request. Se este broadcast for recebido por A, A pode simplesmente retornar um pacote route reply para F que contem a rota completa para D, que consiste na sequência dos hops A, B, C, e D.

Um problema particular pode ocorrer, entretanto, quando diversos hosts móveis recebem um broadcast do remetente do pacote route request, e todas as respostas são baseada em rotas encontradas em seus route caches. Na Fig.5, por exemplo, se A e B receberem o route request broadcast de F, ambos serão capazes de enviar respostas baseados em seus route cache, aproximadamente no mesmo tempo, desde que ambos tenham recebido o broadcast também aproximadamente no mesmo tempo. Particularmente quando mais do que um host móvel, como neste exemplo, são envolvidos, estas respostas simultâneas dos hosts móveis


que recebem o broadcast, podem criar colisões de pacotes entre algumas ou todas estas respostas e podem causar congestionamento local na rede wireless. Além disso, será frequente os casos em que respostas diferentes indicarão rotas de comprimentos diferentes. No exemplo, a resposta de A indicará uma rota para D que é um hop a mais do que na resposta de B.

Evitamos o problema de muitas respostas simultâneas e tentamos eliminar as respostas que indicam rotas mais longas do que a resposta à rota mais curta, fazendo com que cada host móvel atrase ligeiramente antes de responder, baseado em seu cache. Antes de responder de seu route cache, um host executa as seguintes operações:

1. Obtenha um período de atraso d = H * (h – 1 + r), onde h é o número de hops na rede para a rota retornada nesta resposta, r é um número randômico entre 0 (zero) e 1 (um), e H é um retardo constante e baixo a ser introduzido per hop.

2. Retarde a transmissão do route reply deste host por um período d.

3. Dentro deste período de retardo, receba promiscuamente todos os pacotes neste host. Se um pacote for recebido por este host durante este período de retardo, endereçado para o alvo desta route discovery (o alvo é o endereço final de destino para o pacote, através de alguma sequência intermediária de hops), e se o comprimento da rota deste pacote é menor do que h, cancele o retardo e não transmita o route reply deste host; este host pode inferir que o remetente desta route discovery já tenha recebido um route reply, fornecendo uma rota igual ou melhor que a sua.

Outro problema que pode ocorrer quando os hosts respondem um route request baseado em seu cache, é a formação de um loop na rota enviada no pacote route reply. O registro da rota no route request não pode conter um loop e nenhuma entrada no route cache é ajustada para uma rota que contenha um loop, todavia a concatenação do registro da rota e da entrada no route cache do host que respondeu para o alvo pode conter


um loop. Por exemplo, na Fig.5, se o host B não tem uma entrada em seu route cache para D, necessitará iniciar uma route discovery antes de enviar um pacote para D. Neste caso, A pode responder imediatamente baseado em seu route cache com a rota para D através de B e C. Isto, entretanto, formaria uma rota concatenada ABCD, possibilitando então que B utilize nos pacotes enviados para D, criando um loop de B para A e então voltando para B. A fim de evitar este problema, se um host recebe um route request e não é o alvo do pedido, mas possa responder baseado em seu cache, o host, ao invés, descarta o pedido se a rota em sua resposta possa conter um loop; esta limitação implica também que um host responderá baseado em seu cache somente com uma rota em que o próprio host esteja.

Como última otimização que envolve o uso do route cache, incluímos a habilidade para o remetente de um route request especificar no pacote do pedido, o número máximo dos hops sobre os quais pacote pode ser propagado. Se outro host próximo ao remetente tiver uma entrada no cache para o alvo de um route request, a propagação de muitas cópias redundantes do route request pode ser evitada se o remetente puder explicitamente limitar a propagação do pedido quando ele é originalmente enviado. Atualmente, usamos esta habilidade durante a route discovery como segue:

1. Para executar uma route discovery, emita inicialmente o route request com um limite de hop de 01 (um). Referimos a este como um route request não propagado.

2. Se nenhuma route reply for recebida deste route request após um pequeno intervalo de timeout, emita um novo route request com um limite de hop inicializado com um valor “maximum” pré-definido para o qual se supõe que todas as rotas úteis na rede ad hoc são menos do que este limite (atualmente 10).


Este procedimento usa o limite do hop no pacote route request para, de forma barata, verificar se o alvo estiver atualmente dentro do limite de transmissão wireless do remetente ou se um outro host dentro do limite tiver uma entrada route cache para este alvo (que use efetivamente os caches dos vizinhos deste host como uma extensão de seu próprio cache). Como o initial request é limitado a 01 (um) hop na rede, o intervalo de timeout antes de enviar um pedido por propagação pode ser bastante pequeno. Este mecanismo poderia também ser usado para implementar um “expanding ring” de busca pelo alvo, no qual o limite do hop é aumentado gradualmente em retransmissões subsequentes de route request para este alvo, mas não experimentamos ainda com esta abordagem.

Conclusão 34

6. C O N C L U S Ã O

Como alternativa tecnológica consideramos válidas ambas as propostas, tanto a de Redes Móveis por Difusão de Mensagens quanto a Redes Móveis Ad Hoc, principalmente pelos aspectos de praticidade, simplicidade e segurança de seus algoritmos de roteamento, principalmente quando sobre esses são impostas estratégias de otimizações (cache), contudo, temos algumas observações que veremos a seguir:

Em ambas as abordagens, os protocolos de roteamento propostos e otimizados não levaram em consideração a compatibilidade com o Mobile IP, assim como não existe autenticação para os elementos que compõem a rede.

Nas Redes Móveis Ad Hoc, mesmo com as otimizações propostas, ainda assim temos um grande overhead provocado pelos serviços internos da rede como por exemplo, os inúmeros broadcasts necessários para o roteamento.

Nas Redes Móveis Ad Hoc, verifica-se que as limitações geográficas, no domínio da distância, e de velocidade são significativas, limitando o uso da mesma (redes “confinadas”).

Nas Redes Móveis Ad Hoc, o enlace entre os hosts poderia ser mais bem utilizado se houvesse a possibilidade do estabelecimento de conexão IP por, pelo menos, um (o que estivesse com conexão mais “forte”) dos componentes da rede, possibilitando com isso que este elemento fizesse o papel de servidor de comunicação IP para os demais elementos, ampliando significativamente o espectro de uso desta rede, desde que houvesse alguma compatibilidade entre os protocolos de roteamento.

Conclusão 35

Desta forma, mesmo considerando válidas as propostas, ambas tem sérias restrições se considerarmos os atuais padrões adotados pelos organismos internacionais responsáveis.

Referências Bibliográficas 36

7. R E F E R Ê N C I A S B I B L I O G R Á F I C A S

[1] Craig E. Wills and Mikhail Mikhaikov. “Towards a Better Understanding of Web Resouces and Server Responses for Inproved Caching”. In Proc. World Wide Web Conference, May 1999.

[2] Mateus, Geraldo Robson e Loureiro, Antônio Alfredo Ferreira. “Introdução à Computação Móvel”.

[3] S. Acharya, R. Alonso, M. J. Franklin, and S. Zdonik. “Broadcast Disks: Data Management for Asymmetric Communications Environments”. In Proceedings of the ACM SIGMOD International Conference on Management of Data, June 1995.

[4] S. Acharya, M. J. Franklin, and S. Zdonik. “Prefetching from a Broadcast Disk”. In Proceedings of the 12th International Conference on Data Engineering, February 1996.

[5] M. H. Ammar. “Response Time in a Teletext System: An Individual User’s Perspective”. IEEE Transactions on Communications, 35(11), November 1987.

[6] D. Barbará and T. Imielinski. “Sleepes and Workaholics: Caching Strategies in Mobile Environments”. In Proceedings of ACM SIGMOD International Conference on Management of Data, pages 1-12, 1994.

[7] J. Jing, O. Bukhres, A. K. Elmargarmid, and R. Alonso. “Bit-Sequences: A New Cache Invalidation Method in Mobile Environments”. Technical Report CSD-TR-94-074, Departament of Computer Science, Purdue University, 1995. Revised May 1995.

[8] K. L. Wu, P. S. Yu, and M. S. Chen. “Energy-Efficient Caching for Wireless Mobile Computing”. In Proceedings of the 12th International Conference on Data Engineering, February 1996.

[9] Johnson, David B. and Maltz, David A. “Dynamic Source Routing in Ad Hoc Wireless Networks”. Computer Science Department, Carnegie Mellon University, 1996.

[10] John Jubin and Janet D. Tornow. “The DARPA Packet Radio Network Protocols”. In Proceedings of the IEEE, 75(1):21-32, January 1987.

Referências Bibliográficas 37

[11] Charles E. Perkins and Pravin Bhagwat. “Highly Dynamic DestinationSequenced DistanceVector Routing (DSDV) for Mobile Computers”. In Proceedings of the SIGCOMM'94 Conference on Communications Architectures, Protocols and Applications, pages 234-244, August 1994.

[12] Nachum Shacham and Jil Westcott. “Future Directions in Packet Radio Architectures and Protocols”. In Proceedings of the IEEE, 75(1):83-99, January 1987.

[13] David F. Bantz and Frédéric J. Bauchot. “Wireless LAN Design Alternatives”. IEEE Network, 8(2):43-53, March/April 1994.

[14] Gregory S. Lauer. “PacketRadio Routing”. In Routing in Communications Networks, edited by Martha E. SteenStrup, chapter 11, pages 55-76. Prentice-Hall, Englewood Cliffs, New Jersey, 1995.

[15] Radia Perlman. “Interconnections: Bridges and Routers”. AddisonWesley, Reading, Massachusetts, 1992.

Tecnologias relacionadas a XML - PUC-Rioendler/courses/Mobile/Monogra… · Web viewPor...

Documents

Transcript of Tecnologias relacionadas a XML - PUC-Rioendler/courses/Mobile/Monogra… · Web viewPor...