F
ACULDADE DE
E
NGENHARIA
E
LÉTRICA E DE
C
OMPUTAÇÃO
D
EPARTAMENTO DE
C
OMUNICAÇÕES
Caixa Postal 6101, CEP 13083-970 Campinas - SP. Telefones: (019) 3788-8324, Fax: (019) 3289-1395
Ambiente de Simulação de Redes a Eventos
Discretos
Dissertação de Doutorado apresentada à Faculdade de Engenharia Elétrica da Universidade Estadual de Campinas, Departamento de Comunicações, como parte dos requisitos exigidos para a obtenção do título de
Doutor em Engenharia Elétrica.
Autor
Ernesto Luiz Andrade Neto
Mestre em Engenharia Elétrica pela UNICAMP em 1997 Engenheiro Eletricista pela UFSM em 1995
Orientador
Prof. Dr. Leonardo de Souza Mendes
PhD em Engenharia Elétrica pela Syracuse University em 1992 Banca Examinadora
Prof. Dr. – Dalton Soares Arantes - FEEC/UNICAMP Prof. Dr. – Max Henrique Machado Costa - FEEC/UNICAMP
Prof. Dr. – Maurício Ferreira Magalhães - FEEC/UNICAMP Prof. Dr. – Shusaburo Motoyama - FEEC/UNICAMP
Prof. Dr. – João César Moura Mota – UFCE Prof. Dr. – Rubens Nascimento Melo – PUC-RJ
FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA DA ÁREA DE ENGENHARIA - BAE - UNICAMP
An24a
Andrade Neto, Ernesto Luiz
Ambiente de simulação de redes a eventos discretos / Ernesto Luiz Andrade Neto. --Campinas, SP: [s.n.], 2001.
Orientador: Leonardo de Souza Mendes. Tese (doutorado) - Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de Computação.
1. Sistemas de telecomunicação – Simulação por computador. 2. Telecomunicações – Tráfego – Modelos matemáticos. 3. Redes de computação – Modelos matemáticos. I. Mendes, Leonardo de Souza. II. Universidade Estadual de Campinas. Faculdade de Engenharia Elétrica e de Computação. III. Título.
Resumo
Neste trabalho apresentamos o Hydragyrum, uma ferramenta para a simulação, projeto e ensino de sistemas de comunicação. O Hydragyrum é um aplicativo que fornece recursos para o desenvolvimento de novos modelos de elementos de um sistema de comunicação. O Hydragyrum possui uma estrutura modular composta de núcleo de processamento (Kernel), modelos e interfaces que permitem a fácil expansão do conjunto de modelos. O sistema de comunicação é interpretado como um conjunto de blocos interligados que podem agendar e trocar eventos entre si para realizar a simulação. O desenvolvimento da ferramenta foi direcionado tanto para a aplicação profissional, em empresas envolvidas com projeto de sistemas de comunicação, como para aplicação educacional, em cursos destinados a educação à distância e auto-aprendizado, dada a facilidade de uso do ambiente gráfico para o qual a ferramenta é projetada. Na modelagem de tráfego são apresentados um modelo original de tráfego autossimilar e um modelo de tráfego multifractal. São desenvolvidos modelos de elementos de rede ATM que permitem a simulação de diferentes aspectos do desempenho da tecnologia das redes ATM para transporte de dados, gerenciamento do tráfego e dimensionamento da rede.
Abstract
This work presents Hydragyrum, a tool for the simulation, design and teaching of communication systems. Hydragyrum is an application that allows the development of new communication system element models. Hydragyrum has a modular structure composed of processing nucleus (Kernel), models and interfaces that allow easy model set extension. The communication system is interpreted as a set of interconnected blocks that schedule and exchange events to accomplish the simulation. The tool development aimed at professional application, in companies involved with communication system project, as well as, at educational use, for distance learning courses and self-learning, due to the ease of use of the graphic environment in which the tool was built. In traffic modeling a new self-similar model and a multifractal traffic model are presented. ATM network models are developed allowing the simulation of several aspects of an ATM network performance, such as, data transport, traffic management and network dimensioning.
Agradecimentos
Este foi um trabalho gratificante e profícuo e agradeço ao meu orientador, Leonardo de Souza Mendes, pela oportunidade de realizá-lo e por todo o apoio dado no transcorrer do trabalho.
Agradeço aos meus pais Ernesto Rubens de Amorim Andrade e Ruth Feijó Andrade todo apoio e compreensão durante todos estes anos de estudo e aprimoramento aos quais me dediquei e que sem sua compreensão e encorajamento não teriam sido possíveis.
Agradeço aos meus irmãos os laços de apoio e compreensão pelos quais estamos ligados e que nos fazem ir em frente e querer sempre mais. Tentando sempre extrair o que temos de melhor em nós e nunca nos deixando esmorecer.
Agradeço aos meus avós (in memoriam) Acelino Feijó e Esther Rushinski Feijó o apoio e incentivo que sempre me deram até o fim de suas vidas.
Agradeço a Flávia de Lima Alves, minha namorada, a paciência, amor e compreensão dada aos momentos que envolveram a realização deste trabalho.
Agradeço aos membros da comissão julgadora a aceitação do convite para participar da avaliação deste trabalho.
Gostaria também de agradecer a todos os colegas que participaram com discussões e contribuições durante todos estes anos de convivência na pós-graduação.
Agradeço a FAPESP o suporte financeiro e os recursos de infra-estrutura sem os quais este trabalho não poderia ter sido realizado.
“
Only the subject's individual consciousness can testify for the
unwitnessed acts, and there is no act more deprived of external testimony
than the act of knowing
.”Publicações
“Estimativa de Descritores de Tráfego MPEG-4 para o Transporte em Redes ATM Utilizando a Técnica do Buffer Virtual”, Antônio M. Alberti, Ernesto L. A. Neto, Leonardo de S. Mendes, VIII Simpósio da Sociedade Brasileira de Telecomunicações, setembro de 2001, Fortaleza, CE.
“Aplicação de Modelos de Multifractais na Simulação de Redes ATM”, Andrade, E.L., Alberti, A. M., Mendes, L. S., XVIII Simpósio da Sociedade Brasileira de Telecomunicações, setembro de 2000, Gramado, RS.
“Hydragyrum Ambiente de Simulação de Redes a Eventos Discretos”, Andrade, E.L., Alberti, A. M., Mendes, L. S., XVIII Simpósio da Sociedade Brasileira de Telecomunicações, setembro de 2000, Gramado, RS.
“Simulação de Redes ATM no Nível de Células”, Alberti, A. M., Andrade, E.L., Mendes, L. S., XVIII Simpósio da Sociedade Brasileira de Telecomunicações, setembro de 2000, Gramado, RS.
“Simulação de Redes ATM”, Alberti, A. M., Andrade, E.L., Mendes, L. S., XVII Simpósio da Sociedade Brasileira de Telecomunicações, setembro de 1999, Vitória, ES.
“A Realistic Model for Self-similar Ethernet Lan Traffic In SimAtm - an Network Simulator: Design And Performance Implications”, Andrade, E. L., Alberti, A. M., Arantes, D. S., Mendes, L. S., SBT-IEEE/International Telecommunications Symposium, August 10, 1998, São Paulo, SP, Brazil.
“SimATM: An ATM Network Simulation Environment”, E.L. Andrade, A. M. Alberti, L.S. Mendes, IEEE/Computer Aided Modelling and Design (CAMAD) Workshop, August 13, 1998, São Paulo, SP, Brazil, trabalho convidado.
Glossário
ABR - Available Bit Rate ALL - ATM Adaptation Layer ATM - Asynchronous Transfer Mode BTE - Broadband Terminal Equipment CAC - Connection Admission Control CAD - Computer Aided Design CAE - Computer Aided Engineering CBQ - Class Based Queuing
CBR - Constant Bit Rate CLR - Cell Loss Ratio DC - Data Connection DLL - Dynamic Link Library EPD - Early Packet Discard fGn - Fractional Gaussian Noise GFR - Guaranteed Flow Rate
GPS - Generalized Processor Sharing H - Hurst Parameter
IP - Internet Protocol
ISSO - International Standards Organization ITU-T - International Telecommunication Union LAN - Local Area Network
MCTD - Maximum Cell Transfer Delay MWM -Multifractal Wavelet Model NC - Network Connection
NIST - National Institute of Standards OSI - Open Systems Integration PPD - Partial Packet Discard QoS - Quality of Service RED - Random Early Discard STL - Standard Template Library
TCP - Transmission Control Protocol UBR - Unspecific Bit Rate
VBR - Variable Bit Rate VC - Virtual Channel
Introdução
O cenário atual das telecomunicações apresenta uma rápida evolução, com tecnologias surgindo e sendo modificadas em períodos de tempo muito curtos. Neste cenário extremamente dinâmico, são necessárias ferramentas flexíveis para poder tratar de forma rápida e eficiente com as modificações que surgem nas diferentes tecnologias de telecomunicação. Uma das soluções empregadas para resolver o problema de acompanhar e manter a evolução das tecnologias de redes de comunicação são as ferramentas de projeto auxiliado por computador (CAD/CAE – ComputerAided Design/ Computer Aided Engineering). Uma outra forma de acompanhar a evolução
tecnológica das telecomunicações, está na implantação de redes de teste para a investigação de uma determinada tecnologia. Comparando-se as duas abordagens observamos que as redes de teste são necessárias para a validação e estudo do comportamento de uma nova tecnologia de rede. Entretanto, nem todas instituições e centros de pesquisa podem arcar com os custos de implantação de uma rede de testes. Assim, o CAD/CAE vem ganhando terreno como solução para a representação do comportamento das tecnologias de telecomunicação. O CAD/CAE é uma das formas mais eficientes de avaliar o impacto de uma nova tecnologia de rede de comunicação. A grande flexibilidade fornecida por estas ferramentas faz com que elas sejam fundamentais para a pesquisa de novas tecnologias em telecomunicações. Elas também permitem o teste de alterações na estrutura da rede de comunicação analisada de forma simplificada e com baixo custo, além de permitirem a avaliação, de forma eficiente, do desempenho das redes de comunicação existentes.
Outra forte razão para adotarmos a abordagem de CAD/CAE na representação de sistemas de comunicação é a larga disponibilidade de computadores cada vez mais potentes para tratar com problemas de simulação. Máquinas como computadores pessoais podem realizar tarefas relevantes na simulação de redes de comunicação e estão à disposição de engenheiros e projetistas de sistemas de comunicação em suas próprias mesas de trabalho. Portanto, ferramentas de CAD/CAE podem ser projetadas para aproveitar a capacidade computacional ociosa que repousa hoje sobre nossas mesas de trabalho e tende a se avolumar com o passar do tempo.
Neste trabalho apresentamos, um ambiente de simulação de redes de comunicação baseado no conceito de CAD/CAE com o princípio de orientação a simulação de eventos discretos o qual decidimos dar o nome de Hydragyrum.
Alguns dos principais recursos disponíveis no Hydragyrum são:
• Biblioteca de modelos expansível - o usuário pode desenvolver seus próprios modelos; • Linguagem de simulação - o Hydragyrum utiliza uma linguagem que é interpretada pelo
simulador, o que permite grande flexibilidade na simulação;
• Duas interfaces - uma interface gráfica amigável e uma interface de linha de comando, para execução de roteiros de simulação;
• Configuração de conexões - permite o estabelecimento de uma hierarquia de conexões em um sistema simulado;
• Automatização da simulação de diferentes cenários de rede - a interface de linha de comando permite a execução de diferentes cenários de simulação com variações de parâmetros e topologia para cada simulação.
Histórico da Evolução do Ambiente de Simulação
A evolução do ambiente de simulação Hydragyrum está baseada no desenvolvimento de outros softwares de simulação em nosso grupo de pesquisa. A primeira ferramenta de CAD/CAE desenvolvida por nosso grupo foi o ambiente de simulação de enlaces ópticos SimNT [1]. O SimNT, atualmente, é um ambiente de simulação de sistemas de comunicação [2] que emprega a técnica de simulação data-driven. Na técnica data-driven, vetores de sinal são gerados e trocados entre os modelos. O processamento de vetores de sinais possui analogia direta com o processamento digital de sinais. Portanto, esta técnica é mais bem aplicada à simulação de sistemas como enlaces ópticos e enlaces de rádio, onde geralmente se pode trabalhar com amostras de sinais no tempo.
Em 1996, já com dois anos de andamento do projeto do SimNT (a partir de 1996 o SimNT tornou-se o projeto FAPESP n0 95/4714-8), surgiu à necessidade de ampliar o comportamento dos modelos e do ambiente de simulação de forma a incorporar outros áreas de simulação de interesse do nosso grupo de pesquisa, como a simulação de redes de alta velocidade. Para tanto, foi tomado como meta para o desenvolvimento do novo simulador a simulação de redes ATM. A base inicial do desenvolvimento foi à implementação do simulador de redes ATM do NIST [3]. Assim surgiu o projeto do SimATM – Simulador de Redes ATM, desenvolvido em 1996. A primeira versão do
SimATM (V0.61) foi concluída no final de 1997 [4]. Esta primeira versão operava apenas com uma interface de linha de comando e não possuía uma arquitetura modular e expansível para a definição de novos modelos como a que o SimNT possuía na época.
Em 1997, com a proposta original deste trabalho iniciamos o desenvolvimento de um ambiente de simulação de redes que seria modular e expansível, permitindo a adição de novos modelos por meio de DLLs sem recompilação do Kernel e com uma interface gráfica de interação com o usuário. As idéias e os conceitos do SimNT foram amplamente empregados no desenvolvimento da nova versão do SimATM (v0.8), que começou em maio de 1997 e terminou em novembro de 1998, contando já com todos os elementos desejados (apesar de ter uma interface gráfica um tanto simplificada). Em 1999, a interface gráfica e o Kernel do SimATM (V0.8) foram aprimoradas utilizando-se uma série de modelos simplificados de elementos de rede ATM, que se basearam nos modelos desenvolvidos em [4]. Em setembro de 1999, com os testes da versão 0.8 do SimATM concluídos, resolvemos denominar o kernel e a interface gráfica que compõe o ambiente de simulação de Hydragyrum – Ambiente de Simulação de Redes, para ressaltar o caráter genérico do ambiente como um ambiente de simulação de redes a eventos discretos (event-driven). No estágio atual, a simulação de redes ATM, ainda é o enfoque do desenvolvimento de modelos para o ambiente de simulação. Contudo, devido a modularidade e a expansibilidade do ambiente de simulação as redes ATM são na realidade um conjunto de modelos inseridos na arquitetura do ambiente de simulação. O Hydragyrum pode ser expandido para englobar outros modelos de rede e técnicas de simulação, sem alterações no Kernel do simulador. Para tanto apenas é necessário a criação de um novo conjunto de modelos com as características desejadas.
Contribuições
Este trabalho fornece um ambiente de simulação modular e expansível, que permite a simulação de diferentes tecnologias de redes de comunicação de forma integrada e flexível. São desenvolvidos modelos de elementos de rede ATM que permitem a simulação de diferentes aspectos da tecnologia das redes ATM para transporte de dados, gerenciamento do tráfego e dimensionamento da rede. Dentro da modelagem de fontes de tráfego é apresentado um modelo original de fonte de tráfego autossimilar para facilitar a geração do tráfego agregado de dados em uma rede de comunicação, melhorando o tratamento da simulação.
Conteúdo do Trabalho
Este trabalho está dividido em 7 capítulos e 5 apêndices.
No primeiro capítulo, discutimos sobre simulação e sobre as técnicas de simulação existentes atualmente que podem ser empregadas na construção de sistemas CAD/CAE.
No segundo capítulo, descrevemos a estrutura do ambiente de simulação mostrando seus componentes e os principais conceitos empregados em seu desenvolvimento.
No terceiro capítulo, descrevemos a interface gráfica do ambiente de simulação, detalhando a interação do usuário com a interface gráfica.
No quarto capítulo, apresentamos os conjuntos de modelos desenvolvidos para a simulação de redes ATM mostrando os modelos e suas aplicações.
No quinto capítulo, detalhamos os modelos de tráfego autossimilar desenvolvidos para o ambiente de simulação.
No sexto capítulo, mostramos os resultados obtidos com o ambiente de simulação para a simulação de topologias de rede de comunicação.
No sétimo capítulo, são apresentadas as conclusões sobre o trabalho e as considerações sobre novos rumos a serem tomados na construção de ferramentas de simulação e na simulação de sistemas de comunicação.
No Apêndice A, é descrita a linguagem de comandos do ambiente de simulação.
No Apêndice B, são apresentados os recursos de programação do ambiente de simulação. No Apêndice C, detalhamos o processo de criação de modelos para o ambiente de simulação, onde observamos as regras para a construção de modelos.
No Apêndice D, é mostrado um exemplo de construção de conjunto de modelos.
No Apêndice E, são apresentados detalhes sobre os parâmetros dos modelos empregados para a simulação de tráfego de células em redes ATM.
Capítulo 1
1 Simulação de Sistemas de Comunicação
1.1
Introdução
O objetivo principal deste trabalho é a simulação de redes de comunicação. Entretanto, é interessante analisarmos outros aspectos do cenário de simulação de sistemas, antes de nos aprofundarmos no detalhamento da estrutura e funcionamento do ambiente de simulação. Assim, poderemos situar o problema da simulação de redes de comunicação, dentro de um contexto mais amplo. Neste capítulo apresentaremos a descrição dos principais conceitos e técnicas de simulação. Serão também apresentadas outras ferramentas de simulação de redes de comunicação, algumas comerciais, outras de domínio público. Com a análise das diversas soluções propostas para a simulação de redes de comunicações poderemos apreciar a evolução e colocação do ambiente de simulação de redes Hydragyrum dentro do contexto dos softwares para simulação de redes de comunicação.
1.2
Técnicas de Simulação
As diversas técnicas de simulação podem ser classificadas de acordo com o método de processamento da informação utilizado. As principais técnicas empregadas na simulação de sistemas de comunicação são: 1) simulação orientada a tempo (time-driven); 2) simulação orientada a fluxo de dados (dataflow ou data-driven); e 3) simulação orientada a eventos (discrete event ou
event-driven).
1.2.1
Simulação Orientada a Tempo (Time-Driven)
Os modelos na simulação time-driven são chamados para realizar suas operações a cada intervalo de tempo discreto de um relógio de simulação. O tempo global é atualizado de um incremento de tempo constante e todos os blocos no modelo são ativados em um instante de tempo para atualizarem seus estados internos com o valor atual do tempo global. O incremento do relógio
de tempo global da simulação time-driven ocorre independentemente da necessidade dos modelos de atualizarem seu estado interno entre um incremento e outro do relógio. Este método é computacionalmente ineficiente, pois emprega uma granularidade de relógio uniforme em todo o sistema que está sendo simulado. Assim, se existe uma diferença muito grande entre as ordens de grandeza das escalas de tempo dos processos envolvidos na simulação, os processos mais lentos terão sua taxa de atualização determinada pela escala de tempo do processo mais rápido, que determinará o incremento mínimo do relógio.
Uma das maneiras de contornar a ineficiência da simulação time-driven é o emprego de incrementos de relógio variáveis. Neste caso, cada modelo é atualizado a uma taxa maior ou menor dependendo da dinâmica do processo caracterizado pelo modelo. Nos pontos onde modelos com taxas de atualização diferente se conectam é necessário fazer uma conversão para equalizar as taxas. Apesar de o método de simulação time-driven poder ser empregado para a simulação de tráfego em redes de comunicação, seu emprego mais direto é na simulação de sinais em sistemas e em sistemas multi-taxas, que são caracterizados por equações diferenciais. O software Simulink [5] emprega a técnica de simulação time-driven com passos de incrementos variáveis para realizar suas simulações.
1.2.2
Simulação Orientada a Fluxo de Dados (Data-Driven)
Na simulação data-driven a ordenação da seqüência de ativação dos modelos é realizada antes da execução. Os modelos, durante a simulação, trocam vetores de dados que podem representar, por exemplo, o conjunto de amostras de um sinal digitalizado. Um modelo na simulação data-driven é acionado quando todos os dados necessários para a execução do modelo estão disponíveis. Os elementos que são executados em primeiro lugar são as fontes de dados, pois não dependem dos dados de nenhum outro modelo para realizar suas operações. Os modelos que recebem dados de outros modelos são executados em ordem de dependência. Um modelo que dependa de dados gerados por outros modelos só pode ser executado depois de todos os modelos, dos quais ele depende, terem sido executados. A relação de dependência entre os modelos é definida pelo comportamento dos modelos e por suas conexões dentro da topologia de um sistema simulado. Esta relação de dependência estabelece o fluxo da informação dentro da simulação. A técnica data-driven é empregada, por exemplo, em simuladores utilizados para a simulação de sistemas ópticos como o SimNT [2] e o Ptolemy [6].
1.2.3
Simulação Orientada a Eventos (Event-Driven)
Na simulação event-driven, os modelos agendam eventos para serem executados em um determinado instante de tempo simulado. Os modelos são ativados apenas quando recebem eventos para processar. Os eventos a serem executados são ordenados em termos de prioridades, sendo que os eventos que têm maior prioridade, e portanto devem ser executados primeiro, são os que possuem o menor tempo agendado para sua execução. Não existe um controle central sobre quando um modelo pode agendar eventos para serem executados, por ele próprio ou por outro modelo, durante a simulação. A simulação event-driven é uma maneira eficiente de simularmos sistemas nos quais não existe um relógio sincronizando os modelos ou quando determinados estados dos modelos podem ser alterados a qualquer instante. A técnica event-driven é empregada na simulação de diversos tipos de sistemas [7], que abrangem, por exemplo, o modelamento do clima, comportamento de bolsa de valores ou a simulação de redes de comunicação . A técnica event-driven é empregada em simuladores para rede de comunicação como o Hydragyrum, o Ptolemy [6], o OPNET [8] e o NS2 [9].
1.2.4
Simulação Paralela
As técnicas de simulação apresentadas são normalmente processadas na forma seqüencial, onde um incremento de tempo, bloco de dados ou evento é executado de cada vez por um processador. Entretanto, quando a simulação seqüencial começa a apresentar problemas em termos de desempenho em termos do tempo total de processamento, surge como uma alternativa de solução o emprego da simulação paralela para melhorar o desempenho e reduzir o tempo de obtenção de soluções [10].
A simulação paralela emprega vários processadores simultaneamente para realizar uma simulação, reduzindo desta forma o tempo total de execução. Os sistemas de simulação que empregam simulações em paralelo têm amadurecido nos últimos anos e no futuro serão uma alternativa viável para a simulação de sistemas grandes e complexos. Exemplos de simuladores paralelos empregados para a simulação de redes de comunicação são Telesim [11], TED [12] e Maisie/Parsec [13].
1.3
Softwares de Simulação para a Simulação de Redes de
Comunicação
Os softwares de simulação de redes de comunicação estão classificados em categorias conforme o grau de flexibilidade e o propósito ao qual o software está destinado. Em [14] estão definidas as três principais categorias de softwares para simulação de redes de comunicação, que são: linguagens gerais de simulação, linguagens de simulação orientadas às redes de comunicações e simuladores orientados às redes de comunicações.
Uma linguagem geral de simulação a princípio pode ser utilizada para simular qualquer sistema. Entretanto, algumas destas linguagens podem incluir conjuntos de modelos especialmente desenvolvidos para a simulação de redes de comunicações. Exemplos deste tipo de software que possibilitam a simulação de redes comunicação são: BONeS Designer [15], MODSIM II [16] e SIMSCRIPT II [17]. Destes, apenas o BONeS Designer possui módulos específicos para a simulação de sistemas de comunicação.
Um modelo é desenvolvido em uma linguagem de simulação através da elaboração de um programa (empregando a sintaxe da linguagem ou uma interface gráfica), que utiliza os elementos de modelagem da linguagem. Estes elementos, podem incluir entidades(mensagens), atributos (tipo ou destino da mensagem), recursos (nós ou enlaces) e filas (buffers). Talvez a maior vantagem deste tipo de software é que ele possibilita simular qualquer tipo de rede de comunicação, independente da sua complexidade e das suas singularidades. Entretanto, nem sempre é possível atingir o grau de detalhamento desejado quando se utiliza este tipo de ferramenta. Em uma linguagem geral de simulação, outras possíveis limitações são a necessidade de grande experiência de programação com a linguagem e um tempo muito grande que pode ser gasto no processo de codificação e depuração da modelagem de redes muito complexas.
As linguagens de simulação orientadas às redes de comunicações são linguagens construídas especialmente para a simulação de redes de comunicação. O OPNET Modeler [8] é um destes pacotes. Como vantagens temos a possível redução do tempo de programação pela utilização de modelos construídos especificamente para os sistemas de comunicação.
Os simuladores orientados às redes de comunicações apresentam-se basicamente como um pacote de software que permite a simulação de uma rede de comunicação de um tipo específico sem a necessidade de programação. Exemplos destes simuladores são o BONeS PlanNet [15], o
simulador ATM do NIST [3], e o COMNETIII [18]. A rede específica que está sendo simulada (dentro do âmbito das redes abrangidas pelo pacote) é construída através da escolha de componentes por meio de um menu, configurada através de caixas diálogos (formulários) e a topologia é estabelecida pelo uso de elementos gráficos (blocos e conexões). A principal vantagem de um simulador orientado a redes de comunicação é que ele permite uma grande redução no tempo de desenvolvimento da simulação quando comparado a uma linguagem de simulação. Este fato pode ser muito importante quando existir a necessidade de gerar rapidamente resultados para uma simulação.
Uma outra vantagem dos simuladores orientados à redes de comunicação é que eles possuem modelos intimamente relacionados aos elementos de uma rede de comunicação, que é uma característica desejável para alguém como um administrador de redes. Pessoas sem experiência com programação também preferem simuladores devido a sua facilidade de uso.
A principal desvantagem do simulador é que ele está limitado a modelar apenas aquelas redes que fazem parte do pacote de blocos básicos do simulador. Portanto, se um sistema de comunicação possui características únicas, não presentes no simulador, estas devem ser modeladas de uma maneira aproximada quando utilizamos certos simuladores. Entretanto, existem vários simuladores como o Ptolemy [6], NS2 [9], COMNETIII [18], e nosso ambiente de simulação, o Hydragyrum, que permitem a modificação de modelos básicos existentes ou a adição de novos modelos ao pacote de blocos do simulador, aumentando a flexibilidade da modelagem. Um sumário das características dos softwares discutidos neste capítulo pode ser observado na Tabela 1-1.
Técnica de Simulação Processamento
Software Data Flow Event Driven Seqüencial Paralelo
Adição de Modelos Ptolemy X X X X OPNET X X X NS2 X X X TELESIM X X X X MAISE X X X TED X X X MODSIM II X X X NIST ATM X X X BoNes X X X Hydragyrum X X X
Tabela 1-1: Comparação entre os diversos softwares para simulação de redes de comunicação.
1.4
Conclusão
Neste capítulo abordamos as principais técnicas de simulação e detalhamos o contexto dos softwares para a simulação de redes de comunicação. No próximo capítulo será descrita a implementação do ambiente de simulação Hydragyrum.
Capítulo 2
2 Estrutura do Ambiente de Simulação
2.1 Introdução
A estrutura do ambiente de simulação pode ser dividida em quatro partes distintas. A primeira, denominada de Kernel do programa, é responsável pelo gerenciamento e execução da simulação. A segunda parte, os Modelos dos Elementos de Rede, formam os blocos do ambiente de simulação responsáveis pelo comportamento dos modelos. A terceira parte consiste da Interface Gráfica, que permite a interação amigável entre o usuário e o ambiente de simulação. A quarta parte no ambiente de simulação é uma Interface de Linha de Comando, que permite a realização de roteiros de simulação dentro do ambiente.
Na Figura 2-1, observamos a estrutura geral do ambiente de simulação. O programa executável
Hydragyrum.exe é a interface gráfica e o programa executável simscl.exe é a interface de linha de
comando. Todos os modelos do Hydragyrum são construídos como DLLs [19], ou seja, bibliotecas de ligação dinâmica do sistema operacional Microsoft WindowsTM 32 bits (Windows 95/98/ME/NT/2000). Os modelos de elementos de rede são DLLs independentes que compartilham a classe Block e agregam elementos das classes Layer e Squeue. O Kernel do programa com sua
Biblioteca de Modelos é uma DLL que é carregada pela Interface gráfica ou pela interface de linha
de comando. A Biblioteca de Modelos do Kernel atua apenas como uma ponte entre os modelos e o Kernel, carregando e descarregando os modelos necessários para uma determinada simulação. O Kernel possui um interpretador de comandos e funções de interface para ser o servidor (kernel.dll) dos clientes que são as interfaces gráfica (Hydragyrum.exe) e de linha de comando (simscl.exe).
Neste capítulo, são mostrados a estrutura e o funcionamento do ambiente de simulação. Inicialmente descreveremos a estrutura do Kernel do ambiente de simulação. A seguir, descreveremos os modelos e sua interação com os elementos do Kernel. Finalmente, apresentaremos a estrutura das interfaces do ambiente de simulação.
kernel.dll
Biblioteca de ModelosKernel
Gerenciador Agendador Executor Interpretador Funções de InterfaceHydragyrum.exe
Topologia Funções de Interface Visualização de Resultadossimscl.exe
Topologia Funções de Interface Roteiro de SimulaçãoDLLs
Modelo de Elemento de Rede 1 Modelo de Elemento de Rede 2 Modelo de Elemento de Rede 3Figura 2-1: Estrutura geral do ambiente de simulação.
2.2 O Kernel
O Kernel do ambiente de simulação de redes agrega todas as funções disponíveis para a simulação a eventos discretos, sendo responsável pela carga dos modelos, agendamento e encaminhamento de eventos, interpretação de comandos e encerramento da simulação. No Kernel também estão presentes as estruturas de dados e as classes que podem ser usadas para a criação de novos modelos para o ambiente de simulação. Nesta seção, apresentaremos a estrutura do Kernel e descreveremos o seu funcionamento durante o processo de simulação de modelos. Apresentaremos
ainda as entidades que podem ser utilizadas dentro do Kernel para a criação e interconexão de modelos.
2.2.1 Estrutura e Funcionamento do Kernel
Na Figura 2-1 apresentamos a estrutura geral do ambiente de simulação onde detalhamos os aspectos funcionais dos diversos elementos do ambiente de simulação. Para realizar as funções descritas, o Kernel do ambiente de simulação foi organizado em uma arquitetura modular composta de um conjunto de classes que implementam as diferentes funções do Kernel. Na Figura 2-2, podemos observar as classes presentes no ambiente de simulação. A DLL do Kernel (kernel.dll) agrega todo as classes mostradas. Os elementos presentes no Kernel podem ser divididos em quatro categorias:
• elementos de gerenciamento e controle (classes Kernel, Auxiliar, Command, Library,
Scheduler e Dispatcher);
• elementos de modelamento (classes Block, Layer e Squeue);
• elementos de interconexão (classes Connection, NetConnection e DataConnection); • elementos para representação de tipos e estruturas de dados (classes Parameter, Table,
Event, SMessage e outras).
Os elementos de gerenciamento e controle realizam as funções do Kernel mostradas na Figura 2-1. Os elementos de modelamento permitem a construção de novos modelos. Os elementos de interconexão permitem a definição da conectividade entre os modelos. Os elementos para a representação dos diferentes tipos e estruturas de dados são empregados tanto nas tarefas de gerenciamento, controle e interface desempenhadas pelo Kernel quanto na construção de novos modelos.
Kernel
Classes para Representação dos Modelos
Classes Componentes do Kernel
Block
Layer SQueue
Classes para Representação dos Elementos de Conexão Connection DataConnection NetConnection Command Library Scheduler Dispatcher
Estruturas de Dados do Ambiente de Simulação Event SMessage Parameter Table Outras Estruturas de Dados
Figura 2-2: Estrutura de classes do Kernel do ambiente de simulação Hydragyrum.
Gerenciamento (Kernel)
Em um ambiente de simulação, a coordenação das diferentes funções necessárias à realização da simulação é efetuada por uma entidade central denominada de gerente da simulação. Este gerente, no Hydragyrum é a própria classe Kernel mostrada na Figura 2-2. Ela coordenada às atividades das outras classes e responde às solicitações enviadas através das interfaces do ambiente de simulação. O gerenciador mantém os vários elementos da simulação armazenados dentro de suas estruturas de dados. Ele armazena as diversas instâncias dos modelos de um sistema simulado e as relações de interconexão entre estes modelos que refletem a topologia do sistema. O gerenciador armazena também um conjunto de parâmetros globais que podem ser manipulados e acessados pelos modelos durante a simulação.
Biblioteca de Modelos (Library)
O carregador de bibliotecas dinâmicas permite a carga das DLLs, as quais contêm os modelos construídos para o ambiente de simulação na memória do computador. A partir de uma solicitação do gerenciador, a biblioteca de modelos carrega para a memória as DLLs dos modelos, cada um deles associado a um bloco do sistema. O bloco associado a uma instância do modelo é armazenado
no gerenciador e pode agora acessar os parâmetros globais da simulação, mantidos pelo gerenciador. Quando o bloco associado ao modelo é apagado do ambiente de simulação, a biblioteca de modelos descarrega este modelo da memória.
A utilização de DLLs dá origem a uma grande economia de memória porque para cada DLL carregada, apenas uma instância da parte comum da DLL é mantida na memória. Para as partes variáveis, correspondentes aos dados da DLL, que geralmente são menores que a parte comum, são alocadas várias instâncias para representar os dados individuais de cada modelo. Portanto, obtemos um uso mais eficiente da memória na simulação usando DLLs quando existem várias instâncias de um mesmo modelo. Assim, não necessitamos de espaço em memória para alocar todas as instâncias do modelo integralmente.
Interpretador (Command)
O ambiente de simulação possui uma linguagem de simulação denominada SCL (Simulation Command Language). Esta linguagem é utilizada como a principal interface entre o servidor (Kernel) e seus clientes (as interfaces). O apêndice A descreve os comandos desta linguagem. O interpretador do Kernel é responsável pela verificação de sintaxe, tratamento de erros e pela chamada das rotinas associadas aos comandos.
O interpretador de comandos interpreta para o Kernel os comandos enviados por uma das duas interfaces do simulador (gráfica ou de linha de comando). Os comandos são traduzidos em ações dentro do Kernel tais como ler um arquivo com a configuração de uma simulação, inicializar a simulação e executar a simulação. O interpretador de comandos suporta em sua interface de linha de comando o recurso de simulação por meio de roteiros (scripts) de simulação. Este recurso é extremamente útil quando se deseja fazer diversas simulações apenas com a variação de alguns parâmetros na mesma topologia de modelos a serem simulados.
Funções de Interface
As funções de interface são funções construídas especialmente para facilitar o acesso das interfaces aos dados e funções do Kernel, sem necessidade de utilizar o interpretador de comandos. Estas funções foram implementadas principalmente para utilização dentro da interface gráfica, onde
restrições de desempenho, introduzidas pelo processamento de seqüências de comandos e trocas de dados em modo caractere, poderiam afetar o desempenho da interface gráfica. Na interface de linha de comando, estas funções são pouco utilizadas uma vez que não é necessária uma troca constante de dados do Kernel para a interface de linha de comando.
Agendador (Scheduler)
O agendador de eventos dentro do ambiente de simulação implementa o núcleo do método de simulação a eventos discretos. O agendador implementa um fila de prioridades para os eventos a serem executados durante a simulação. Os eventos na fila de prioridades estão ordenados em ordem crescente de tempo de simulação, sendo que o evento que é mantido no topo da pilha é aquele que possui o menor tempo de simulação agendado. Desta forma, quando for necessário processar um evento, é só retirá-lo do topo da pilha, uma vez que a estrutura implementada na fila de prioridade garante a correta ordenação dos eventos a serem simulados. A implementação usada no ambiente de simulação foi baseada na fila de prioridades descrita em [20]. Podemos observar a forma como a fila de prioridades ordena os eventos na Figura 2-3.
t = 3
t = 7 t = 11
t = 15 t = 17 t = 8 t = 10
Evento de Mais Alta Prioridade
Executor (Dispatcher + Kernel)
A execução de eventos dentro do ambiente de simulação é realizada através da operação em conjunto do encaminhador (Dispatcher) e do gerenciador (Kernel). Durante a execução da simulação o gerenciador retira do topo da fila de prioridades (Scheduler) o evento que possui o menor tempo de execução agendado. Este evento, é então repassado ao encaminhador, que realiza a função de entregar o evento ao modelo ao qual este evento se destina. Quando o evento chega ao modelo de destino, ele é executado e agora o modelo detêm o controle da simulação. Quando termina a execução do evento o controle da simulação é devolvido ao gerenciador, que inicia novamente o ciclo de execução. O esquema do processamento de eventos no ambiente de simulação está resumido na Figura 2-4.
Kernel
Encaminhador
Agendador
(Fila de Prioridades Global)
Interpretador de Comandos Sistema Simulado Ev ento 1 (tem po ,m ens ag em ) Ev ento 2 (tem po ,m ens ag em ) Ev ento 3 (tem po ,m ens ag em ) Ev ento 4 (tem po ,m ens ag em ) Ev ento 5 (tem po ,m ens ag em )
Interface Gráfica Interface de Linhade Comando
Agendamento de Eventos
Modelo de Elemento de Rede 3 Modelo de Elemento
de Rede 1 Modelo de Elementode Rede 4
Modelo de Elemento
de Rede 2 Modelo de Elementode Rede 5
Execução de Eventos
2.2.2 Elementos de Modelamento
Os elementos do Kernel que permitem a adição de novos modelos ao ambiente de simulação são as classes Block, Layer e Squeue mostradas na Figura 2-2. Novos modelos são derivados da classe base Block. A classe Block pode conter um conjunto de componentes derivados das classes Layer e
Squeue. A classe Block define também a interface para a carga da DLL do modelo para dentro do
Kernel e a aparência do bloco do modelo na interface gráfica. As classes Block, Layer e Squeue fornecem uma série de funcionalidades para integração dos modelos com o ambiente de simulação, tais como:
• manipulação de estruturas de dados; • criação, envio e processamento de eventos; • envio de mensagens entre modelos;
• padronização para arquivos de entrada e saída na interface gráfica; • manipulação de parâmetros do modelo.
A classe Block é a classe de interface entre o Kernel e as outras classes que estão contidas dentro da classe Block (Layer e Squeue). Cada classe derivada da classe Block, a qual se agregam novas camadas (classes derivadas da classe Layer) e sistemas de filas (classes derivadas da classe Squeue), constitui uma DLL de modelo. Desta forma, o modelo na simulação é definido como um bloco onde são agregados camadas e sistemas de filas, que se comportam conforme as características do elemento que se pretende modelar. A classe Layer deve abrigar os diferentes algoritmos que retratam o comportamento do modelo na simulação. A classe Squeue deve representar os elementos de armazenamento e serviço das mensagens na simulação. A divisão das funções originalmente atribuídas a cada classe baseia-se em um modelo genérico para elementos de rede. Na concepção original, estão presentes o elemento de rede (Block), seus algoritmos (Layer) e suas estruturas de armazenamento (Squeue). Entretanto, nada impede que outras funções possam ser desempenhadas por estas classes dentro da estrutura do modelo, uma vez que a definição do comportamento e do algoritmo que será implementado em cada classe é de responsabilidade do projetista do modelo. Portanto, quando se respeitam as funções básicas e a interface das classes de modelamento, qualquer outra funcionalidade não prevista originalmente pode ser desempenhada pelas classes de modelamento.
Block
SQueue
Layer
Figura 2-5: Relação de associação entre as classes de modelamento.
Na Figura 2-5, podemos observar as relações de associação da classe Block com as classes Layer e Squeue. Novas classes derivadas das classes Layer e Squeue são adicionadas por associação de ponteiros ao bloco do modelo (classe derivada de Block). Após a associação dos elementos ao bloco, este gerencia a desalocação das instâncias das classes associadas no momento em que o próprio bloco é desalocado da memória pelo Kernel do ambiente de simulação. Na Figura 2-5, as classes
Layer e Squeue relacionam-se apenas através de associações de ponteiros, sem que estas impliquem
em relações de pertinência e responsabilidade de desalocação entre as classes. As associações entre classes derivadas das classes Layer e Squeue podem ser unidirecionais ou bidirecionais, sendo escolhidas conforme a lógica do modelo a ser implementado.
2.2.3 Elementos de Interconexão
Na seção anterior, descrevemos como o ambiente de simulação emprega os conceitos de derivação e associação para a construção de novos modelos. Entretanto, após construirmos os modelos utilizando as classes base de modelamento, necessitamos representar dentro do ambiente de simulação a maneira pela qual estes modelos estão interconectados. Para representar a interconexão entre os modelos do ambiente de simulação, uma série de classes de interconexão foi definida dentro da arquitetura do ambiente de simulação. Estes objetos de interconexão, acessíveis aos modelos do ambiente de simulação, estão organizados em uma estrutura hierárquica similar a arquitetura de camadas do modelo ISO/OSI [21].
Os objetos de interconexão representam as relações topológicas entre os modelos nos vários níveis (camadas) da hierarquia da rede simulada. Na estrutura do Kernel, esta hierarquia é representada pelos objetos das classes Connection, NetConnection e DataConnection. O relacionamento destas estruturas em sua hierarquia é mostrado na Figura 2-6. O objeto da classe
nos níveis superiores. O objeto da classe conexão de rede Netconnection está no nível intermediário da hierarquia, contendo objetos da classe Connection imediatamente abaixo e contido dentro dos objetos da classe Dataconnection imediatamente acima. Estas estruturas de dados permitem a agregação de conexões em três níveis diferentes para representar as camadas de conexões, por exemplo, de uma rede de ATM ou TCP/IP. Utilizando a estrutura hierárquica de conexões, o Kernel do ambiente de simulação disponibiliza, aos modelos, funções para rotear automaticamente os eventos, dentro da topologia descrita pelos objetos de interconexão. Desta maneira, é facilitado o envio de eventos entre os modelos durante a simulação. Entretanto, se for necessário ao projetista de modelos utilizar a hierarquia de objetos de interconexão para representar outras formas de relacionamento entre os objetos de interconexão do Kernel, ele poderá fazê-lo sem necessitar alterar o Kernel. Para realizar esta tarefa, o projetista de modelos precisa utilizar apenas as funções das classes de modelamento que tratam com os objetos de interconexão. Quando os objetos de interconexão forem removidos da simulação sua deleção também deve respeitar a relação de hierarquia entre os mesmos. A Figura 2-7, mostra a ordem de deleção que é seguida pelo Kernel quando os diferentes elementos de interconexão são deletados.
Conexão de Dados - DC1
Conexão de Rede - NC1
Conexão de Rede - NC2
C1
C2
C3
C4
C5
C6
C1 a C6 - Conexões
Os elementos de interconexão do ambiente de simulação são representados pelas classes
Connection, NetConnection e DataConnection. As classes de interconexão definem a topologia da
rede, o caminho e a direção do fluxo de eventos da simulação. Na Figura 2-8, podemos observar o relacionamento das diferentes classes de interconexão, e um exemplo de sua utilização para a representação de conexões em um modelo hierárquico. A classe Connection pode representar conexões físicas ou de enlaces entre os blocos dos modelos da simulação. Ela representa pares de conexão bloco fonte e camada fonte ligada ao bloco de destino e camada de destino. Um objeto da classe Connection é bidirecional. Logo conectar um bloco/camada A/X com outro bloco/camada B/Y, é equivalente a conectar um bloco/camada B/Y com um bloco/camada A/X. A classe
Connection é a classe sobre a qual todas as outras classes de conexão são construídas. Isto implica,
que no momento em que se destrói um objeto da classe Connection, por exemplo, todas as conexões de rede (NetConnection) e conexões de dados (DataConnection) que usam o objeto da classe
Connection, que está sendo apagado, são destruídas.
A classe NetConnection representa um caminho unidirecional a ser percorrido na rede, composto pela associação de uma seqüência de objetos da classe Connection. No estabelecimento de um caminho pela rede de conexões na topologia a ser simulada (criação de um objeto da classe
NetConnection), os objetos da classe Connection, são ordenados e verificados automaticamente pelo
Kernel. A partir da especificação da fonte e do destino do caminho de rede, e baseando-se na informação de quais blocos e camadas estão conectados pelos objetos da classe Connection, o Kernel pode estabelecer de forma automática um caminho através da rede interconectando dois blocos de modelo.
A classe Dataconnection pode representar as conexões de dados entre os aplicativos que geram a informação a ser transmitida na rede. O objeto da classe Dataconnection é unidirecional sendo composta pela associação de um ou mais objetos de conexões de rede Netconnection que estão disponíveis entre a fonte e o destino especificados.
Ordem de Deleção dos Objetos de Conexão Deleção de Conexão DataConnection Connection NetConnection DataConnection Connection NetConnection
Deleção de Conexão de Rede
DataConnection
Connection NetConnection
Deleção de Conexão de Dados
Deleção
Deleção
Deleção
Figura 2-7: Ordem de deleção dos objetos de interconexão do ambiente de simulação.
Camada de Rede
Camada Física e/ou de Enlace B1 B2 B3 B4
C1 C2 C3
NC2 NC1
Composição dos Objetos de Conexão de Dados Composição dos Objetos de Conexão de Rede
NC1 (B1-B4) NC2 (B1-B3)
C1 C1
C2 C2
C3
-B1, B2, B3, B4 - blocos dos modelos Camada de Interface de Saída (Porta) Camada de Interface de Entrada (Porta)
Objetos Conexão C1 (B1-B2) B1 Saída | B2 Entrada C2 (B2-B3) B2 Saída | B3 Entrada C3 (B3-B4) B3 Saída | B4 Entrada Camadas Altas (Transporte, Aplicação) DC3 DC2 DC1 DC1 (B1-B4) DC2 (B1-B3) NC1 NC2 NC2 -DC3 (B1-B3) NC2
-Figura 2-8: Exemplo de construção de uma rede entre modelos utilizando os objetos de
Na Figura 2-8, observamos um exemplo do emprego dos objetos de interconexão de redes. Os blocos de modelos são interconectados por objetos da classe Connection (C1,C2 e C3), que são denominados de objetos de conexão no exemplo, e representam as conexões de enlace entre os modelos. Existem dois objetos da classe NetConnection (NC1 e NC2), denominados de conexão de rede, e representam um caminho na rede composto por uma seqüência de enlaces. O caminho de rede é a rota por onde a informação trocada entre os modelos (eventos) pode fluir através da rede. Os três objetos da classe DataConnection (DC1, DC2 e DC3), denominados de conexões de dados, definem por quais caminhos de rede um determinado fluxo de informação irá trafegar. A conexão de rede DC1 trafega seus dados apenas através do caminho de rede NC1. Entretanto, os recursos do caminho de rede NC1 podem também ser utilizados pelos outros fluxos de dados se não houver isolação do tráfego nos caminhos de rede. As conexões DC2 e DC3, trafegam sobre o mesmo caminho de rede NC2, devendo, portanto, compartilhar todos os recursos disponíveis neste caminho de rede que venham a ser implementado nos modelos.
bhash
btree
btable
bqueue
bhash
bpriorque
blist
biterator
bvector
Event
Smessage
Sstring
Table
Joker
Parameter
Param
Figura 2-9: Estruturas de dados do ambiente de simulação.
2.2.4 Estruturas de Dados
As estruturas de dados do ambiente de simulação são mostradas na Figura 2-9. Elas são utilizadas para armazenar as informações usadas pelo Kernel e pelos modelos durante a simulação. Muitas destas estruturas já vem sendo utilizadas em nosso grupo de pesquisa na área de simulação há alguns anos. Entretanto, todas as estruturas de dados precisaram de modificações para se adaptar
às novas estruturas usadas como containers (repositórios) de dados no ambiente de simulação. A classe Sstring, é uma abstração de dados para trabalhar com vetores de caracteres alfanuméricos, sendo usada na maioria das trocas de nomes e de informação alfanumérica nos modelos.
As classes de parâmetros (Param, Parameter e Joker) representam os tipos de dados suportados pelo simulador. A classe Joker é o local de armazenamento dos tipos de dados suportados pelos parâmetros. Os tipos de dados suportados atualmente são long, int, double, Sstring e unsigned int, e estão definidos no arquivo Simdefs.h, que pode ser estendido para outros tipos de dados. Como estas classes utilizam expansão de macros para sua definição, o tamanho do código do programa aumenta muito a cada novo tipo de dado adicionado. A classe Parameter apenas adiciona ao dado da classe Joker um conjunto de Sstrings, as quais representam uma descrição do parâmetro, informação de formato e uma opção. A classe Param é responsável pelo armazenamento de um conjunto de objetos da classe Parameter indexados em um dicionário pelo nome do parâmetro que definirá a interface para ler, escrever, inserir e apagar novos parâmetros nas classes dos modelos do ambiente de simulação. O Kernel possui uma instância da classe Param, a qual representa os parâmetros globais da simulação. A estrutura de dados na forma de parâmetros é uma contribuição do trabalho do SimNT [1][2], que se mostrou muito eficiente para tratar com a atualização de variáveis dentro dos modelos. Uma outra contribuição do trabalho do SimNT é a estrutura de dados implementada na classe Sstring.
A classe Table implementa outra estrutura de dados para o armazenamento dos mesmos tipos de dados descritos no arquivo Simdefs.h (long, int, double, Sstring e unsigned int). Sua estrutura permite que estes tipos de dados sejam indexados por duas chaves de procura na tabela. Esta estrutura é útil para o armazenamento de tabelas de roteamento e associações de sistemas de filas (Squeue) e camadas (Layer) dentro dos modelos. A estrutura da classe Table foi uma contribuição do trabalho da primeira versão do SimATM [4].
Os eventos e as mensagens trocadas entre os elementos da simulação são representados pelas classes Event e Smessage. A classe Event representa os eventos trocados na simulação. Estes eventos contêm as informações do tempo em que devem ser processados, para qual elemento da simulação se destinam e uma string que identifica o tipo do evento gerado. Os eventos são gerados por funções específicas dentro dos blocos (Block), camadas (Layer) e sistemas de filas (Squeue) dos modelos. A classe Smessage é a classe base para a derivação de novas mensagens a serem transportadas pelos eventos do simulador. Ela possui apenas alguns poucos campos fixos, como o
tempo de entrada e de saída em uma fila. Outros dados podem ser adicionados conforme a necessidade de cada conjunto de modelos a serem simulados. Desta forma, a classe Smessage, utilizando a estrutura de derivação, permite ao Kernel uma maneira simples e prática para sua adaptação às futuras necessidades dos modelos do ambiente de simulação.
SMessage
Cell
Packet
Figura 2-10: Classe SMessage utilizada como base para o transporte de tipos genéricos de
mensagens dentro dos eventos.
Na construção de uma biblioteca de classes container adaptamos e corrigimos a biblioteca de classes template descrita em [20]. As classes desta biblioteca, mostradas na Figura 2-9, implementam o equivalente aos containers genéricos da STL (Standard Template Library) [22]. A classe bhash implementa uma hash table, utilizada para a indexação de elementos em outras classes tipo containers. A classe biterator implementa a interface para a abstração de iteradores genéricos para as outras classes tipo containers. A classe bstack implementa a abstração de uma pilha de tipos genéricos. A classe bqueue implementa a abstração de uma fila de tipos genéricos. A classe btree implementa uma arvore binária de tipos genéricos. A classe bmap implementa uma estrutura equivalente aos mapas da STL, onde mapeia-se um tipo de dado em outro. A classe bvector implementa um vetor de tipos de dados genéricos, utilizado na maioria dos modelos para obter conjuntos de valores como resposta a uma função de requisição de informação. A classe bpriorque implementa a fila de prioridades utilizada pelo gerenciador de eventos do kernel.
Estas estruturas de dados genéricas (templates) devem ser usadas obrigatoriamente nas funções de interação dos modelos com o Kernel do ambiente de simulação. No entanto, se os modelos não necessitarem que suas classes sejam exportadas por sua DLL para outros modelos, eles podem fazer uso das classes da STL ou de outras classes template em seu código sem necessitar usar as classes tipo container definidas no ambiente de simulação para realizar as operações internas do modelo. A utilização das classes container dentro das operações internas do modelo é obrigatória, quando este deve ser exportado para ser utilizado como base de outros modelos, devido às limitações no tamanho do nome das funções exportadas em uma biblioteca de funções. Isto só acontece porque
alguns compiladores não suportam os nomes extremamente longos gerados pela exportação de funções da STL.
Estrutura de Dados Descrição
Sstring String genérica utilizada para a manipulação de caracteres. Parameter Parâmetros do modelo para manipulação nas interfaces. Table Tabela de dados indexada com duas chaves de procura. Blist Classe de lista genérica retornada pelo kernel.
Bvector Classe de vetor genérica retornada pelo kernel.
Smessage Classe base das mensagens do ambiente de simulação. Event Classe que representa os eventos trocados entre os modelos.
Tabela 2-1: Estruturas de dados definidas no ambiente de simulação para troca de
informações entre o Kernel e os modelos.
O Kernel e os modelos podem trocar informação utilizando uma série de estruturas de dados pré-definidas no Kernel e nas classes de modelamento. Estas estruturas são mostradas na Tabela 2-1. As estruturas de dados devem, necessariamente, ser utilizadas apenas nas funções de interface que requerem estes tipos de dados específicos, dando a liberdade ao projetista de modelos para definir os tipos de dados que mais lhe convém para serem trocados entre os modelos de seu próprio conjunto de modelos.
Classe Kernel (kernel.h) Library * Factory EventManager * Scheduler Dispatcher * Dispatch Param * GlobalParam Command * Interpreter Auxiliar * AuxiliarFunc ConsoleOstream Prompt blist < Block * > Blocks
blist < Connection *> Connections blist < NetConnection *> NetConnections blist < DataConnection *> DataConnections
Classe Command (command.h) Classe Library (library.h) Classe EventManager (eventmanager.h) Classe Auxiliar (auxiliar.h) Classe Dispatcher (dispatcher.h) Classe ConsoleOstream (sim_ostream.h) Classe Param (param.h) Classe blist<T> (blist.h)
Figura 2-11: Estrutura de classes implementadas que compõem o Kernel do ambiente de
simulação.
2.2.5 Implementação do Kernel
Na Figura 2-11, observamos o diagrama das classes que compõem a implementação do Kernel. A classe Kernel tem seu protótipo no arquivo kernel.h, sendo composta pelas classes Library,
EventManager, Dispatcher, Param, Command, Auxiliar e ConsoleOstream. A classe Library,
implementa as funções de carga e descarga das DLLs dos modelos. A classe EventManager, implementa as funções de agendamento e ordenação da fila de prioridades dos eventos na simulação. A classe Dispatcher implementa as funções de encaminhamento dos eventos ao seu destino. A classe Param fornece o repositório para os parâmetros globais da simulação. A classe
Command representa uma instância do interpretador de comandos do ambiente de simulação. A
classe Auxiliar, implementa uma série de funções auxiliares para a manipulação dos arquivos de entrada e saída do Kernel. A classe ConsoleOstream é uma interface de saída genérica, para qual os modelos podem enviar mensagens através do Kernel e apresentá-las tanto na janela da interface gráfica quanto na janela da interface de linha de comando. A lista da classe blist<T> implementa o
container para os objetos armazenados no Kernel, que são os blocos dos modelos (Block) e os
bhash.h btree.h btable.h bqueue.h bhash.h bpriorque.h blist.h biterator.h bvector.h sim_defs (.h) squeuemcr (.h .cpp) block (.h .cpp) blockmcr (.h .cpp) blockb (.cpp) blockc (.cpp) layer (.h .cpp) layerb ( .cpp) squeue (.h .cpp) kernel (.h) kernelmcr (.h .cpp) kernela (.cpp) kernelc (.cpp) kernelb (.cpp) connection (.h .cpp) dataconnec (.h .cpp) netconnec (.h .cpp) event (.h .cpp) smessage (.h .cpp) sstring (.h .cpp) Table (.h .cpp) joker (.h .cpp) parameter (.h) param (.h .cpp) auxiliar (.h .cpp) command (.h .cpp) commandb (.cpp) dispatcher (.h .cpp) library (.h .cpp) sim_iostream (.h .cpp) stimer (.h .cpp) eventmanager (.h .cpp)
Figura 2-12: Arquivos das classes que compõem o Kernel do ambiente de simulação.
Na Figura 2-12, são mostrados os arquivos que contêm os códigos da implementação do Kernel do ambiente de simulação. Os arquivos .h indicam arquivos de cabeçalho e os arquivos .cpp indicam os arquivos de fonte usados na implementação do Kernel. Estes arquivos são compilados e ligados para construir a biblioteca de ligação dinâmica do Kernel do ambiente de simulação denominada kernel.dll. A DLL kernel.dll é carregada tanto pelas interfaces de linha de comando quanto pela interface gráfica, e também é empregada para a construção de novos modelos.
Class Layer Block * OwnerBlock Kernel * _Kernel
EventManager * Scheduler blist < Connection * > Connections blist < Squeue *> Squeues blist < DataConnection *> DCs blist < NetConnection *> NCs
Class Block blist < Layer * > Layers blist < Connection * > Connections blist < Squeue * > Squeues blist < InterfacePort > InterfacePorts blist < NetConnection * > NCs blist < DataConnection * > DCs Param * GlobalParam EventManager * Scheduler Kernel * _Kernel
bmap <Sstring , Sstring> OutputFileNames ConsoleOstream MESSAGE
Class Squeue Block * OwnerBlock
Kernel * _Kernel
EventManager * Scheduler blist < Layer * > AssociatedLayers blist < Connection * > AssociatedConnections blist < NetConnection *> AssociatedNetConnections blist < DataConnection *> AssociatedDataConnections
Class Connection Kernel * _Kernel Block * BeginBlock Block * EndBlock Layer * BeginLayer Layer * EndLayer
blist < NetConnection * > NetConnections
Class Event double Time Sstring Type Block * SourceBlock Block * DestinationBlock Layer * SourceLayer Layer * DestinationLayer Squeue * SourceSqueue Squeue * DestinationSqueue SMessage * EventMessage NetConnection * EventNetConnection DataConnection * EventDataConnection Class NetConnection Kernel * _Kernel
blist < Connection *> Connections Sstring BeginBlock
Sstring EndBlock Sstring BeginLayer Sstring EndLayer
blist < DataConnection *> DataConnections
Class DataConnection Kernel * _Kernel
blist < NetConnection * > NetConnections Sstring Source Sstring Destiny Sstring BeginLayer Sstring EndLayer Sstring BeginSap Sstring EndSap
Figura 2-13: Implementação das classes de modelagem, interconexão e eventos.
Na Figura 2-13, temos a implementação das classes de modelagem, eventos e interconexão presentes no ambiente de simulação. A classe Block, apresenta uma série de listas Blist <T> que implementam os containers para outros objetos que são componentes do bloco. Estes elementos são derivados das classes Layer e Squeue. A classe Block contem as listas das conexões (Connection) conexões de rede (NetConnection) e conexões de dados (DataConnection) que passam através do bloco do modelo. Na classe Block são definidas as portas do modelo na interface gráfica (InterfacePort) e os nomes dos arquivos de geração de resultados para a interface gráfica (OutputFileNames). A classe Block possui também ponteiros para o Kernel (_Kernel) e para a classe de agendamento de eventos (Scheduler) do ambiente de simulação. Os parâmetros globais da simulação na classe Block são manipulados através de um ponteiro para os parâmetros globais armazenados no Kernel (GlobalParam). As mensagens geradas pelo modelo dentro da classe Block são transportadas para a interface gráfica ou de linha de comando utilizando o objeto de interface da classe ConsoleOstream. A implementação da classe Layer é semelhante à da classe Block, entretanto, as conexões armazenadas representam agora as conexões, conexões de redes e conexões
de dados que pertencem à camada (Layer). A classe Layer possui um ponteiro para o bloco (Block) que a contêm e um conjunto de ponteiros para as filas (Squeue) que podem ser associadas à camada. A classe Squeue possui estrutura semelhante a classe Layer com uma série de listas para a associação arbitrária de camadas (Layer), conexões (Connections), conexões de rede (NetConnections) e conexões de dados (DataConnection). A Figura 2-14, mostra a inclusão das estruturas de dados de parâmetros (Param) e tabelas (Table) nas classes de modelamento, que é realizada através de herança múltipla. A classe Connection contem ponteiros para o Kernel e ponteiros para os blocos (Block) e camadas (Layer) que compõem a conexão. A classe Connection contém também uma lista das conexões de rede (NetConnection) que utilizam o objeto da classe. A classe NetConnection contém ponteiros para o Kernel do ambiente de simulação e o nome dos blocos e camadas terminais do objeto. A classe NetConneciton apresenta duas listas, uma das conexões (Connection) que a compõem e a outra das conexões de dados (DataConection) que a utilizam. A classe Dataconnection contem um ponteiro para o Kernel e os nomes das blocos, camadas e pontos de acesso que são os terminais da conexão de dados. A classe Dataconnection possui uma lista das conexões de rede (NetConnection) que utiliza para transmitir dados de um aplicativo no modelo de rede simulada.
Param
Table
SQueue
Layer
Block
Figura 2-14: Diagrama de herança relacionando as classes base de criação de modelos às
estruturas de dados Param e Table.
Na Figura 2-13, a classe Event define as informações presentes nos eventos do ambiente de simulação. Para caracterização do evento são necessários o tempo em que ele será executado, o tipo do evento a ser executado, o elemento da simulação que gera o evento, o elemento da simulação que recebe o evento e as conexões de dados (DataConnection) e de rede (NetConnection) da qual o evento pode fazer parte. A classe Event, transporta as mensagens trocadas entre os modelos através de uma estrutura polimórfica representada por classes derivadas da classe SMessage.
2.3 Modelos
Os modelos do ambiente de simulação são compostos de objetos derivados das classes base
Block, Layer e Squeue. A classe Block é a classe que define o modelo e como ele agrega os seus
componentes, que podem ser objetos derivados das classes base Layer ou Squeue. Esta agregação dos diferentes elementos dentro do bloco do modelo permite uma modularidade no projeto do código do modelo e na apresentação e manipulação dos parâmetros do modelo na interface gráfica.
AAL5 BTE_INPUT BTE BTE_OUTPUT PRIORITY_QUEUE ALL5 BTE_OUTPUT BTE_INPUT layer smessage Packet Cell Block BTE PRIORITY_QUEUE squeue Composição do Modelo
Figura 2-15: Exemplo de composição de um modelo no ambiente de simulação.
Um fato importante a ressaltar na arquitetura do ambiente de simulação é a forma como as mensagens são definidas, usando o polimorfismo da linguagem C++. No ambiente de simulação, as mensagens são derivadas da classe base SMessage e transportadas dentro dos eventos usando um campo de ponteiro para a classe SMessage presente na estrutura do evento (objeto da classe Event). Esta característica da linguagem C++ permite que, no ponto de recepção do evento, a mensagem seja extraída do evento e convertida para o tipo de dado apropriado. Assim, em termos da linguagem C++, o ponteiro da classe base de mensagens (SMessage) é convertido para o ponteiro da classe derivada apropriada, permitindo o acesso direto a todos os dados presentes na classe derivada. O