T estando todos os pares de interfa e

O projeto Ro ketfuel [57 ℄ testava apenas pares de interfa es que davam algum indi ativo

de provavelmente perten erem a um mesmo roteador, por exemplo: pares de interfa es om

nome pare ido no DNS, ou pares de interfa es ujos IPs são pare idos. Isso pode deixar de

fora diversos pares que não têm essas ara terísti as em omum e ainda assim perten em a

um mesmoroteador. A vantagem da nossametodologia de resoluçãode interfa es sinnimas

sobre a metodologia adotada no projeto Ro ketfuel é o fato de testarmos todos os pares de

interfa esen ontrados nas oletasdetra eroute, usandopara adapar,otestesIP eoteste

IPID des ritosna seção3.4.2.1 .

O maior problema om a nossa metodologia é a quantidade de pares a serem testados.

Havendo

n

interfa es,são

(n×(n−1))/2

paresaseremtestados 1

. Nonosso aso,en ontramos

13335 interfa es, das quais8897 respondiam ao teste de resolução de interfa es sinnimas, o

que orresponde a quase 40 milhões de pares. Dependendo da velo idade om que essas

interfa es respondem (se responderem), um teste de um par de interfa es pode durar até 5

segundos. Mesmo assumindo que ada teste durasseem média apenas 1 segundo, testar 40

milhõesdepares seqüen ialmente é inviável, pois demoraria maisde1 ano.

Existeapossibilidadedeparalelizaçãodessestestes. Sendo8900interfa es,mesmoquenão

queiramos envolver umamesma interfa e em maisde 1 teste por um período de 5 segundos,

é possível,emtese,testar4450pares simultaneamente a ada 5segundos. Criou-seentãoum

sistemade resolução de interfa es sinnimas, omosseguintesobjetivos:

•

gerar ospares aseremtestados, não testando interfa es quenão estejamrespondendo;

•

paralelizar a realizaçãodos testes;

•

priorizar pares de interfa esquetiverem maior han ede seremsinnimasentresi;

•

testarpelomenos3vezes,temporalmenteespaçadas,pares ujotesteIPID(seção3.4.2.1 ) a usasse sinonimidade, mas o teste IP (seção 3.4.2.1) não onseguisse determinar isso.

1

Umaotimização poderiaserfeita paradiminuironúmeroini ial depares,tirandoproveitodofato de

arealizaçãodoTesteIPnãorequererqueambasasinterfa esdeumparpassempelotestesimultaneamente.

LembrandoqueoTesteIP onsistenoenviodeum pa otea adainterfa e dopar ea omparação entreos

ampos SRC dospa otes ICMPretornados porelas, seria possível enviar somente1 pa ote a adauma de

todasasinterfa esen ontradaseutilizarosresultadosparaformar umabaseini ialdeinterfa essinnimas.

Figura4.3: Arquitetura dosistemade resolução deinterfa es sinnimas

Figura4.4: Exemplode exe uçãoda ferramenta ally

4.3.1.1 Arquitetura e fun ionamento do sistema de resolução de interfa es

sinnimas

Nosso sistema de resolução de interfa es sinnimas foi onstruído utilizando omo base a

ferramenta ally do projeto Ro ketfuel [57 ℄. O programa ally re ebe omo parâmetros duas

interfa es IP,realiza oTesteIP e, asoo resultadonão sejapositivo, realizatambémo Teste

IPID.

A gura 4.4 mostra um exemplo de exe ução do ally, para duas interfa es que não são

sinnimas. A linha rotulada 0: mostra os dados do pa ote ICMP re ebido do roteador

que ontém a primeira interfa e, 150.164.3.39. Neste aso opa ote ICMP veio dessa mesma

interfa e, segundo mostra o ampo from dessa linha, mas ele poderia ter vindo de outra,

revelandoassimumsinnimopara150.164.3.39. Essalinhamostratambémovalordo ampo

IPIDdessepa ote,9400,bem omooTTLdopa otederequisiçãoquandoessepa ote hegou

à interfa e e o TTL do pa ote ICMPre ebido. A linha rotulada 1: mostra o mesmo tipo

de informação parao pa ote re ebidoda segunda interfa e. Poderia haverlinhas 2: e 3:

orrespondente a segundospa otes enviadosàsinterfa es. Oenviodo segundopa oteo orre,

por exemplo, quando os primeiros pa otes indi am que as interfa es podem ser sinnimas

pelo teste IPID, o que não é o aso, já que os ampos IPID dos primeiros pa otes são bem

diferentes entre si.

Na mesmagura, nasegunda exe ução, quefoi ronometrada omo omando time,note

que o tempo de pro essamento é de 5 milisegundos, enquanto o tempo de resposta é de 62

milisegundos. Comooteste dagurafoirealizadoemumamáquinaquenão estavasobre ar-

regada, issoindi a queo pro essoally  ou muitotempoparado, simplesmenteesperandoos

pa otes ICMPde respostaretornarem. Daíapossibilidade deparalelizaçãodostestes,aqual

nosso sistemaexplora.

Nosso sistema é responsável por riar e geren iar os pares de interfa e, determinando

quando ada par deve ser submetido ao teste do ally, interpretando a saída do ally e assim

riando umabase desinnimos. A seguirdetalhamos ofun ionamento do sistema.

A gura 4.3 mostra a arquitetura do nosso sistema. Os rótulos numéri os dessa gura

(dentrode ír ulos)serãoutilizadosaseguir,entreparênteses,parafa ilitarades riçãopasso-

a-passo dofun ionamento dosistema.

Osistemare ebe,atravésde umarquivo forne ido pelainterfa e om ousuário (1), uma

listadeinterfa es(endereçosIPv4), adaumadelasop ionalmenteasso iadaaumnomeDNS

e a umidenti adorde sistemaautnomo.

O sistema primeiro testa (2) se a interfa e está respondendo ao tipo de teste realizado

peloally. Caso dada interfa e não esteja respondendo, ela éarmazenada a partee o sistema

realizaumnovoteste omelaa ada6horasparaveri arseelapassouaresponderejápode

ser inserida.

Caso esteja respondendo, a interfa e será então inserida para testes. Criam-se os obje-

ombasenasemelhança entreosendereços IPdasinterfa es, entre osnomesDNSe entreos

identi adores de sistemas autnomos. Considera-se que identi adores de sistemasautno-

mossão semelhantes se eles sãoiguais ou se orrespondem a sistemasautnomos adja entes

dea ordo omo grafode sistemasautnomos (5)obtido em[13, 10℄. Ospares sãoinseridos

na la de pares (6) para testes, em uma posição que depende da prioridade do par, pares

maisprioritários  ando noprin ípio da la.

Existem

n

uxos de exe ução paralelos (7) responsáveis por testar os pares da la (no

nosso aso usamos

n = 30

, mas esse valor pode ser ongurado de a ordo om a apa idade

de pro essamento da máquina onde o sistema estiver rodando). Cada uxo de exe ução

varre a la a partir do prin ípio (maiorprioridade), bus ando por um par tal que nenhuma

das interfa es esteja travada, isto é, envolvida em um teste om alguma outra interfa e.

Ao en ontrar um par assim, esse par é retirado da la e as interfa es que o ompõem são

travadas (3).

Ouxode exe uçãorealiza a hamadafork, paraexe utaro ally,que realizao teste om

asduasinterfa es e armazenasuasaídaem umarquivo.

Apósterminado o ally,o par é des artado e asinterfa es orrespondentes  amem uma

ladedes anso (8) por 5segundos antes deserem destravadas(6). Issoimpede queasin-

terfa essejamtestadasmuitofreqüentemente. Umdosproblemas omtestesdemasiadamente

freqüentes é queexistemroteadores quelimitam a quantidade de pa otes ICMPgerados por

unidadede tempo. Portanto, testarvárias vezesseguidas umainterfa e de talroteador pode

levar avários dessestestes seremin on lusivos.

Também apósa exe uçãodo ally, o mesmo uxo (7) que deu origem ao pro esso ally é

en arregadodeleroarquivogerado(asaídadoally)einterpretá-lo,paradeterminarseforam

des obertos novossinnimose assimatualizar a basedeinterfa es sinnimas(9).

CasoopartenhapassadonotesteIP,elessãogarantidamentesinnimos,assimessainfor-

maçãoéarmazenadanabasedesinnimos(9)eoobjeto orrespondenteaoparédes artado.

Caso ontrário,seapenasotesteIPIDtiversidopositivo,existea han e,masnãoagarantia,

deasinterfa esseremsinnimas. Neste aso,umnovopar é riado omessasinterfa es. Esse

novo par des ansa por 1 hora(10) para dar tempo de os ontadores dos dois roteadores se

dessin ronizarem aso o resultado positivo tenha sido apenas uma oin idên ia. Após esse

tempo, o novo par volta para a la de testes (6), a m de ser testado novamente. Ao ter

passado por 3 vezes pelo teste IPID (essa informação é mantida em (11)), as interfa es do

par são nalmente onsideradas sinnimas e armazenadas na base de sinnimos (9). Se em

algumadessas3vezesoteste IPIDfalhar, onsidera-sequehavia sidoapenasuma oin idên-

iae o par é removido do sistemasem que asinterfa es que o ompõem sejam onsideradas

sinnimas.

No documento Roteamento de mídia contínua em topologias reais da internet (páginas 55-58)