O comportamento do programa de simulação é definido pelo código associado ao módulo simples principal. Sempre que surge um acontecimento a primeira função a ser invocada é a função principal associada directamente a esse módulo, referida na Secção 5.2.1. Esta função tem por objectivo fazer o processamento do acontecimento, determinar o instante do próximo acontecimento e escaloná-lo. No OMNeT++ os acontecimentos são representados por mensagens.
Existem dois geradores principais e independentes de mensagens, um gera pedidos e o outro gera falhas. Tanto os pedidos como as falhas são gerados como processos de Poisson com valores de parâmetros introduzidos no ficheiro de configuração (ficheiro ini). Na fase de inicialização da simulação são geradas mensagens iniciais, uma geradora de pedidos e uma geradora de falhas.
Na fila de acontecimentos existe sempre uma mensagem geradora de pedidos e uma mensagem geradora de falhas. Existirão também em geral várias mensagens correspondentes a pedidos, tantas quantos os pedidos activos. Quando existir uma falha activa (no máximo pode existir uma, restrição que traduz o cenário de falha isolada subjacente aos algoritmos com partilha de LB) existirá ainda na fila de acontecimentos uma mensagem de falha. A Figura 5.1 ilustra um estado possível da fila de acontecimentos. Essa figura corresponde a um instante em que existem 6 pedidos no sistema (em estados não especificados na figura). Neste exemplo existe uma falha activa. A mensagem de falha apresentada na figura
Msg geradora de um pedido Msg geradora de uma falha Msg falha Msg pedido
t
Instante actual
Figura 5.1:Fila de acontecimentos futuros - um estado possível.
sinaliza o fim dessa falha.
Sempre que é invocada a função que faz o tratamento de mensagens é porque aconteceu uma das três situações seguintes:
1. Surgiu uma mensagem geradora (de um pedido ou de uma falha);
2. Surgiu uma mensagem associada a um pedido, que passamos a designar por mensagem pedido;
3. Surgiu uma mensagem associada a uma falha, que passamos a designar por mensagem falha.
Quando surge uma mensagem geradora de uma falha para ser tratada, vai ser gerada efectivamente uma nova instância de falha e escalonada de novo a men- sagem geradora de falha para o instante em que deve surgir a falha seguinte. Na geração da nova falha começa por ser determinado o ramo, de entre os vários da rede, que será afectado pela falha. Considerou-se que todos os ramos possuem a mesma probabilidade de falha (utilização de uma distribuição uniforme discreta). Na geração da falha é criada uma mensagem falha, à qual se associa informação relativa à mesma. Esta mensagem é escalonada para o instante actual da simu- lação. Quando ela for recebida pela função de tratamento de mensagens será verificado que se trata do início de uma falha. Nesta situação várias acções serão realizadas: O ramo afectado pela falha será marcado como desactivado; serão identificados todos os pedidos afectados pela falha (sendo construído um vector com todas as mensagens associadas a esses pedidos) e será alterado o estado desses pedidos para o sub-estado SP_EM_FALHA (como será referido adiante a cada pedido activo está associada uma máquina de estados); todas as mensagens dos pedidos afectados pela falha serão escalonadas para o instante actual da si- mulação; por último a mensagem falha será escalonada para o instante em que a falha for recuperada.
Comportamento similar vai ser desencadeado quando surge uma mensagem geradora de um pedido para ser tratada. De modo análogo, vai ser gerado uma nova instância de pedido e escalonada a mensagem geradora de um pedido para
o instante em que deve surgir o pedido seguinte. A geração do novo pedido en- volve a determinação do nó origem e destino, a determinação da LB e a determi- nação do CT do pedido. A escolha do nó origem e do nó destino é feita através de uma distribuição uniforme discreta, considerando-se todos os nós com a mesma probabilidade de serem escolhidos (à semelhança do realizado em Calle et al., 2004; Kodialam e Lakshman, 2002b; Qiao e Xu, 2002; Xiong et al., 2003). Também foi utilizada uma distribuição uniforme discreta na determinação da LB (de entre os valores {1, 2, . . . , bw.}). Actualmente a determinação do CT está a ser efectu- ada pela aplicação do método de Monte Carlo tendo por base as proporções do BCM utilizado. A geração do novo pedido envolve também a atribuição de uma máquina de estados ao pedido e a criação de uma mensagem pedido (à qual é associada uma estrutura que armazena informação relativa ao pedido). Esta mensagem é escalonada para o instante actual da simulação. Posteriormente, a mensagem será sucessivamente escalonada aquando da saída dos vários estados estacionários da máquina de estados associada ao pedido.
Foi necessário definir uma máquina de estados para controlar as transições en- tre os vários estados dos pedidos. Cada pedido está sempre num determinado estado. Os estados podem ser estados estacionários ou transitórios. A diferença entre estes é que a transição entre estados transitórios se faz automaticamente sem passagem de tempo (e sem consultar a fila de acontecimentos) enquanto que um pedido num estado estacionário devolve o controlo ao simulador (que consulta a fila de acontecimentos e pode levar a passagem de tempo). Um acon- tecimento num pedido (mensagem pedido) faz passar o pedido para o próximo estado de acordo com a máquina de estados. O pedido sai do estado estacionário corrente, percorre um ou mais estados transitórios, e finalmente chega a um novo estado estacionário. Cada estado possui código que será executados quando se sai dele e pode também possuir código para ser executado quando se entra no estado. No estado FIM_PEDIDO o pedido é libertado.
A Figura 5.2 apresenta o diagrama de fluxo da máquina de estados. São vi- síveis na figura os vários estados (21 no total, incluindo estacionários e transi- tórios) em que um pedido se pode encontrar. Actualmente o único estado em que ocorre passagem de tempo é o estado S_EM_PROGRESSO, embora tenham sido definidos outros estados estacionários (estados em que poderá também ser gasto tempo). Outros estados em que se pretenda considerar passagem de tempo devem ser convertidos de transitórios para estacionários. Em parte a complexi- dade da máquina de estados resultou de se pretender que fosse adequada não só na simulação ao fluxo mas também na simulação ao pacote (e neste último caso permitir o funcionamento adequado do RSVP).
S_TABELA_A S_TABELA_B T_DETERMINA_CAMINHOS T_ESTABREG_CAMINHOS S_VERIF_ESTAB_CAMINHOS T_TESTA_TODOS_VERIF T_EM_PROGRESSO T_REMOVREG_CAMINHOS S_TABELA_O S_TABELA_F T_PASSA_A_USAR_RP T_DETERMINA_RP T_REMOVREG_CAMINHOS_NA_FALHA [Encontrou caminhos viáveis]
[Não encontrou caminhos viáveis]
[Todos reservados] [Alguma reserva por definir]
[Alguma falha na reserva]
[Falha Recuperada] [Falha] [Optimização] [Fim do pedido] [Determina novo RP] [Existe RP] [Usa RP anteriormente determinado] [Possibilidade de
Novo Caminho Activo (com ou sem novo Esquema de Recuperação)] [Há LB disponível] T_PASSA_A_USAR_AP [Esquema Reversivel] S_TABELA_C T_PREPARA_NOVAS_RESERVAS [Quer reserva e RP novo] [Esquema Não Reversivel] [Caso contrário] S_TERMINOU_EM_FALHA [Falha no RP] [Não existe RP] S_EM_PROGRESSO [Não há LB disponível] T_PEDIDO_EM_REVERSAO
No início, cada pedido é colocado no estado INICIO_PEDIDO. Seguidamente, passará pelo grupo de estados S_TABELA_A, S_TABELA_B e T_DETERMINA_CA- MINHOS para escolha do esquema e com este do CA (e possivelmente do CR). De seguida, passa pelo estado S_TABELA_C, usado para permitir suporte de
esquemas híbridos, mas não definido na implementação actual. O pedido de
recursos e verificação das reservas é efectuado nos estados T_ESTABREG_CAMI- NHOS, T_TESTA_TODOS_VERIF e S_VERIF_ESTAB_CAMINHOS. Após isto, o pedido é considerado realmente estabelecido, o que é conseguido nos estados T_EM_PROGRESSO e S_EM_PROGRESSO. Se tudo prosseguir sem problemas o pedido ficará no último estado referido até expirar a sua duração. Após isto, será então mudado para os estados T_REMOVREG_CAMINHOS e FIM_PEDIDO para libertação de recursos usados e fim efectivo do pedido. Se durante a execu- ção do pedido ele for afectado por uma falha, passará para o estado S_TABELA_F (que executa a etapa responsável pela escolha de esquemas na falha). Daqui o pedido pode terminar por falha através do estado S_TERMINOU_EM_FALHA. Pode passar em vez disto por (alguns) estados como T_DETERMINA_RP (es- colha de um novo CR), T_PASSA_A_USAR_RP (utiliza na prática o CR) ou T_PREPARA_NOVAS_RESERVAS (efectua as reservas para o novo CR). Existe ainda a possibilidade de passar pelo estado T_REMOVREG_CAMINHOS_NA_FA- LHA se foi decidida a escolha de um novo CA. Após o término da falha o pedido pode passar aos estados T_PEDIDO_EM_REVERSAO e T_PASSA_A_USAR_AP usados no tratamento de esquemas reversivos. Um outro estado, S_TABELA_O, foi considerado para suportar optimização, mas não é usado na implementação actual. Existem ainda algumas transições entre estados não referidas, por exem- plo para suportar a terminação de pedidos que não foi conseguido estabelecer.
A Figura 5.3 ilustra o percurso de vários pedidos, desde o início do pedido - cri- ação, até ao fim do pedido - conclusão, passando por vários estados intermédios. São também apresentadas nessa figura várias mensagens geradoras de pedidos e uma mensagem geradora de uma falha (não são apresentadas as mensagens pedido nem as mensagens falha). Apesar de não ser uma representação à escala, é visível na figura que existe um grande período de passagem de tempo que corresponde ao intervalo em que o pedido está em progresso. Na realidade na implementação actual, como será referido à frente, o estado S_EM_PROGRESSO é mesmo o único em que existe passagem do tempo simulado. Na figura, ape- nas o Pedido 2 foi afectado pela falha. Este pedido começa por ter um período
em progresso, após o que é afectado por uma falha (instante t4), recupera desta
e passa ao segundo período em progresso. Posteriormente, a falha é eliminada
Msgs geradoras de pedidos Msgs geradoras de falhas t t1 t2 t3 t4 t5 Pedido 1 Pedido 4 Pedido 3 Pedido 2 t6
Figura 5.3:O percurso de quatro pedidos.
representada na figura) e o pedido regressa ao caminho original, terceiro período em progresso.
Foi referida nesta secção a utilização da distribuição uniforme discreta na es- colha da origem e destino do pedido, da LB do pedido, do ramo afectado por uma falha e a utilização do método de Monte Carlo na determinação do CT. Para utilizar outras distribuições ou outros parâmetros das distribuições, que se considerem mais adequados ao sistema que se pretenda simular, a alteração do código não seria difícil, mas a determinação das distribuições e parâmetros mais adequados à rede em causa envolveria a necessidade de um estudo adicional.