A primeira tarefa a levar a cabo no âmbito deste o processo consiste em verificar que se o mesmo foi lançado como super-user, uma vez que certas funções implicam privilégios de root.
Seguidamente, deve-se modificar a prioridade do processo, pois assim verifica-se uma melhoria substancial no rápido funcionamento do processo e consequentemente uma diminuição das perdas de pacotes (por saturação dos buffers de entrada).
Para que seja possibilitar um correcto funcionamento do processador de pacotes, deve-se, primeiramente, identificar as interfaces disponíveis na máquina e correspondentes endereços IP e, posteriormente, configurar a rotina de serviço ao sinal SIGALRM. Neste momento, o processo fica num modo “adormecido” à espera de receber uma mensagem a fim de a processar.
O processamento de pacotes baseia-se na identificação do pacote, através do tipo de pacote RSVP, contido no cabeçalho RSVP (ver tabela x). Para tal, é necessário averiguar se o pacote possui a opção Router_Alert activa a fim de destrinçar os pacotes SResvInit e SResvRefresh dos pacotes SResvStat e SResvTear. Todo o processo
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 40/113 Nuno Rafael Silva
Paulo Renato Silva seguinte fica, obviamente, dependente do tipo de pacote recebido.
No caso de se tratar de um pacote SResvInit inicia-se uma nova reserva, e aloca- se memória para os dados da reserva. Concomitantemente, é guardado o IP do router anterior, o label, bem como toda a informação relativa às necessidades de recursos da reserva.
Seguidamente é alterado o valor do label_setup e do RSVP_Hop e é feito o reenvio da mensagem para o router seguinte. Quando esta chegar ao seu destino final, é igualmente processada pelo router, como nos anteriores. No entanto, neste caso, não é feito o reenvio, mas antes o envio duma mensagem SResvStat para o router anterior.
Quando o processador de pacotes recebe uma mensagem de SresvRefresh, o trabalho de deamon consiste em verificar a existência do label como reserva, através da consulta do mapa de memória alocada. Posteriormente, este remove a reserva temporal do fifo respectivo e volta a coloca-la no final do fifo com o novo tempo de expiração.
Em caso de sucesso, é feito o reenvio do pacote para o router seguinte. Todavia, em caso de erro, é enviado para o router anterior uma mensagem SResvStat com o erro respectivo.
No caso de receber uma mensagem SResvStat o deamon verifica a validade do label através do mapa de memória alocada e identifica se se trata de uma mensagem de sucesso ou de erro, através do campo “error code”.
Em caso de sucesso o deamon procede à confirmação da reserva. Nesta situação, a reserva passa a ter disponíveis os recursos para o fluxo naquele router, sendo reenviada para o router seguinte, se necessário desde que anteriormente tenham sido alterados os valores do label, label_setup e RSVP_Hop.
No caso de ser uma mensagem de erro a reserva é eliminada, uma vez que não foi implementado o processamento de mudanças de rota. Se o label da mensagem não existir no mapa de memória alocada é enviada um SResvStat a reportar o respectivo erro.
Por último, no caso da mensagem recebida se tratar do tipo SResvTear é verificado a validade do label. Neste caso, a reserva temporal da memória é de igual modo removida
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 41/113 Nuno Rafael Silva
Paulo Renato Silva através do mapa de memória alocada. De seguida, toda a informação relativa à reserva é apagada, bem como alteradas as definições de controlo de tráfego. Se necessário, a este tipo de mensagem é reenviado para o router seguinte.
Por fim, procede-se a uma nova procura da próxima reserva a expirar e activa-se o alarme para a próxima reserva a expirar. De salientar, que o processador de pacotes desliga este alarme inicialmente para que a função de serviço ao SIGALRM nunca seja executada, evitar, assim, eventuais incongruências.
O socket usado para receber os pacotes é do tipo RAW, com filtro para mensagens RSVP e com a opção ROUTER_ALERT activa.
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 42/113 Nuno Rafael Silva
Paulo Renato Silva
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 43/113 Nuno Rafael Silva
Paulo Renato Silva
9.2 - Funcionamento do módulo de comunicação com a API
Este módulo, cujo fluxograma é representado pela figura 14, é lançado pelo programa principal como uma thread, o que, apesar do processamento paralelo, não afecta a performance do deamon, uma vez que, como supra referido, esta encontra-se maioritariamente num modo “adormecido”.
Este modelo usa sockets do tipo UNIX e fica à espera de informação vinda da API, e procedendo ao respectivo processamento da informação. Após receber essa informação, verifica o que fazer com ela: apagar a reserva, criar reserva GS ou criar reserva AF.
No caso de ser necessário criar uma reserva, é feito todo o procedimento de criação duma reserva, designadamente, reservar recursos o sistema, acrescentar à lista biligada toda a informação relativa à reserva, inserir o tempo de expiração na respectiva lista e enviar o pacote SResvInit. No final, o valor de label da reserva criada retorna à API.
O valor de label da reserva criada vai ser usado quando for necessário terminar a reserva. A API fica assim com a vantagem de informar o deamon que quer terminar, fornecendo, para tal, o label. Esta possibilidade beneficia o processamento do deamon dado que possibilita o acesso directo à memória alocada para a reserva.
O processo de apagar a reserva passa por retirar a reserva da tabela de tempo de expiração, apagar a informação sobre a reserva da lista biligada, alterar as definições de controlo de tráfego e enviar o pacote de SResvStat.
Se a operação for bem sucedida é retornado à API o valor 0. Deve-se, porém, antes de apagar a reserva, verificar, através do mapa de memória alocada, a validade do label pois este pode já não existir.
No final, a fim de evitar exclusão mútua, procede-se ao fecho do socket usado e programa-se a próxima reserva a expirar. Esta exclusão suceder visto que ambas as threads têm a possibilidade de aceder, em simultâneo, à memória global.
Este módulo tem de ser executado com o “mutex_lock”, para garantir exclusão mútua no acesso a regiões de memória críticas.
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 44/113 Nuno Rafael Silva
Paulo Renato Silva
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 45/113 Nuno Rafael Silva
Paulo Renato Silva
9.3 - Funcionamento da função manipuladora do SIGALRM
Esta rotina de serviço é executada sempre que o kernel active a interrupção SIGALARM.
Analisando o fluxograma da função, figura 15, podemos verificar que inicialmente, é levada a cabo uma procura em busca da próxima reserva a expirar. Caso a reserva tenha realmente expirado, este serviço cuida do seu tratamento. Caso não o efectue, o serviço programa o alarme para o seguinte tempo de expiração.
O processo de tratamento passa por verificar se a reserva é local, isto é, se a reserva teve como origem a máquina em questão. Neste caso, tem de verificar se a reserva já foi confirmada, visto que é infrutífero proceder ao refrescamento da reserva se esta não foi confirmada.
Em caso afirmativo, a reserva é removida da memória.
No caso da reserva ter sido confirmada efectua-se, então, o refrescamento da reserva, enviando-se, de seguida, o pacote SResvRefresh para o router seguinte, de acordo com a informação guardada e memória. Este processo repete-se até encontrar uma reserva que não tenha expirado.
É também exequível verificar a existência dum contador “número de vezes”.
No presente projecto, este contador foi implementado para evitar o congestionamento dos buffers de recepção com mensagens de refrescamento. De facto, tal pode ocorrer quando existem muitas reservas em memória com tempos de expiração num intervalo de 1 segundo. Conseguimos, assim, dividir as mensagens de refrescamento em grupos de 100 espaçadas de 10ms, o que solucionou o problema.
Contudo, entendemos que estes valores deveriam depender do número de reservas a refrescar e da capacidade de processamento dos próprios routers.
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 46/113 Nuno Rafael Silva
Paulo Renato Silva Procurar próxima reserva
Próxima reserva expirou? Numero vezes<100? A reserva não é local? A reserva foi confirmada?
Remover reserva não local Remover resrva local Refrescar reserva local
Enviar pacote SResvRefresh
Procurar próxima reserva
Incrementar número de vezes
Programar temporizador para próxima reserva Exit Não Não Não Não Sim Sim Sim Sim
Programar temporizador para 10ms
Start
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 47/113 Nuno Rafael Silva
Paulo Renato Silva
9.4 - Funcionamento dos blocos principais
Alguns dos blocos representados nos fluxogramas anteriores (figuras 13 a 15) deveram ser melhor explicados, pois o seu funcionamento não pode ser explicado visualmente.
9.4.1 - Instalação do signal de controlo do SIGALRM
Este bloco simplesmente programa a chamada da função “sig_alarm (int)” por parte do alarme do kernel, a fim de se proceder ao racionamento das expirações de reservas.
Este inicia com a procura da reserva a expirar. De seguida, identifica o que fazer (remover reserva ou refrescar reserva) e programa o alarme para a próxima reserva (vide diagrama de blocos para a função manipuladora do SIGALRM).
9.4.2 - Receber pacote
Este bloco é bloqueante, ou seja, enquanto não receber nenhum pacote está no modo adormecido (sleep), por isso não influencia o desempenho do deamon. Este recorre ao uso de sockets do tipo raw e verifica se o tamanho do pacote recebido corresponde ao tamanho do campo length do cabeçalho IP.
9.4.3 - Criar reserva
Para criar uma reserva é necessário reservar espaço em memória para a informação relativa à reserva, e colocar na lista bi-ligada circular de reservas.
O tipo de reserva é colocado com “-1” ou “-2” para representar que a reserva não foi confirmada. Ao mesmo tempo, é alterado o mapa de bits de memória alocada, para uso da função “Verify_label (union rsvdata*);”, e guardada toda a informação conhecida até ao momento da reserva: label, label na máquina anterior, tos, port, rex, endereço IP na máquina anterior, endereço IP na própria máquina, e as características da reserva.
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 48/113 Nuno Rafael Silva
Paulo Renato Silva 9.4.4 - Criar reserva temporal
Neste bloco é colocado, numa lista de tempos, o tempo no qual a reserva vai expirar, segundo o rex especificado para a reserva. Esta lista é, de facto, um array com 8 ponteiros, em que cada ponteiro associa-se para cada valor de rex possível. Por sua vez, cada fila de tempos encontra-se ordenada, estando no topo a próxima reserva a expirar (“First-In First-Out”). Deste modo, facilita-se o processo de procura da próxima reserva a expirar e, ao mesmo tempo, diminui-se o peso computacional.
9.4.5 - Confirmar reserva
Aqui a reserva é confirmada, ou seja, o tipo de reserva passa de “-1” ou “-2” para “1” ou “2” respectivamente.
O “1” corresponde a uma reserva do tipo serviço garantido (GS) e o “2” o envio assegurado (AF).
9.4.6 - Programar próxima reserva
Este bloco é fundamental visto que ocorre num momento em que já ocorreu uma das seguintes operações: criação de nova reserva, eliminação de uma reserva ou refrescamento de uma reserva.
Posto isto, torna-se necessário:
Averiguar quais as listas de tempos que expiraram;
Averiguar quais as listas de tempos que sofreram alterações; Procurar a próxima reserva;
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 49/113 Nuno Rafael Silva
Paulo Renato Silva 9.4.7 - Label válido?
Este bloco é condicional visto que depende da existência do label como reserva na máquina em questão. Para averiguar a existência do mesmo, deve-se consultar um mapa de bits de memória alocada, e consoante o resultado retornar um valor boleano.
9.4.8 - IP destino pertence a esta máquina?
Este bloco é igualmente um bloco condicional uma vez que serve para verificar se a reserva tem como destino final a máquina em questão.
O seu funcionamento depende do tipo de pacote e recorre a informação contida no próprio pacote quer nos dados em memória.
Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia
Página 50/113 Nuno Rafael Silva
Paulo Renato Silva