Estruturas para recolha de dados e estruturas auxiliares

As três estruturas principais implementadas para a obtenção e registo das estatís- ticas são MBStatBase, a sua derivada KodStats e a classe KStatsGenerico de- rivada desta última. A classe MBStatBase define apenas funções virtuais puras, tendo apenas função de interface para as classes derivadas. A classe KodStats

implementa quase todas as funções de MBStatBase, excepto duas, que são im- plementadas pela classe KStatsGenerico. O objecto ModuloBaseTabelas pos- sui um ponteiro para MBStatBase, mas como a esse ponteiro é atribuída uma instância de KStatsGenerico, quando ModuloBaseTabelas invoca uma função a que é executada é a de KStatsGenerico, ou a de KodStats no caso de não ter sido redefinida em KStatsGenerico (polimorfismo).

Para obtenção das estatísticas escalares foram necessários os objectos auxiliares TimedValue, TimedValueCL e VecTimeValueCL. TimedValue é um objecto es- tatístico que permite calcular valores correspondentes à média de uma medida, ponderada pelos intervalos de tempo que decorrem entre as recolhas de cada va- lor dessa medida. TimedValueCL é um vector de objectos TimedValue em que é guardado um valor da medida por CT e um valor correspondente ao agregado dos CT. Desta forma o número de elementos do vector TimedValueCL é igual ao número de CT mais um. Finalmente, VecTimeValueCL é um vector de objectos TimedValueCL, geralmente com tantos elementos quantos os ramos da rede. Na prática este vector é utilizado para armazenar medidas por ramo da rede ou por esquema de recuperação.

O registo das estatísticas vectoriais implicou a definição do objecto auxiliar OutVec, derivado do objecto cOutVector da biblioteca de classes do OMNeT++, e que permite o registo de valores através da função membro record de cOut- Vector.

Vários métodos da classe KodStats são responsáveis por registar no ficheiro de saídas vectoriais atributos do tipo OutVec, recorrendo à função regista, ou responsáveis por coligir valores dos atributos escalares, dos tipos TimedValue, TimedValueCL ou VecTimeValueCL, que no final da simulação serão registado no ficheiro de saídas escalares. A classe auxiliar largBandaStats foi também usada para registar valores estatísticos relativos à alteração da ocupação de LB.

Suporte para reservas, ocupações e múltiplos BCM

A informação da rede que deverá ser partilhada por todos os esquemas de re- cuperação e restante código é armazenada na classe InformacaoRede ou em instâncias de outras classes que podem ser acedidas através desta. Esta informa- ção inclui a topologia (carregada aquando do início da simulação) e as ocupações efectivas de cada ramo em cada instante. Estas informações são armazenadas di- rectamente em especializações do ModeloRestricaoLarguraBanda, mas tam- bém são agregadas em estruturas de dados específicas de alguns esquemas, como Delta_IJ_UV.

As ocupações dos ramos da rede são mediadas por um BCM. Estes foram implementados através de especializações da classe ModeloRestricaoLargu-

raBanda, designadas MRLB_MAM e MRLB_MAR. Estes tratam de armazenar

e gerir informação sobre as ocupações de cada ramo considerando as restrições associadas a cada CT. Permitem também receber informação sobre a disponibili- dade actual de LB em cada CT de acordo com essas restrições (e de acordo com as reservas RSVP activas).

A classe ReservaRSVP corresponde a uma implementação simplificada do RSVP. Implementa as funções associadas a reservas de caminhos simples (Reser-

vaCaminhoActivoUniforme, ReservaCaminhoRecuperacaoUniforme, liber-

taCaminhoActivoUniforme e libertaCaminhoRecuperacaoUniforme) e as

associadas às reservas de conjuntos de ramos não uniformes – necessários para suportar partilha de LB de protecção (reservaCaminhoRecuperacaoNaoUni-

forme e libertaCaminhoRecuperacaoNaoUniforme). Além destas funções

existem também funções auxiliares para obter o número de reservas RSVP ten- tadas, conseguidas e falhadas. Na implementação actual em geral todas as re- servas RSVP tentadas são conseguidas, uma vez que os esquemas verificam a ocupação/reserva antes de tentar fazer novas reservas, e que não há passagem de tempo entre as reservas dos vários ramos de um caminho.

As reservas possuem uma identificação, através da qual é possível saber em que ramos foi feita reserva e de que valor. A função ReservaCaminhoActivoU-

niforme permite fazer a reserva para o CA. Neste caso os ramos a reservar

formam um caminho (o nó em que um ramo termina é o início do ramo seguinte do caminho) e a LB necessária é a mesma em todos os ramos (tratando-se de uma reserva bastante simples). A função ReservaCaminhoActivoUniforme chama a função reservaCaminhoU que por sua vez irá utilizar o BCM para fazer a re- serva efectiva da LB (ocorre alteração das estruturas de informação do BCM, no respeitante ao CT em causa).

As reservas de LB associadas a CR que partilham LBP são geridas usando re- servas fictícias, uma vez que o valor a reservar por ramo pode ser diferente entre eles e os ramos a reservar podem não constituir um caminho. Estas questões são tratadas pelas reservas não uniformes. Para o conseguir, altera-se na prática um conjunto de reservas “reais” que já existem (uma por ramo) em função das modificações necessárias. É criada também uma nova reserva “fictícia” na qual são indicados todos os ramos efectivamente usados pelo caminho com um valor de LB zero (simplesmente para manter o registo de recursos usados). Para além de muitas reservas “fictícias” podem existir vários conjuntos de reservas “reais” simultaneamente, a cada um dos quais corresponde uma assinatura. Esta situa-

ção ocorre quando tivermos simultaneamente vários esquemas que precisem de fazer reservas não uniformes que são manipuladas independentemente. Estas reservas complexas são criadas pelo método reservaCaminhoRecuperacaoNa-

oUniforme.

As funções de libertação de recursos podem simplesmente libertar a LB em ca- minhos uniformes anteriormente reservados (libertaCaminhoActivoUniforme,

libertaCaminhoRecuperacaoUniforme). Pode também ser necessário liber-

tar reservas não uniformes (é o caso de libertaCaminhoRecuperacaoNaoU-

niforme) e nesse caso as variações a fazer nas reservas devem ser calculadas

previamente, fora da função, uma vez que não podem geralmente ser inferidas das reservas anteriores.