Roteamento em redes ad hoc: quando a infraestrutura centralizada desaparece — cenários como guerras e catástrofes exigem redes onde carros e dispositivos móveis atuam simultaneamente como roteadores e hosts. O algoritmo AODV (Ad hoc On-demand Distance Vector) resolve esse desafio com descoberta de rotas sob demanda via flooding recursivo, economizando largura de banda e bateria ao evitar tabelas de roteamento estáticas. A topologia mutável dessas redes torna impossível garantir caminhos fixos ou bidirecionais. O ponto fraco do AODV é a tentativa de manter estado de conexão após o roteamento, consumindo bateria desnecessariamente — ponto que o professor aponta como oportunidade de melhoria e tema promissor para pesquisa acadêmica.
Transcrição do áudio
Recoleguinha, vamos falar sobre roteamento em redes ad hoc. Então nós vimos até agora o que? Nós vimos redes que nós tínhamos a estação base centralizada ou pelo menos distribuída, mas mesmo uma ficha fixa. Agora imagine você um seguinte cenário, uma calamidade total, roteadores móveis em carros, andando por, por exemplo, vamos imaginar um terremoto em escala do tipo que destrói uma cidade inteira, vamos colocar assim. Ah, a Califórnia, quem sabe, eles estão, eles estão sobre uma espécie sinistra lá, né? Vamos imaginar então uma guerra, o que? Ucrânia, gása, complica gása não foi gela, né? Então vamos imaginar esse cenário catastrófico e aí você tem o que? Você tem carros que são roteadores e também eles são pares de comunicação. Então imagine que eu tenho um dispositivo móvel e eu me comunico com o meu carro e o meu carro eles comuniquem com outros carros como roteadores. Então os roteadores que comem cima desses carros grandes, as caminhonetes, vamos colocar assim e lá também tem outras pessoas e nós dentro desse cenário nós estamos lá tendo uma rede para nos comunicar. Então seria uma rede ad hoc, pois o router e a máquina são dispositivos que estão sempre andando, sempre se movimentando, saindo de posição, saindo de alcance. Então cada nó consiste então em um roteador e um host e que naturalmente você pode ter mais de um host, né? E em geral no mesmo computador, vamos imaginar assim e nesse cenário como nós teríamos um problema que seria e o alcance eu não posso naturalmente acreditar que todos os pares de conexão comigo estão dentro dos alcances de um do outro. Pode ser comum que nesse cenário eu tenho um outro que saia do alcance de todos e fique fora da comunicação. Também eu não posso garantir que se eu mandei uma mensagem por um caminho ele vai naturalmente voltar pelo mesmo caminho ou até mesmo a segunda mensagem vai passar pelo mesmo caminho. O que seria ruim numa guerra por exemplo, sabendo qual é o caminho eu conseguiria destruir alguém no meio do caminho. Olha só que interessante, os russos eles partiram, na verdade os soviéticos partiram para a ideia do Sputnik. Lança lá de cima e lá de cima então todos se comunicam, certo? Legal. Os americanos foram para uma outra ideia, para uma rede descentralizada chamada de SEPA em que a decisão do caminho não é tomado por quem manda mensagem sim pelos elementos intermediários da rede, que é bem parecido com o que temos hoje em redes de computadores. Veja que todos os dois cenários, tanto os americanos como os soviéticos, eles pensam em um modelo em que a pessoa que decide o caminho, então se for possível saber o caminho seria possível alcançar um elemento intermediário para que não acontecesse a troca de mensagens. Então pensa assim, e se você acha que guerra não está tão longe, desculpe, se você acha que não está tão perto, saiba que até os seis anos atrás quem imaginar uma pandemia, né? Seis anos atrás quem imaginar uma guerra de pandemia ou do Irã, pensa assim, então cara, começa a estudar, tá? Começa a estudar para você terminar no fundo de uma vala morrendo engasgado com bosta e fezes de todo mundo da trincheira, né? Ou se você for para a trincheira, tu posso para levar um tiro logo e morrer logo lá de vez, porque morre agonizando na merda dos outros foda. O que torna as redes ad hoc tão diferentes das redes fisicamente conectadas é que a topologia é repetidamente abandonada, ela é mutável, o tempo inteiro mutável, porque os elementos saem de cena e eles entram em cena. Tem vários problemas aí, eu vejo números TCCs nisso aí, eu vejo números pesquisas nisso aí, porque é o futuro, muito triste de dizer, mas é o futuro. Você entende, né? O que está acontecendo? O mais popular dos algoritmos de volteamento é o AODV, que é um roteador baseado em distância e vetor, no caso vetor de distância, português, tá? E bem parecido com o RIP, só que dinâmico, em uma rede dinâmica, ele requer baixa largura de banda e pouca carga de bateria, só que eu acho que esse algoritmo tem um problema, cara, eu no meu ponto de vista, eu vejo que esse algoritmo tem uma merda lá que vai fazer gastar O que acontece? Você tem que entender que nesse cenário nem sempre você tem um reator nuclear, é sério! Se o teu carro quebrar na rua e você precisar de passar seis horas com o teu carro lá, você já tem problema com energia, porque você tem seu mobile, você tem um carro, provavelmente você vai querer colocar um som, você já tem problema com energia, cara. Então nem todo mundo tem um problema nuclear, acima do carro ou uma hidrelétrica, acima do carro, né? Agora você imagine o que? Um cenário catastrófico, onde não tem nada, você falar e o painel solar, tá? Você vai cargar um painel solar, o quê? De meio metro? Um meio metro? 50 por centímetros? Quanto que isso te carga, gera? Não gera muito, meu amigo! Então você tem que imaginar um cenário e esse algoritmo tem um que eu coloquei embaixo. Tá em vermelho. Mas vamos ver a ideia do algoritmo do cara. Descoberta sobre demanda, isso é bacana. Em vez de eu ficar monitorando os elementos e criando as tabelas de roteamento, igual nós vimos, por exemplo, no próprio vetor de distância ou no estado de enlace, penso o seguinte, e se eu montasse só na hora que eu preciso, você vai falar pra mim, vai ficar mais lento, porque veja, eu tenho que montar um caminho e depois eu tenho que transmitir. Pois isso vai ficar muito lento. Quem disse que velocidade é o problema? Olha o problema, baixa largura de banda, aqui é baixa largura de banda e requer pouca bateria. Então é isso mesmo. Preciso, cria-se um grafita e depois manda. Entende a jogada? A rede é um grafo. Bom, toda rede de computadores é um grafo. Isso aí não seria muito, muito, muito inovador no meu desalgoritmo. Um nó pode se comunicar com todos dentro de seu alcance. Então veja, o A tem o alcance de B e D. Então ele pode se comunicar com os caras aqui. Então eu teria o caminho de A para D de A para B. Diretamente. Tanto que B teria o caminho para D e D teria o caminho para B, certo? Legal. Envia um hold request por meio de folding. Então digamos, eu preciso de me comunicar, certo? Eu preciso de me comunicar. Vamos imaginar que é de A Beleza? Então eu pego, eu jogo para B para D, B para C, D para F, D para B, D para G. É o request indo. O C joga para E, o G joga para E, o G joga para H, o G joga para o I, o E joga para o G, o F joga para H. Veja que ele vai indo tipo num floating. Ele vai levando esse request até o I. Beleza? Então ele vai levando esse request até o I. E isso vai. Legal? E aí, o que que acontece? É que aqui o cara usou um caminho mais curto, né? Eu fui um trouxa. Eu já joguei do A no I. Depois, o que que eu faço? Eu pego e venho voltando à resposta. Nisso que eu venho montando a resposta, veja, é um grafo. Grafo é uma recursividade de envio de pacotes. Olha que louco. É uma recursividade de chamada de método, não, meu amigo. É uma recursividade para você jogar os pacotes nessa rede. Essa coisa vai de forma recursiva. E depois ela vem voltando. Concorda comigo o que quem voltar primeiro chegou? Primeiro, então eu encontro um caminho e o melhor caminho, né? Então, depois eu retorno o Holder Hapley, que vai retornar o caminho inverso e primeiro que chegar. O único problema é que ele mantém o estado. Ele tenta manter o estado de conexão. Então, ele A tenta manter um estado com B e A tenta manter um estado com B, B tenta manter um estado com D e D tenta manter um estado com B. E isso aqui, atualmente, tá? Essas tentativas de manter, isso aqui vai consumir bateria. No meu ponto de vista, essa é a merda. Esse algoritmo, no meu ponto de vista, poderia ser melhor se foda-se. Não tem que manter tabela nenhuma. Não tem que manter nada. Tá muito bom até o 5. Tá muito bom até o 5. Depois ele fica tentando manter o estado e aí ele pede bateria. Bom, em todo mundo carregam, reatam, não queriam ter uma doença assim, tá? Esse algoritmo é muito bom, cara. Eu acho que vale um TCC. Se você quer fazer um TCC comigo, tá? Se você quer fazer um TCC comigo, eu faria roteadores de banco de dados distribuídos. Eu vou repetir, roteador de banco de dados distribuído. Cara, me procure. Até o próximo vídeo. Até mais. Tchau.