Existem vários tipos de erros que podem ocorrer devido a problemas de rede, enquanto que outros são inerentes às próprias capacidades dos computadores utilizados, quer a nível de memória, a nível da capacidade de processamento ou da capacidade dos
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 55/113 Nuno Rafael Silva
Paulo Renato Silva interfaces de rede.
Contudo, nem todos os erros são passíveis de serem solucionados. Certos erros terão mesmo de ser comunicados ao emissor para este decidir o que fazer. Nesta última solução, muito embora a operação habitual seja o terminus da reserva, é possível implementar outro tipo de solução.
Uma das possíveis soluções seria terminar a reserva, comunicar ao emissor a fim de este iniciar nova reserva com os mesmos parâmetros. Como se torna óbvio, esta solução é manifestamente fácil de implementar.
10.8.1 - Recursos insuficientes no interface de rede
Este erro pode ocorrer sempre que é iniciada uma reserva, quando algum dos nós (pertencentes ao caminho que se iria criar) não dispõe de largura de banda suficiente aos requisitos da reserva, no interface necessário à reserva.
Como solução para este erro, propomos o envio duma mensagem SResvStat a informar o emissor do sucedido.
10.8.2 - Recursos insuficientes na alocação de memória
Este erro é de ocorrência rara, pois este deamon usa, para cada reserva, muito pouca memória.
Como acima mencionado, pressupondo que os computadores utilizados têm uma razoável quantidade de memória disponível, para simular este erro seria necessário não utilizar memória virtual (“memória swap”) e arranjar forma de ocupar memória desnecessariamente (consegue-se isso duma forma muito fácil, nomeadamente alocando memória desnecessariamente).
Neste caso, a função de alocação de memória reporta um erro, que deve ser detectado pelo deamon e enviado uma mensagem SResvStat ao nó emissor.
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 56/113 Nuno Rafael Silva
Paulo Renato Silva Neste caso o erro não é directamente detectado. O único processo de o detectar cifra-se em recorrer ao refrescamento da própria reserva.
Neste caso, as mensagem não são processadas pelo deamon atempadamente pelo que a reserva acaba por expirar devido à saturação do buffer de entrada (e consequente perda do pacote) ou, em alternativa, devido à escassez temporal de processamento para que a mensagem.
Nesta situação é muito importante o uso do conceito de reservas soft-state, pois se a reserva não for refrescada, esta é terminada. Atente-se que o nó em questão ao receber um pacote de refrescamento deve ser capaz de verificar que a reserva deixou de existir (através do mapa de bits de memória alocada), e enviar uma mensagem SResvStat a todos os nós anteriores a reportar o erro sucedido.
De igual modo, pode-se enviar uma mensagem de SResvTear para terminar a reserva a todos os nós seguintes. Esta última operação não é vital dado que as reservas sempre acabarão por expirar.
10.8.4 - Mudanças de rota na rede
Durante o tempo de vida duma reserva pode facilmente ocorrer mudanças no percurso do fluxo da reserva.
Graças ao processo de envio de mensagens nó a nó (“hop by hop) é possível de detectar facilmente tais ocorrências. Através dos dados guardados em memória para cada reserva, onde se inclui, o IP do nó anterior e do nó seguinte, podemos fazer uma comparação desses valores com os valores contidos na própria mensagem. De notar que esta detecção deve-se fazer antes de enviar a própria mensagem. Para realizar tal tarefa, deve-se consultar a tabela de roteamento no nó em questão e verificar se esta vai ser enviada pelo interface correcto.
Detectado o problema pode-se recorrer a um mecanismo de mudança da rota da reserva. Este mecanismo consiste em detectar a mudança de rota e seguidamente tentar criar novas reservas com as mesmas especificações pelo novo percurso. Ou seja, envia- se uma mensagem SResvInit a partir do nó onde foi detectado o erro e procede-se a um processo de criação de reserva em tudo idêntico ao inicial.
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 57/113 Nuno Rafael Silva
Paulo Renato Silva
Pode-se, igualmente, terminar as reservas anteriores através do envio duma mensagem SResvTear. Contudo, se tal não for possível, e visto que a reserva acaba por terminar por falta de refrescamento, este problema não merece especial atenção.
O erro pode ser detectado no nó seguinte ao da mudança de rota, quando, na altura da consulta da tabela de roteamento do nó, a mudança ainda não tivesse ocorrido, mas já tenha sucedido (essa mudança) aquando envio da mensagem. Neste caso o nó vai detectar a reserva como se fosse uma reserva que tivesse terminado.
A solução para este problema passaria por enviar uma mensagem SResvStat ao nó anterior, como se de uma reserva expirada se tratasse. Esta, por sua vez, detectaria que ainda possuía a reserva em memória e procederia à criação dum novo caminho para a reserva.
Muitos outros erros podem ocorrer. Contudo, uma vez que tratando-se duma arquitectura que recorre ao uso de soft-timers, que garante a extinção das reservas, o principal problema a garantir traduz-se em assegurar a utilidade e bom funcionamento do protocolo no caso da reserva se extinguir.
O método que melhor se afigura para prosseguir tal intento, será desenvolver mecanismos de informação ao emissor da reserva para que este decida o que fazer.
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 58/113 Nuno Rafael Silva
Paulo Renato Silva