Tutorial do MobiCS - INF

Tutorial do MobiCS
by Ricardo Couto Antunes da Rocha
NOTICE:
Table of contents
1 Visão Geral de uma Simulação Usando MobiCS................................................................................................................... 2
2 Implementação Passo-a-Passo do Protocolo RDP...................................................................................................................2
2.1 Implementação do protocolo.............................................................................................................................................. 2
2.2 Simulação............................................................................................................................................................................2
2.3 Compilação e Execução do Exemplo.................................................................................................................................3
3 Programando um Protocolo com Timers.................................................................................................................................3
4 Modo de Simulação Estocástico..............................................................................................................................................3
4.1 Introdução........................................................................................................................................................................... 3
4.2 Os Parâmetros de Simulação e a Criação de um Elemento...............................................................................................4
4.3 A Criação dos Modelos de Simulação...............................................................................................................................4
4.4 Etapas de Implementação da Simulação............................................................................................................................ 6
4.5 Exemplo.............................................................................................................................................................................. 6
5 Detalhes sobre Implementação de Protocolos......................................................................................................................... 6
5.1 Endereços de Hosts............................................................................................................................................................ 6
5.2 Criação de Mensagens........................................................................................................................................................7
© 2000-2004 IME-USP / PUC-Rio
Copyright © 2004 IME-USP/PUC-Rio. All rights reserved.
Tutorial do MobiCS
1 Visão Geral de uma Simulação Usando MobiCS
O tutorial abaixo corresponde a uma apresentação feita na aula de MAC 5743, no IME-USP. Nestes slides é mostrado um
exemplo de como um protocolo pode ser prototipado e simulado no MobiCS. O protocolo usado como exemplo foi o RDP. Há
também uma versão em postscript ( http://www.ime.usp.br/~sidam/Tools/MobiCS/aula02_mac5743.ps.gz) do documento.
•
•
•
Visão Geral ( http://www-di.inf.puc-rio.br/~endler/MobiCS/mobics-tutorial1.pdf) do MobiCS
Tutorial do MobiCS: Interfaces de Programação e Exemplos ( http://www.ime.usp.br/~sidam/Tools/MobiCS/aula2)
Exemplo de Uso ( http://www-di.inf.puc-rio.br/~endler/MobiCS/mobics-tutorial2.pdf)
Outras páginas com informações sobre simulação no MobiCS:
•
•
Página do MobiCS na PUC-Rio ( http://www-di.inf.puc-rio.br/~endler/MobiCS/) , do prof. Markus Endler
Página antiga ( http://www.lcpd.ime.usp.br/~mobics/old-site) do MobiCS
2 Implementação Passo-a-Passo do Protocolo RDP
Como exemplo passo-a-passo de implementação e simulação de um protocolo no MobiCS, vamos utilizar como exemplo o
protocolo RDP. Para maiores detalhes sobre este protocolo, favor conferir na página de exemplos ( samples.html#RDP) .
Nota
Observe que na página de exemplos há protocolos mais simples que o RDP!
Para implementar e simular o protocolo RDP do exemplo disponibilizado, é necessário seguir os seguintes passos:
2.1 Implementação do protocolo
1.
2.
3.
4.
Declarar as mensagens tratadas pelo protocolo. Todas as mensagens são declaradas como subclasses da classe Message.
Essas classes estão no pacote sidam.rdp.messages ( ../sample/sidam/rdp/messages) .
Definir as instâncias de implementação do protocolo. O RDP possui uma instância para Mss's e Mh's. Para efeito
de testes, criamos também uma instância do protocolo para servidores, que chamamos de RDPServer. Esta instância é
responsável apenas por responder um requisição Req, com uma mensagem Res. No script determinístico, o protocolo do
servidor
Declarar os micro-protocolos na forma de interfaces Java. A implementação do RDPMss, que é a mais complexa, contém
três micro-protocolos: RDPMssWireless ( ../sample/sidam/rdp/RDPMssWireless.java) , RDPMssWired ( ../sample/sidam/
rdp/RDPMssWired.java) e RDPMssHandoff ( ../sample/sidam/rdp/RDPHandoffModule.java) . Observe nos arquivos quais
mensagens são tratadas pelos micro-protocolos, comparando o nome dos métodos com as mensagens declaradas no item 1.
Implementar o protocolo. Para implementar um protocolo é necessário implementar as classes que implementam os
métodos de todos os micro-protocolos declarados. No caso do RDPMss, a implementação é feita na classe RDPMss.java
( ../sample/sidam/rdp/RDPMss.java) .
2.2 Simulação
1.
2.
Declarar os tipos de elementos simulados utilizados na simulação. Devem ser declaradas classes (em geral) que
definam elementos simulados com mesmo padrão de comportamento. Tipicamente, declara-se uma classe para cada Mss
e/ou Mh que possuem os mesmos protocolos encapsulados e padrão de comportamento durante a simulação. No exemplo
do RDP, foram declaradas duas classes: MyMss.java ( ../sample/MyMss.java) e MyMh.java ( ../sample/MyMh.java) .
Os construtores da classe simplesmente criam um objeto protocolo, que implementa o RDP para aquele elemento, e
incorporam ele ao elemento, que a partir daí é capaz que responder com o protocolo a todas as mensagens do RDP
recebidas.
Implementar a simulação determinística. Para isso, é necessário criar uma subclasse de DetermSimulation ( ../api/
mobics/simulation/DetermSimulation.html) e implementar os métodos configure e script. A simulação determinística está
implementada na classe MySimulation.java ( ../sample/MySimulation.java) . No método configure deve-se inicializar todos
© 2000-2004 IME-USP / PUC-Rio
Copyright © 2004 IME-USP/PUC-Rio. All rights reserved.
Page 2
3.
Tutorial do MobiCS
os elementos simulados (que foram declarados como atributos da classe), enquanto que no método script deve-se descrever
o script determinístico.
Incorporação e execução da simulação no programa do usuário. O programa do usuário é a classe MyApp.java ( ../
sample/MyApp.java) . Ela simplesmente cria um objeto da classe MySimulation e inicia a simulação, executando o método
start.
2.3 Compilação e Execução do Exemplo
1.
2.
3.
Faça o download do arquivo ( ../sample/exemplordp.tar) com o exemplo RDP. Descompacte o arquivo com o comando
tar -xvf exemplordp.tar (no Windows o próprio Winzip é capaz de gerar os arquivos a partir do .TAR).
Considerando que sua variável de ambiente CLASSPATH contém os caminhos para acesso às bibliotecas do JDK1.2.2,
adicione a ela as bibliotecas do MobiCS e do JGL. No caso da rede IME, você deve usar o comando export
CLASSPATH=$CLASSPATH:/home/posmac/rcarocha/lib/mobics.jar:/home/posmac/rcarocha/
lib/jgl3.1.0.jar:.
Compile o exemplo com o comando javac MyApp.java. Execute com o comando java MyApp.
3 Programando um Protocolo com Timers
O documento abaixo descreve como programar e simular um protocolo que utiliza timers, ou seja, que executa ações após
tempos pré-determinados.
•
Programação de Eventos de Tempo no MobiCS ( http://www.inf.puc-rio.br/~endler/MobiCS/timers.pdf)
4 Modo de Simulação Estocástico
4.1 Introdução
A simulação determinística foi utilizada para permitir testar o funcionamento do protocolo em situações bem específicas e
críticas, que eram programadas pelo usuário da simulação. O seu objetivo é permitir avaliar a corretude do protocolo.
Na simulação estocástica, o protocolo será submetido a um cenário aleatório e a uma simulação exaustiva, que deverão
permitir:
•
•
a avaliação do desempenho do protocolo
observação do comportamento do protocolo em cenários maiores e exaustivos, cuja descrição em script detemrinístico é
impraticável. Com isso, a estabilidade do protocolo poderá ser avaliada também.
A diferença básica da simulação determinística para a estocástica é a forma como o cenário de simulação é descrito.
Enquanto que na simulação determinística o usuário descrevia em um script um cenário bem específico e determinístico, na
estocástica o usuário deverá descrever os padrões de comportamento de todos os elementos de rede: máquinas fixas e móveis
e canais de comunicação. Por exemplo, se no script o usuário colocava explicitamente comandos MoveTo para realizar uma
migração de um Mh, na simulação estocástica o usuário deverá indicar em qual taxa o Mh migra de célula. Esses padrões de
comportamento são chamados de modelos de simulação. Vamos definir os seguintes termos:
•
•
•
Parâmetros de simulação: conjunto de parâmetros de entrada de um elemento simulado que definem como eventos
internos serão gerados surante a simulação.
Modelo de simulação: define quais são os parâmetros dos elementos simulados que definem seu comportamento e como
os eventos internos (como envio de mensagens e migrações) são gerados a partir desses parâmetros.
Eventos internos: quaisquer eventos que um elemento simulado pode gerar sem a interferência de outro, como enviar
mensagens, migrar (caso de Mh). Caso um elemento gere nenhum evento interno, ele será um elemento passivo na
simulação, que apenas executa alguma ação quando recebe uma mensagem de outro elemento.
A maioria dos simuladores define um modelo de simulação e o usuário define seus parâmetros quando quiser executar uma
simulação. O MobiCS é flexível o bastante para permitir que novos modelos de simulação possam ser implementados e usados
em simulações, e é justamente essa a tarefa que deverá ser feita no 2o. EP: implementar o modelo de simulação descrito
no trabalho e executar a simulação com diferentes parâmetros, observando o comportamento do protocolo. Para isso, não é
© 2000-2004 IME-USP / PUC-Rio
Copyright © 2004 IME-USP/PUC-Rio. All rights reserved.
Page 3
Tutorial do MobiCS
necessária nenhuma alteração no protocolo que foi desenvolvido, mas apenas modificar a classe Simulation ( ../api/mobics/
simulation/Simulation.html) .
4.2 Os Parâmetros de Simulação e a Criação de um Elemento
Toda a simulação deve criar objetos que representam os elemento simulados, desde estações móveis até canais de
comunicação. No exemplo do RDP, para se criar uma estação móvel utilizou-se o comando
mh = new MyMh("Mh",sim);
Na simulação estocástica será necessário acrescentar mais um parâmetro no construtor do objeto que será seu modelo de
simulação. O exemplo poderia então ser substituído por
mh = new MyMh("Mh",sim, new MySimulationModel(p1,p2,p3));
onde p1, p2 e p3 são os três parâmetros utilizados para o modelo de simulação. Assim, a classe MySimulationModel
define um modelo de simulação e p1, p2 e p3 os parâmetros de simulação do Mh. Observe que esse parâmetros
poderiam estar embutidos na implementação da classe MyMh e a chamada do construtor poderia ser como a
anterior. Caso não seja utilizado esse parâmetro, será criado um modelo de simulação nulo, no qual o elemento
de comporta de maneira passiva, ou seja, não gera nenhum evento (cf. os construtores de Mh ( ../api/mobics/
network/Mh.html#Mh(java.lang.String,%20mobics.simulation.Simulator)) e Mss ( ../api/mobics/network/
Mss.html#Mss(java.lang.String,%20mobics.simulation.Simulator,%20mobics.network.Cell)) )
Da mesma forma como os elementos, o construtor dos canais de simulação também precisa receber como parâmetro o seu
modelo de simulação. Só que no caso de canais, o modelo não define a geração de eventos internos, mas o desempenho do
canal, sua taxa de envio de dados. No caso de canais WiredLink, esse modelo de simulação é trivial e deve indicar a taxa de
envio de dados pelo canal para cada mensagem. O caso dos canais WirelessLink pode ser um pouco mais complicado, pois a
taxa de envio de dados é dependente da distância entre Mss e Mh e da própria mobilidade do Mh; entretanto para descrever
esse modelo no 2o. EP, essas informações não serão utilizadas e esse canal terá uma taxa fixa de envio de dados tal como um
canal WiredLink.
4.3 A Criação dos Modelos de Simulação
Conforme comentado anteriormente, para realizar uma simulação estocástica é necessário definir, no mínimo, dois modelos de
simulação: um para os canais de comunicação e outro para os elementos de rede simulados.
4.3.1 Para canais de comunicação
Um modelo de simulação para canais de simulação é bastante simples. Sua única função é definir o atraso associado ao envio
de uma mensagem dada. Quando um modelo é associado a um canal, ele é chamado durante o envio de cada mensagem para
calcular o atraso de envio da mensagem e determinar o timestamp da mensagem quando ela chega ao destinatário.
Para definir um modelo basta implementar uma subclasse de LinkSimModel ( ../api/mobics/simulation/
models/LinkSimModel.html) , que implementa o método delaySend ( ../api/mobics/simulation/models/
LinkSimModel.html#delaySend(mobics.network.NetMessage)) . que recebe como parâmetro a mensagem de rede NetMessage
( ../api/mobics/network/NetMessage.html) a ser enviada. O método deve retornar um long que indica o atraso referente ao
envio daquela mensagem.
O programador do modelo de simulação define a complexidade do seu modelo, de acordo com as
características que deseja simular. Tipicamente, o método delaySend ( ../api/mobics/simulation/models/
LinkSimModel.html#delaySend(mobics.network.NetMessage)) retorna um valor proporcional ao tamanho da mensagem e
associado ao throughput do canal (que é um parâmetro de simulação a ser recebido no construtor do modelo de simulação).
Para canais de comunicação sem fio, a implementação pode ser bastante complexa. O modelo, além de avaliar o tamanho da
mensagem a ser enviada, pode avaliar como a distância entre emissor e receptor da mensagem influencia nesse atraso.
© 2000-2004 IME-USP / PUC-Rio
Copyright © 2004 IME-USP/PUC-Rio. All rights reserved.
Page 4
Tutorial do MobiCS
4.3.2 Para elementos de rede simulados
A definição de modelos de simulação para elementos de rede é mais complexa que para canais de comunicação. O diagrama
básico do modelo de simulação, que daqui para frente será chamado de gerador de eventos, está mostrado na figura abaixo.
O modelo de simulação é implementado em uma subclasse de EventGenerator ( ../api/mobics/simulation/models/
EventGenerator.html) . Esse gerador de eventos é responsável por criar os eventos de simulação internos do elemento e
adicioná-los à fila de eventos EventQueue ( ../api/mobics/simulation/models/EventQueue.html) . Esses eventos são retirados da
fila pela camada de simulação e executados.
A geração dos eventos é feita no método run() ( ../api/mobics/simulation/models/EventGenerator.html#run())
do gerador de eventos. Há duas formas de fazê-lo: adicionando os elementos da fila de eventos já ordenados
segundo o seu timestamp (usando o método EventQueue.putEvent(SimEvent)) ( ../api/mobics/simulation/
models/EventQueue.html#pushEvent(mobics.simulation.models.SimEvent)) ou adicionar os eventos fora
de ordem (usando o método EventQueue.putAsynchEvent(SimEvent)) ( ../api/mobics/simulation/models/
EventQueue.html#pushAsynchEvent(mobics.simulation.models.SimEvent)) e depois indicar o término da geração de eventos
ou um timestamp limite até onde os eventos estão ordenados (método EventQueue.setCurrentLimitTimer(long)) ( ../api/
mobics/simulation/models/EventQueue.html#setCurrentLimitTimer(long)) .
O timerScheduler ( ../api/mobics/simulation/models/EventGenerator.html#timerScheduler) auxilia o programador
a definir geração de eventos periódicos. O programador do modelo de simulação pode adicionar um modelo de
geração de evento, subclasse de EventModel ( ../api/mobics/simulation/models/EventModel.html) , ao timerScheduler
informando qual é o período de geração do evento (cf. método TimerScheduler.addEvent(long, SimEvent)) ( ../api/
mobics/simulation/models/TimerScheduler.html#addEvent(long,%20mobics.simulation.models.EventModel)) . Neste
períodos o timerScheduler irá executar o método EventModel.generateEvent(Element) ( ../api/mobics/simulation/models/
EventModel.html#generateEvent(mobics.network.Element)) que irá retornar um novo evento de simulação (por exemplo uma
nova migração) ou um null, indicando que nenhum evento será gerado naquele timestamp (o método pode testar de acordo
com uma probabilidade dada e o gerador de números aleatórios, se um novo evento será gerado ou não; no caso de eventos
realmente periódicos um novo evento será gerado sempre que o scheduler chamar o método).
Há ainda um gerador de número aleatórios ( ../api/mobics/simulation/models/RandomGenerator.html) que pode auxiliar na
programação no modelo de geração de eventos.
© 2000-2004 IME-USP / PUC-Rio
Copyright © 2004 IME-USP/PUC-Rio. All rights reserved.
Page 5
Tutorial do MobiCS
4.4 Etapas de Implementação da Simulação
Para implementar uma simulação estocástica devem ser seguidos o seguintes passos:
1.
2.
3.
4.
5.
6.
7.
8.
Definir todos os parâmetros de simulação e como os eventos serão gerados a partir desses parâmetros.
Implementar subclasses de LinkSimModel ( ../api/mobics/simulation/models/LinkSimModel.html) que definir os modelos
de simulação dos canais de comunicação, tanto wireless como wired. Implementar os respectivos métodos delaySend ( ../
api/mobics/simulation/models/LinkSimModel.html#delaySend(mobics.network.NetMessage)) .
Implementar subclasses de EventGenerator ( ../api/mobics/simulation/models/EventGenerator.html) que definem os
modelos de simulação para cada um dos elementos simulados com diferente modelo de simulação.
1. Declarar uma subclasse de EventModel ( ../api/mobics/simulation/models/EventModel.html) para cada tipo de evento
a ser gerado periodicamente. Implementar seu método EventModel.generateEvent(Element) ( ../api/mobics/simulation/
models/EventModel.html#generateEvent(mobics.network.Element)) .
2. Adicionar todos os modelos de eventos criados acima no timerScheduler ( ../api/mobics/simulation/models/
EventGenerator.html#timerScheduler) , no código do construtor do EventGenerator ( ../api/mobics/simulation/models/
EventGenerator.html) indicando o timestamp periódico em que a tarefa deve ser testada OU
3. Modificar o método run() ( ../api/mobics/simulation/models/EventGenerator.html#run()) do gerador de eventos,
indicando todos os eventos a serem incluidos na EventQueue ( ../api/mobics/simulation/models/EventQueue.html) e
modificar o timestamp limite dos eventos ordenados quando for necessário.
Criar uma simulação estocástica em uma subclasse de StochSimulation ( ../api/mobics/simulation/StochSimulation.html) ,
assim como feito anteriormente com uma simulação determinística.
Criar objetos dos modelos de simulação criados, passando-os como parâmetro dos construtores dos canais e elementos
simulados. Todos esses objetos devem ser criados na classe simulação estocástica.
Na aplicação executar o método StochSimulation.start() ( ../api/mobics/simulation/StochSimulation.html#start()) para
iniciar a simulação.
Avaliar o resultado obtido
Testar para outros parâmetros de simulação.
4.5 Exemplo
No diretório do RDP ( http://www.ime.usp.br/~rcarocha/mobics/exemplo/) há também um exemplo de simulação estocástica.
5 Detalhes sobre Implementação de Protocolos
5.1 Endereços de Hosts
Toda máquina de rede simulada possui um endereço, declarado como um objeto da classe Address ( ../api/mobics/network/
Address.html) . Esse endereço é um identificador único e está relacionado à interface de rede com a qual o elemento envia
mensagens para outra máquina. Mh's também possuem um endereço que identifica a sua interface de rede sem fio e para a qual
o MSS responsável pode enviar mensagens.
Atenção
Esse endereço não pode ser usado por outras máquinas da rede para enviar mensagens para o Mh, pois é um endereço de interface sem fio e
não existe nenhum método de reencaminhamento de mensagens (como o protocolo RDP) previamente utilizado nos elementos simulados.
Para obter o endereço de qualquer elemento de rede, basta chamar o método getAddress ( ../api/mobics/network/
Element.html#getAddress()) , declarado na classe Element ( ../api/mobics/network/Element.html) .
O envio de mensagens é feito sempre com o método send(Address, Message) ( ../api/mobics/network/
Element.html#send(mobics.network.Element,%20mobics.ppi.message.Message)) . Caso a mensagem não possa ser
enviada para o endereço fixo indicado, o método retorna a exceção HostNotReachedException ( ../api/mobics/exception/
HostNotReachedException.html) , o que é válido apenas para o envio entre máquinas fixas de rede como, por exemplo,
entre Mss's. No caso de envio de mensagens pelo canal sem fio (entre Mss e Mh), a primitiva send não é confiável e ela não
© 2000-2004 IME-USP / PUC-Rio
Copyright © 2004 IME-USP/PUC-Rio. All rights reserved.
Page 6
Tutorial do MobiCS
garante que o endereço utilizado é correto ou que o Mh está na célula no momento do envio. Para se ter garantias quanto ao
envio de mensagens pelo meio sem fio, deve-se adicionar confirmações ao protocolos ou utilizar o método rSend ( http://
www.lcpd.ime.usp.br/~mobics/rsend) , que implementa uma confirmação simples do recebimento da mensagem. Caso a
mensagens não tenha sido recebida, é recebida a exceção MessageNotAcknowledged ( http://www.lcpd.ime.usp.br/~mobics/
g) (observe que a própria mensagem de confirmação pode ser perdida). O método send ( http://www.lcpd.ime.usp.br/~mobics/
g) e rSend ( http://www.lcpd.ime.usp.br/~mobics/g) para Mh's só contém o parâmetro Message, já que um Mh só pode enviar
mensagens para o seu Mss responsável.
Não há nenhum protocolo previamente adicionado aos elementos de uma rede simulada no MobiCS, nem mesmo protocolos
de encaminhamento de mensagens pela rede fixa. Por isso, uma máquina fixa como um Mss, só pode enviar mensagens
diretamente para as máquinas fixas para as quais possuem canais WiredLink ( ../api/mobics/network/WiredLink.html) .
Para realizar um broadcast de uma mensagem, basta colocar como destinatário da mensagem o endereco Address.bCast
( ../api/mobics/network/Address.html#bCast) , que é um endereço estático do tipo BCastAddress ( ../api/mobics/network/
BCastAddress.html) declarado na classe Address ( ../api/mobics/network/Address.html) . Esse tipo de endereço é válido tanto
para realizar broadcasts pelo meio conectado como pelo meio sem fio. É importante observar que no caso de um broadcast
pela rede fixa, uma máquina envia mensagens apenas para as demais máquinas conectadas a ela por canais WiredLink ( ../api/
mobics/network/WiredLink.html) .
Em scripts determinísticos é possível enviar mensagens usando apenas a referência ao elemento simulado, ao invés de seu
endereço. Por exemplo, ao invés de send(mss1.getAddress(),mesg1) pode-se usar send(mss1,mesg1).
5.2 Criação de Mensagens
Na declaração de mensagens duas coisas nunca devem ser esquecidas. A primeira delas é chamar o construtor de Message
( ../api/mobics/ppi/message/Message.html) , passando como parâmetro a classe (com extensão .class) do protocolo que
é responsável por manipular aquele tipo de mensagem. No exemplo do RDP, na declaração da mensagem PList ( http://
www.ime.usp.br/~rcarocha/mobics/exemplo/sidam/rdp/messages/PList.java) há uma chamada super(RDPMss.class)
no construtor da mensagem, indicado que a classe RDPMss implementa o tratamento da mensagem. Caso isso não
seja feito, quando o Mss receber a mensagem, será gerada a exceção MsgHandleException ( ../api/mobics/exception/
MsgHandleException.html) .
Outra informação que não deve ser esquecida diz respeito ao handler da mensagem. A classe Message ( ../
api/mobics/ppi/message/Message.html) implementa um método callHandler ( ../api/mobics/ppi/message/
Message.html#callHandler(mobics.ppi.protocol.Protocol)) , que é responsável por definir qual é o método do objeto protocolo
responsável por tratar aquela mensagem. No caso do exemplo citado acima, callHandler define qual o método do objeto da
classe RDPMss.class que será chamado quando o elemento receber a mensagem PList.
A classe Message implementa uma funcionalidade básica para o método, na qual é chamado o método do protocolo que
possui exatamente o mesmo nome da classe da mensagem recebida. No exemplo, o método chamado será PList (observe que a
assinatura do método deve ser idêntica à da classe, obedecendo o uso de maiúsculas e minúsculas). O usuário pode definir um
novo método como handler da mensagem, bastanto para isso reimplementar o método callHandler. No exemplo da mensagem
PList, para associar como handler da mensagem o método pList2, basta adicionar a seguinte declaração de método na classe
PList:
public void callHandler(Protocol prot){
((RDPMss) prot).pList2(this);
}
Usando o callHandler default, caso o método handler não exista é gerada a exceção durante a simulação. No caso acima, erro
ocorre durante a compilação da classe PList.
© 2000-2004 IME-USP / PUC-Rio
© 2000-2004 IME-USP / PUC-Rio
Copyright © 2004 IME-USP/PUC-Rio. All rights reserved.
Page 7