Encaminhamento de pacotes de dados

O encaminhamento dos pacotes de dados ´e feito no arquivo forwarder.cpp, onde s˜ao implementados os pipelines de encaminhamento. Como esta estrat´egia controla n˜ao s´o o encaminhamento de interesses, mas tamb´em o encaminhamento dos dados, foi necess´ario alterar o arquivo forwarder.cpp, mais propriamente a fun¸c˜ao onIncomingData, que ´e a fun¸c˜ao chamada quando um pacote de dados ´e recebido. A altera¸c˜ao feita foi a seguinte: antes de enviar o pacote de dados, ´e verificado se a estrat´egia de encaminhamento a ser utilizada ´e a BFstrategy. Se sim, em vez de enviar o pacote para a rede, vai para a fun¸c˜ao wait data, que ser´a explicada de seguida.

Cap´ıtulo 6. Implementa¸c˜ao 67

Figura 6.9: Sequˆencia de fun¸c˜oes para o encaminhamento de interesses, na estrat´egia BFstrategy

Al´em disso, foram acrescentadas duas novas fun¸c˜oes: wait data e sendData. A fun¸c˜ao wait data executa v´arias tarefas: em primeiro lugar, ´e verificado se ´e o consumidor a receber os dados ou o produtor a enviar os dados. Caso uma destas hip´oteses seja v´alida, o pacote de dados ´e enviado de imediato. De seguida, ´e verificado se a Tabela de interesses atrasados possui algum interesse com o mesmo prefixo que o pacote de dados acabado de receber e, nesse caso, o campo “Dados” ´e alterado para true. Depois, ´e verificada a Tabela de dados atrasados, para averiguar se existe algum pacote de dados igual ao pacote acabado de receber. Se sim, este ´e marcado como inv´alido e o pacote ´e

Cap´ıtulo 6. Implementa¸c˜ao 68

descartado. Sen˜ao, ´e calculado um tempo aleat´orio para o envio do pacote.

J´a a fun¸c˜ao sendData tem o mesmo objetivo do que a fun¸c˜ao sendInterest, mas para o caso do encaminhamento dos dados.

Na Figura 6.10 est´a representada a sequˆencia de fun¸c˜oes que foram alteradas e criadas, no encaminhamento de dados, para implementar esta estrat´egia de encaminha- mento. ´E de notar que a fun¸c˜ao onOutgoingData n˜ao foi alterada, estando na imagem apenas para mostrar o seguimento do c´odigo.

Todos os algoritmos podem ser consultados em anexo, no Apˆendice A: o algoritmo da fun¸c˜ao onIncomingData est´a representado na Listagem 5, o algoritmo da fun¸c˜ao wait data est´a representado na Listagem 6 e, por fim, o algoritmo da fun¸c˜ao sendData est´a representado na Listagem 7.

Figura 6.10: Sequˆencia de fun¸c˜oes para o encaminhamento de dados, na estrat´egia BFstrategy

Cap´ıtulo 6. Implementa¸c˜ao 69

6.5.2 Estrat´egia DSRstrategy

A estrat´egia DSRstrategy, abordada anteriormente na Sec¸c˜ao 5.2, foi baseada, tal como a estrat´egia anterior, no protocolo Blind Forwarding (BF) e, adicionalmente, no protocolo de encaminhamento reativo DSR (Dynamic Source Routing)[17] [2].

Nesta nova estrat´egia, foram alterados os ficheiros onde est˜ao definidos os pacotes de interesse e dados interest.cpp e data.cpp, respetivamente, porque foi definido um novo campo, no cabe¸calho do pacote de interesse e do pacote de dados, designado por “Path”, que ´e uma vari´avel do tipo string.

6.5.2.1 Encaminhamento de interesses

O encaminhamento de interesses ´e igual ao da estrat´egia BFstrategy e, por isso, os arquivos DSRstrategy.cpp e DSRstrategy.hpp s˜ao iguais aos arquivos BFstrategy.cpp e BFstrategy.hpp, respetivamente.

A altera¸c˜ao feita na fun¸c˜ao onIncomingInterest do forwarder.cpp ´e, tamb´em, igual `

a estrat´egia anterior.

Por outro lado, a fun¸c˜ao onOutgoingInterest do forwarder.cpp, que ´e chamada para enviar um interesse foi alterada, a fim de introduzir o ID do n´o no campo “Path” do cabe¸calho do interesse. Al´em disso, caso o n´o seja o produtor dos dados correspondentes do interesse, a rota do interesse ´e processada para, posteriormente, ser colocada no pacote de dados. Este algoritmo pode ser consultado em anexo, no Apˆendice B e est´a representado na Listagem 8.

Na Figura 6.11 est´a representada a sequˆencia de fun¸c˜oes que foram alteradas e criadas, no encaminhamento de interesses, para implementar esta estrat´egia de encami- nhamento. Os algoritmos das fun¸c˜oes afterReceiveInterest, wait interest e sendInterest n˜ao est˜ao descritos nesta estrat´egia, pois s˜ao iguais aos da estrat´egia BFstrategy, j´a abordada.

6.5.2.2 Encaminhamento de pacotes de dados

J´a para o encaminhamento de dados, foi alterada a fun¸c˜ao onIncomingData do forwarder.cpp: antes de enviar os dados, ´e verificado se ´e o produtor a enviar o pacote. Caso seja, envia-o de imediato. Caso contr´ario, se for um n´o interm´edio a reencaminhar o pacote, ´e necess´ario ir buscar o valor do campo “Path”, a fim de averiguar se o n´o

Cap´ıtulo 6. Implementa¸c˜ao 70

Figura 6.11: Sequˆencia de fun¸c˜oes para o encaminhamento de interesses, na estrat´egia DSRstrategy

pertence `a rota percorrida pelo interesse. Caso perten¸ca, envia o pacote, caso contr´ario, vai para a fun¸c˜ao wait data, j´a usada na estrat´egia anterior.

As fun¸c˜oes wait data e sendData, j´a abordadas na estrat´egia anterior, s˜ao usadas, tamb´em, nesta estrat´egia.

Na Figura 6.12 est´a representada a sequˆencia de fun¸c˜oes que foram alteradas e criadas, no encaminhamento de dados, para implementar esta estrat´egia de encami- nhamento. Os algoritmos das fun¸c˜oes wait data e sendData n˜ao est˜ao descritos nesta estrat´egia, pois s˜ao iguais aos da estrat´egia BFstrategy, j´a abordada.

Cap´ıtulo 6. Implementa¸c˜ao 71

O algoritmo da fun¸c˜ao onIncomingData pode ser consultado em anexo, no Apˆendice B, e est´a representado na Listagem 9. A fun¸c˜ao onOutgoingData n˜ao foi alterada.

Figura 6.12: Sequˆencia de fun¸c˜oes para o encaminhamento de dados, na estrat´egia DSRstrategy

6.5.3 Estrat´egia MPRstrategy

Esta estrat´egia, abordada anteriormente na Sec¸c˜ao 5.3, ´e baseada na t´ecnica Multi- Point Relay, que ´e usada pelo protocolo OLSR. Esta t´ecnica tem o objetivo de limitar os n´os da rede que reencaminham os pacotes, a fim de se poder eliminar mensagens re- dundantes. Assim, a sua fun¸c˜ao ´e selecionar um subconjunto de n´os da rede, chamados Multipoint relay (MPR), para disseminar mensagens por toda a rede. A escolha de cada MPR ´e feita de modo a que cubra todos os n´os a dois saltos de distˆancia.

Cap´ıtulo 6. Implementa¸c˜ao 72

Todos os n´os ter˜ao uma Tabela “Vizinhos”, cuja estrutura est´a ilustrada na Fi- gura 6.13. Esta tabela ´e representada por uma struct.

Figura 6.13: Estrutura da Tabela “Vizinhos” de um n´o na MPRstrategy

Por fim, a estrutura do pacote de interesse foi, novamente, alterada no arquivo interest.cpp, a fim de acrescentar o campo “MPR”. Neste campo ser´a colocado o conjunto de n´os MPRs calculado.

6.5.3.1 Encaminhamento de mensagens hello

Foi decidido que os n´os iriam iniciar as sua fun¸c˜oes em tempos diferentes, de modo a implementar um cen´ario mais real. Assim, o primeiro interesse hello a ser enviado por cada n´o ser´a feito em tempos diferentes, o que faz com que a troca de interesses hello n˜ao esteja sincronizada.

O protocolo de troca de hellos foi implementado com base em interesses e dados, o que levantou uma s´erie de problemas, nomeadamente:

• Em primeiro lugar, como um n´o N era, simultaneamente, consumidor e produtor do mesmo prefixo, “/hello”, quando N enviava um interesse com esse prefixo, em vez de enviar para uma interface n˜ao local, ou seja, enviar para outro n´o em broadcast, enviava internamente (para si pr´oprio), atrav´es de uma interface local. Isto porque j´a tinha encontrado o produtor do interesse que estava a enviar, que era o pr´oprio N. Todos os n´os tinham este comportamento e, por isso, n˜ao havia interesses com o prefixo “/hello” a serem enviados para a rede. Para contornar este problema, foi imposta a restri¸c˜ao de que, quando um n´o desejava enviar um interesse “/hello”, n˜ao poderia envi´a-lo por uma interface local, mas sim para a rede.

• Em segundo lugar, quando um n´o N recebia, pela primeira vez, um interesse “/hello”, deveria envi´a-lo internamente, por uma interface local, a fim de pro- duzir um pacote de dados. Em vez disso, o n´o descartava o interesse, pois, como tinha enviado um interesse “/hello” num curto espa¸co de tempo, os registos de

Cap´ıtulo 6. Implementa¸c˜ao 73

sa´ıda da entrada PIT do interesse enviado ainda n˜ao tinham expirado. Para eli- minar este problema, foi imposta a restri¸c˜ao de que, mesmo que os registos de sa´ıda, da entrada PIT do interesse enviado, ainda n˜ao estivessem expirados, o n´o N podia enviar o interesse recebido internamente.

• Aparentemente, o problema estaria resolvido, mas aconteceram mais imprevistos. Quando um n´o N recebia um interesse “/hello”, na segunda troca de interesses, em vez de produzir um pacote de dados novo, enviava o pacote que continha na sua Content Store. Isto n˜ao podia acontecer, pois os seus vizinhos poderiam ter-se alterado e o pacote de dados “/hello” tem de estar sempre atualizado. Para isso, foi imposta uma restri¸c˜ao que obriga um produtor a produzir sempre um novo pacote de dados “/hello” e nunca reutilizar o pacote armazenado na CS.

• Em quarto lugar, quando um produtor enviava um pacote de dados, em vez de en- viar, unicamente, para os seus vizinhos, enviava, tamb´em, para si pr´oprio, atrav´es de uma interface local. Isto porque, como tinha um interesse pendente com o mesmo prefixo, iria satisfazer esse interesse com os seus dados. Como o objetivo n˜ao era esse, foi imposta uma restri¸c˜ao para que um produtor n˜ao pudesse enviar o seu pacote de dados “/hello” para si pr´oprio.

• Em quinto lugar, um n´o N reencaminhava os pacotes de dados recebidos, atrav´es de um vizinho X, o que n˜ao poderia acontecer, pois os vizinhos de N iam achar que X era seu vizinho, o que poderia n˜ao ser verdade. Para isso, foi imposta a restri¸c˜ao de impedir o reencaminhamento de pacotes de dados “/hello”.

• Por ´ultimo, um consumidor s´o aceitava o primeiro pacote de dados que recebesse, aceitando s´o os dados de um ´unico vizinho. Isto acontecia porque o n´o verificava que j´a tinha aquele pacote de dados, com o prefixo “/hello”, e, por isso, descartava novos pacotes de dados. Para contornar este problema, foi imposta a restri¸c˜ao para que um consumidor aceitasse todos os pacotes de dados “/hello” recebidos.

Com todas estas solu¸c˜oes, o problema foi resolvido e foi conseguido o resultado esperado.

6.5.3.2 Encaminhamento de interesses

Como foi criada uma nova estrat´egia, foi necess´ario criar dois arquivos: MPRstra- tegy.cpp e MPRstrategy.hpp.

Cap´ıtulo 6. Implementa¸c˜ao 74

A fun¸c˜ao afterReceiveInterest do MPRstrategy.cpp tem a tarefa de verificar se o n´o pertence ao grupo de MPRs do interesse. Caso perten¸ca, adiciona o interesse `a Tabela de interesses atrasados, calcula o valor de TInterestM P R e programa a ida para a fun¸c˜ao

sendInterest, depois desse tempo. Caso n˜ao perten¸ca, descarta o interesse.

A fun¸c˜ao sendInterest verifica se o n´o recebeu os dados correspondentes, durante

TInterestM P R. Se sim, descarta o interesse. Sen˜ao, envia-o pela interface de sa´ıda.

A fun¸c˜ao onOutgoingInterest foi tamb´em, alterada: tal como na estrat´egia DSRs- trategy, ´e introduzido o ID do n´o no campo “Path” do cabe¸calho do interesse e, caso o n´o seja o produtor dos dados correspondentes do interesse, a rota ´e guardada para, posteriormente, coloc´a-la no cabe¸calho do pacote de dados. Al´em disso, antes de enviar o pacote, ´e calculado o conjunto de MPRs, atrav´es do algoritmo MPR, que foi explicado na Sec¸c˜ao 5.3.2.1, e o resultado ´e colocado no campo “MPR” do cabe¸calho do interesse. Por outro lado, se o interesse for um hello, ´e constru´ıda uma string com o seu ID e o ID de todos os seus vizinhos e, por fim, ´e enviado o resultado para o produtor.

Na Figura 6.14 est´a representada a sequˆencia de fun¸c˜oes que foram alteradas e criadas, no encaminhamento de interesses, para implementar esta estrat´egia de encami- nhamento.

Todos os algoritmos podem ser consultados em anexo, no Apˆendice C: o algoritmo da fun¸c˜ao afterReceiveInterest est´a representado na Listagem 10, o da fun¸c˜ao sendInterest est´a representado na Listagem 11 e o da fun¸c˜ao onOutgoingInterest est´a representado na Listagem 12. ´E de notar que a fun¸c˜ao onIncomingInterest n˜ao foi alterada.

6.5.3.3 Encaminhamento de pacotes de dados

Para o encaminhamento dos pacotes de dados foram alteradas as fun¸c˜oes onInco- mingData e onOutgoingData do forwarder.cpp, que s˜ao usadas para receber um pacote de dados e enviar um pacote de dados, respetivamente. Al´em disso, s˜ao usadas as fun¸c˜oes wait data e sendData, j´a abordadas nas estrat´egias anteriores.

As altera¸c˜oes feitas na fun¸c˜ao onIncomingData s˜ao as mesmas abordadas na es- trat´egia DSRstrategy e foi acrescentado um c´odigo extra, para a situa¸c˜ao em que ´e recebido um pacote de dados hello por uma interface local, ou seja, quando o n´o ´e o pro- dutor do pacote. Neste caso, o pacote ´e adicionado `a Tabela de dados Hello atrasados, ´

e calculado o valor de THello e programada a ida para a fun¸c˜ao sendHello, depois desse

Cap´ıtulo 6. Implementa¸c˜ao 75

Figura 6.14: Sequˆencia de fun¸c˜oes para o encaminhamento de interesses, na estrat´egia MPRstrategy

A Tabela de dados Hello atrasados serve para armazenar os pacotes, durante o tempo de espera antes do reencaminhamentos. ´E representada por uma estrutura de dados e tem, apenas, dois campos: o campo “ID”, que identifica o pacote e o campo “data”, que ´e o pacote de dados.

A fun¸c˜ao sendHello envia os pacotes de dados hello.

Por fim, a fun¸c˜ao onOutgoingData foi alterada, para permitir a troca de hellos: se for o produtor a enviar o hello, produzido por si, para si pr´oprio ou o produtor a reencaminhar o hello, recebido da rede, para outro n´o, a opera¸c˜ao ´e terminada.

Todos os algoritmos podem ser consultados em anexo, no Apˆendice C: o algoritmo da fun¸c˜ao onIncomingData est´a representado na Listagem 13, o da fun¸c˜ao sendHello est´a representado na Listagem 14 e o da fun¸c˜ao onOutgoingData est´a representado na Listagem 15.

A Figura 6.14 ilustra a sequˆencia de fun¸c˜oes que foram alteradas e criadas, no encaminhamento de dados, para implementar esta estrat´egia de encaminhamento. Os algoritmos das fun¸c˜oes wait data e sendData n˜ao est˜ao descritos nesta estrat´egia, pois s˜ao iguais aos da estrat´egia BFstrategy, j´a abordada.

Cap´ıtulo 6. Implementa¸c˜ao 76

Figura 6.15: Sequˆencia de fun¸c˜oes para o encaminhamento de dados, na estrat´egia MPRstrategy

Cap´ıtulo 7

Testes e resultados

Depois de implementado o cen´ario da rede de dados nomeados numa rede Ad Hoc e as v´arias estrat´egias de encaminhamento, procedeu-se `a execu¸c˜ao de testes. Para isso, foram feitas v´arias simula¸c˜oes, de forma a verificar e certificar o comportamento do cen´ario e das v´arias estrat´egias de encaminhamento implementadas.

Neste cap´ıtulo, ser˜ao apresentados todos os testes e simula¸c˜oes realizadas, assim como a an´alise e discuss˜ao dos resultados obtidos.

7.1

Configura¸c˜oes para a simula¸c˜ao

As simula¸c˜oes foram realizadas utilizando o simulador ndnSIM, como j´a tinha sido referido anteriormente.

Em todas as simula¸c˜oes feitas, para averiguar o desempenho dos protocolos de en- caminhamento implementados, s˜ao utilizados os mesmos parˆametros de configura¸c˜ao. Estes est˜ao de acordo com a Tabela 7.1. O cen´ario tem, ent˜ao, uma dimens˜ao de 600 metros por 1500 metros, com 80 n´os. O modelo de mobilidade usado foi o Random Waypoint e a posi¸c˜ao inicial dos n´os ´e feita de um modo aleat´orio. O alcance de trans- miss˜ao dos n´os ´e de 160 metros. O tipo de tr´afego ´e Constant Bit Rate (CBR), com uma frequˆencia de envio de 1 interesse por segundo. (A taxa de transmiss˜ao ´e de 2Kbps) e o tamanho dos pacotes de dados ´e de 64 Bytes. Por fim, foi usado um tempo de simula¸c˜ao de 204 segundos.

Cap´ıtulo 7. Testes e Resultados 78

Parˆametros Valor

Dimens˜ao 600m x 1500m

N´umero de n´os 80

Modelo de Mobilidade Random Waypoint Alcance de transmiss˜ao 160m

Tipo de tr´afego Constant Bit Rate (CBR) Tamanho dos pacotes 64 Bytes

Taxa de transmiss˜ao 2Kbps

Especifica¸c˜oes Wifi IEEE 802.11b, freq. 2.4GHz. Taxa de tranf. at´e 2Mbps Tempo de simula¸c˜ao (s) 204

Tabela 7.1: Parˆametros do cen´ario de simula¸c˜ao