barriquello
commented
6 years ago Fabrício, acho que isto pode adicionar muita complexidade ao software. Fica mais simples se o nó que recebe o pacote só aguardar a rota ser atualizada e depois seguir normalmente. Da mesma forma, o nó anterior que enviou o pacote pode trocar a rota para o próximo pacote e seguir normalmente. Acho que não vale a pena colocar muita complexidade no roteador, pois aumenta a chance de ter bugs, a não ser que seja algo que permita reduzir o tráfego na rede. Por exemplo, o ACK com status me parece mais interessante se for usado para indicar ao nó anterior que há espaço no buffer para um pacote que havia sido anteriormente descartado por falta de buffer. Assim, evitaria que o nó anterior ficasse retransmitindo várias vezes um mesmo pacote até que tenha espaço no buffer (como acontece hoje). Até nem precisaria ser um ACK, mas uma mensagem de link avisando que o buffer foi liberado. O nó anterior pode ter um timer para evitar ficar muito tempo esperando caso não receba a mensagem. Aí ele pode trocar de rota ou tentar novamente, pois pode não ter recebido a mensagem de link. De qualquer forma, acho que seria importante testar no simulador para ver se ajudaria na diminuição do tráfego e na taxa de entrega.
Boa tarde,
No módulo unet_core.c na função UNET_Router_Down_Ack_Task, verifica-se que a emissão do pacote de confirmação ocorre antes de verificar se o dispositivo possui alguma rota para o pacote recebido.
Não seria melhor verificar se há rotas disponíveis antes de retornar o pacote de confirmação? Desse modo o dispositivo anterior pode verificar outras rotas para utilizar para emitir suas informações. Nesse caso, acredito que deva-se utilizar uma mensagem de ACK com retorno de status, indicando que a mensagem foi entregue, entretanto sem rota para prosseguir.
Obrigado!