18.03.2015 Views

XI Workshop de Testes e Tolerância a Falhas (WTF) - SBRC 2010

XI Workshop de Testes e Tolerância a Falhas (WTF) - SBRC 2010

XI Workshop de Testes e Tolerância a Falhas (WTF) - SBRC 2010

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>XI</strong> <strong>Workshop</strong> <strong>de</strong> <strong>Testes</strong> e Tolerância a <strong>Falhas</strong> 167<br />

namento e <strong>de</strong>scarte <strong>de</strong> mensagens são <strong>de</strong>senvolvidas e um mecanismo <strong>de</strong> replicação <strong>de</strong><br />

mensagens é implementado. O algoritmo não consi<strong>de</strong>ra para encaminhamento das mensagens<br />

nenhuma informação sobre o estado futuro da re<strong>de</strong>. Uma avaliação é realizada<br />

comparando os resultados do NECTAR com os obtidos pelos algoritmos Epi<strong>de</strong>mic Routing<br />

[Vahdat e Becker 2000] e PROPHET [Lindgren et al. 2004] consi<strong>de</strong>rando tamanhos<br />

distintos <strong>de</strong> buffer e verificando a quantida<strong>de</strong> <strong>de</strong> mensagens entregues e o número <strong>de</strong> saltos<br />

realizados pelas mesmas.<br />

Três algoritmos distribuídos para construção <strong>de</strong> tabelas <strong>de</strong> roteamento em DTNs<br />

previsíveis foram propostos em [Santos et al. 2008]. Em um dos algoritmos, o Distributed<br />

Shortest Journey (DSJ), cada nó calcula a tabela <strong>de</strong> roteamento <strong>de</strong>le para todos os outros<br />

nós consi<strong>de</strong>rando o menor número <strong>de</strong> saltos. No outro, <strong>de</strong>nominado Distributed Earliest<br />

Journey (DEJ), as tabelas são construídas objetivando a chegada mais cedo da informação<br />

ao nó <strong>de</strong> <strong>de</strong>stino. Por último, o algoritmo Distributed Fastest Journey (DFJ), realiza a<br />

construção das tabelas levando-se em consi<strong>de</strong>ração as jornadas mais rápidas para chegar<br />

até os <strong>de</strong>stinos. Em todos os algoritmos a construção da tabela em cada nó é realizada à<br />

medida que os enlaces para os nós vizinhos tornam-se disponíveis e novas informações sobre<br />

o estado da re<strong>de</strong> são obtidas. As tabelas geradas mantêm, para cada nó <strong>de</strong> <strong>de</strong>stino, uma<br />

lista or<strong>de</strong>nada dos intervalos <strong>de</strong> tempo <strong>de</strong> disponibilida<strong>de</strong> dos enlaces adjacentes. Cada<br />

intervalo é único na lista e <strong>de</strong>termina qual vizinho <strong>de</strong>ve receber a mensagem para posterior<br />

encaminhamento para cada nó <strong>de</strong> <strong>de</strong>stino. Os algoritmos realizam um filtro nos instantes<br />

<strong>de</strong> tempo <strong>de</strong> disponibilida<strong>de</strong> dos enlaces adjacentes para evitar o envio <strong>de</strong>snecessário <strong>de</strong><br />

mensagens <strong>de</strong> controle pelos canais <strong>de</strong> comunicação.<br />

Em [Argolo et al. 2009], além do algoritmo AJRP, também é proposto um<br />

mo<strong>de</strong>lo <strong>de</strong> Programação Linear Inteira para DTNs baseado na abordagem multicommodities<br />

flow. Esta formulação matemática difere das <strong>de</strong>mais [Jain et al. 2004,<br />

Balasubramanian et al. 2007], pois a complexida<strong>de</strong> para encontrar a solução ótima é diretamente<br />

proporcional ao número <strong>de</strong> nós e não ao número <strong>de</strong> mensagens da re<strong>de</strong>. Uma<br />

comparação dos resultados do AJRP com a solução ótima foi realizada consi<strong>de</strong>rando as<br />

limitações <strong>de</strong> largura <strong>de</strong> banda dos enlaces e <strong>de</strong> capacida<strong>de</strong> <strong>de</strong> armazenamento dos nós.<br />

A avaliação mostra que o AJRP obteve um <strong>de</strong>sempenho satisfatório, entregando cerca <strong>de</strong><br />

96% da <strong>de</strong>manda <strong>de</strong> mensagens quando atribuída baixa carga <strong>de</strong> mensagens na re<strong>de</strong> e<br />

cerca <strong>de</strong> 83% quando submetida a uma alta carga.<br />

3. Mo<strong>de</strong>lo<br />

DTNs previsíveis po<strong>de</strong>m consi<strong>de</strong>rar várias informações conhecidas antecipadamente, tais<br />

como: a disponibilida<strong>de</strong> <strong>de</strong> contato entre os nós da re<strong>de</strong> ao longo do tempo; as <strong>de</strong>mandas<br />

<strong>de</strong> mensagens <strong>de</strong> cada nó; e a capacida<strong>de</strong> <strong>de</strong> armazenamento <strong>de</strong>stes. No entanto, a<br />

obtenção a priori <strong>de</strong> todo este conhecimento é praticamente inviável <strong>de</strong>vido ao tamanho<br />

da re<strong>de</strong> ou até mesmo a própria dinâmica <strong>de</strong> geração das mensagens.<br />

O problema <strong>de</strong> roteamento em DTNs consiste em entregar as mensagens aos <strong>de</strong>stinos<br />

<strong>de</strong> acordo com uma métrica pré-<strong>de</strong>terminada, levando-se em conta as restrições <strong>de</strong><br />

disponibilida<strong>de</strong> e capacida<strong>de</strong> dos enlaces para transmissão das mensagens, assim como as<br />

limitações <strong>de</strong> armazenamento <strong>de</strong>stas pelos nós da re<strong>de</strong>. As <strong>de</strong>sconexões presentes nestas<br />

re<strong>de</strong>s po<strong>de</strong>m implicar na inexistência <strong>de</strong> uma rota fim-a-fim entre a origem e o <strong>de</strong>stino.<br />

O presente trabalho utiliza o mo<strong>de</strong>lo para DTNs proposto em [Argolo et al. 2009],

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!