UNIVERSIDADE DO VALE DO RIO DOS SINOS
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE INFORMÁTICA - HABILITAÇÃO EM ANÁLISE DE SISTEMAS
Implementação de Mecanismos de
Busca, Cópia e Reuso de Traços de
Protocolos na Plataforma de
Gerenciamento Trace
por
RODRIGO ARGENTA
Prof. Dr. Luciano Paschoal Gaspary
Orientador
São Leopoldo, novembro de 2002.
2
Sumário
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
6
7
7
1.1
1.2
1.3
1.4
Contextualização . . . . . . . . . . .
Motivação e definição do problema
Objetivos . . . . . . . . . . . . . . . .
Organização do trabalho . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 A plataforma Trace . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 A linguagem PTSL . . . . . . . . . . . . . . . .
2.1.1
Graphical PTSL . . . . . . . . . . . . . . . . . .
2.1.2
Textual PTSL . . . . . . . . . . . . . . . . . . .
2.2 A arquitetura . . . . . . . . . . . . . . . . . . .
2.3 A aplicação de gerenciamento . . . . . . . . .
2.3.1
Processo convencional de especificação de traços
2.3.2
Modelo de dados da aplicação de gerenciamento
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
9
11
12
12
17
3 Mecanismos incorporados à aplicação de gerenciamento 18
3.1
3.2
3.3
Mecanismo de busca de traços . . . . . . . . . . . . . . . . . . . . . 18
Mecanismo de cópia de traços . . . . . . . . . . . . . . . . . . . . . 20
Mecanismo de reuso de traços . . . . . . . . . . . . . . . . . . . . . 21
4 Experimentação dos mecanismos implementados . . . . 25
4.1
4.2
Metodologia utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1
5.2
Contribuições do trabalho . . . . . . . . . . . . . . . . . . . . . . . 28
Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Anexo 1 Roteiro de experimentação . . . . . . . . . . . . . . . 30
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3
Lista de Figuras
FIGURA 1.1 – Requisição de uma página web inválida . . . . . . . . . . . . .
FIGURA 1.2 – Representação gráfica de um traço . . . . . . . . . . . . . . . .
FIGURA 1.3 – Traço de requisições HTTP com retorno de página não encontrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
2.1 – Formato de uma especificação T-PTSL . . . . . . . . .
2.2 – Componentes da arquitetura Trace . . . . . . . . . . .
2.3 – Interface do mecanismo de gerenciamento de traços . .
2.4 – Interface de identificação de traços . . . . . . . . . . .
2.5 – Interface de inserção de campos de mensagens . . . . .
2.6 – Interface de detalhamento de campos de mensagens . .
2.7 – Interface de inserção de mensagens . . . . . . . . . . .
2.8 – Interface de detalhamento de mensagens . . . . . . . .
2.9 – Interface de inserção de agrupamentos de mensagens .
2.10 – Interface de detalhamento de agrupamentos . . . . . .
2.11 – Interface de visualização da máquina de estados . . .
2.12 – Interface de transições da máquina de estados . . . . .
2.13 – Interface de criação de estados . . . . . . . . . . . . .
2.14 – Interface de visualização integral das caracterı́sticas do
2.15 – Modelo E-R original da aplicação de gerenciamento .
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
3.1
3.2
3.3
3.4
3.5
3.6
FIGURA
FIGURA
FIGURA
FIGURA
–
–
–
–
–
–
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
traço
. . . .
Interface do mecanismo de busca de traços . . . . . . . .
Utilização do mecanismo de busca com a palavra “http”
Utilização do mecanismo de cópia . . . . . . . . . . . . .
Traço criado com o mecanismo de reuso . . . . . . . . . .
Utilização do mecanismo de reuso . . . . . . . . . . . . .
Modelo E-R da aplicação de gerencimento utilizado para
portar o mecanismo de reuso . . . . . . . . . . . . . . . .
3.7 – Implementação das listas encadeadas . . . . . . . . . . .
3.8 – Interface alterada para suportar reuso de traços . . . . .
3.9 – Máquina de estados suportando reuso (Layer 0 ) . . . . .
3.10 – Máquina de estados suportando reuso (Layer 1 ) . . . .
. .
. .
. .
. .
. .
su. .
. .
. .
. .
. .
5
6
7
10
11
12
12
13
13
13
14
14
14
15
15
16
16
17
.
.
.
.
.
18
19
20
22
22
.
.
.
.
.
23
23
23
24
24
FIGURA 4.1 – Tempo gasto pelos usuários para a realização completa do roteiro
FIGURA 4.2 – Tempo dispendido pelos usuários do grupo 1 na criação de
cada um dos traços . . . . . . . . . . . . . . . . . . . . . . . .
FIGURA 4.3 – Tempo dispendido pelos usuários do grupo 2 na criação de
cada um dos traços . . . . . . . . . . . . . . . . . . . . . . . .
FIGURA 4.4 – Taxa de utilização dos mecanismos pelos usuários do grupo 2 .
26
26
26
27
4
Resumo
O crescimento das redes de computadores tem sido uma constante nos últimos
anos, bem como o aumento do número de protocolos e aplicações que nelas trafegam.
Esse fato tem imposto alguns desafios para os gerentes de rede quanto ao monitoramento do tráfego, pois cada vez mais protocolos novos ou desconhecidos trafegam
livremente, causando problemas como congestionamento e invasões por indivı́duos.
Com a explosão do número de protocolos disponı́veis passa a ser crı́tica a definição dos cenários a serem monitorados. A plataforma Trace foi desenvolvida para
gerenciamento de protocolos de alto nı́vel e uma de suas funcionalidades é a criação
de traços de protocolos (cenários). O volume de traços criados na plataforma tende
a crescer muito com o passar do tempo, fazendo com que a busca e a identificação
de traços tornem-se tarefas gradativamente mais dispendiosas. Soma-se a esse problema a ausência na plataforma de mecanismos que permitam agilizar o processo
de especificação de novos traços, obrigando o gerente da rede a iniciar, sempre “do
zero”, uma nova especificação. Para amenizar esses problemas, foi realizada a implementação de mecanismos de busca, cópia e reuso de traços na plataforma de
gerenciamento Trace, bem como um estudo de caso com usuários da plataforma
identificando alguns benefı́cios proporcionados pela implementação dos mecanismos
desenvolvidos.
Palavras-chave: Gerenciamento de redes de computadores, busca, reuso.
5
1
1.1
Introdução
Contextualização
A plataforma Trace foi desenvolvida para o gerenciamento de protocolos de
alto nı́vel, serviços e aplicações em rede [GAS 2002a, TRA 2002]. Uma das funcionalidades primárias da plataforma é a criação de traços (interações entre um ou mais
protocolos de alto nı́vel), os quais são especificados utilizando-se a linguagem PTSL
(Protocol Trace Specification Language)[GAS 2001a, GAS 2001b, GAS 2001c]. A
linguagem PTSL baseia-se no conceito de máquinas de estados finitos, permitindo
que sejam modeladas seqüências de trocas de pacotes que, quando observados na
rede, indicam a ocorrência de eventos. Um traço representa essa troca de pacotes
(mensagens) entre duas estações interconectadas. Quando as mensagens especificadas em um traço são verificadas entre duas estações, fica caracterizada a ocorrência
deste traço. Por exemplo, quando se utiliza um navegador web para acessar alguma página é necessário o envio de uma requisição de uma página ou documento
ao servidor que possui o conteúdo desejado. Essa requisição é precedida por um
comando chamado GET, o qual significa que o usuário está requisitando ao servidor
que uma página seja visualizada em seu navegador. Para isso é enviado ao servidor
uma mensagem com um comando do tipo GET ./pagina.html. Se a requisição for
validada pelo servidor, a página será visualizada no navegador; caso contrário será
retornada uma mensagem com o código HTTP/1.1 400 indicando que a requisição
é inválida. A figura 1.1 ilustra o exemplo citado. Com a utilização da plataforma
Trace, a ocorrência desse e outros traços (definidos pelo gerente de rede) pode ser
monitorada. Essas informações podem então ser usadas para o gerenciamento de
falhas, configuração, contabilização, desempenho e segurança.
Mensagem “GET”
Web Browser
Servidor
Web
Retorno HTTP/1.1 400
FIGURA 1.1 – Requisição de uma página web inválida
Para criar um traço que verifique a situação da figura 1.1, é necessária a
criação de uma especificação que analise na rede as trocas de mensagens entre duas
estações, buscando nas mesmas as requisições GET e os códigos de retorno enviados
posteriormente pelo servidor. Quando um navegador receber o código de retorno
HTTP/1.1 400 após uma requisição GET, será verificada a ocorrência deste traço.
O traço ilustrado pela figura 1.2 descreve, através da linguagem PTSL, o
exemplo supracitado. Como pode ser observado, o traço possui um estado inicial
chamado idle que também possui uma transição de saı́da (GET) conectada ao estado
6
Traço “Requisição HTTP inválida”
GET
idle
2
Version: 1.0
Description: Acesso HTTP inválido
Key: HTTP, 400, inválido
Port: 80
Owner: Rodrigo Argenta
Last Update: Fri, 25 Sep 2002 21:45:00 GMT
HTTP/1.1 400
FIGURA 1.2 – Representação gráfica de um traço
2. O estado 2, por sua vez, se conecta de volta ao estado idle através de uma
transição de retorno (HTTP/1.1 400).
A plataforma Trace possui um agente de monitoração que utiliza as especificações definidas em um traço para contabilizar a sua ocorrência no tráfego de rede.
Considerando que o agente esteja programado para monitorar a ocorrência do traço
ilustrado na figura 1.2, a sua contabilização ocorre quando uma mensagem GET for
verificada na rede, fazendo com que a máquina de estados evolua do estado idle para
o estado 2. De forma análoga, quando uma mensagem HTTP/1.1 400 for verificada
entre os mesmos pares de estações que originaram a mensagem inicial, a máquina
de estados evolui do estado 2 para o estado idle que neste caso também é o estado
final. Com a máquina de estados chegando ao seu fim, a ocorrência desse traço é
contabilizada em uma base de dados que será consultada futuramente pela estação
de gerenciamento.
1.2
Motivação e definição do problema
Na seção anterior foi citado que uma das funcionalidades da plataforma é a
criação de traços. Depois de criados, esses traços ficam armazenados em uma base
de dados, onde ficam disponı́veis para manutenção, consulta e exclusão. Com o
passar do tempo o volume de traços criados na plataforma tende a crescer significativamente, e a busca e a identificação de traços tende a se tornar uma tarefa
dispendiosa. Por exemplo, quando o gerente de rede deseja verificar se determinado
traço tem o objetivo de analisar requisições HTTP inválidas, ele deve procurar uma
a uma as especificações previamente cadastradas que contenham as caracterı́sticas
ilustradas na figura 1.2. Esta tarefa pode tomar um tempo elevado se a base de
traços for relativamente grande e possuir traços com caracterı́sticas semelhantes.
Além desse problema, o processo de especificação de traços não permite o
reaproveitamento de especificações desenvolvidas anteriormente, mesmo que exista
na base de dados uma especificação praticamente igual a que se deseja criar. Se na
base de traços existir uma especificação que possua caracterı́sticas que podem ser
reutilizadas em um novo traço, este deverá ser criado a partir de seu ponto inicial,
não existindo nenhum meio de copiar ou reusar a especificação já existente. Por
exemplo, o traço “Requisição HTTP página não encontrada” ilustrado na figura
1.3 é praticamente igual ao traço ilustrado na figura 1.2, alterando-se somente a
7
mensagem HTTP/1.1 400 para HTTP/1.1 404. No entanto, o processo tradicional
de especificação de traços requer que esse novo traço seja criado a partir de seu
ponto inicial.
Traço “Requisição HTTP página não encontrada”
GET
idle
2
Version: 1.0
Description: Acesso HTTP com página não
encontrada
Key: HTTP, 404, página
Port: 80
Owner: Rodrigo Argenta
Last Update: Fri, 26 Sep 2002 20:48:00 GMT
HTTP/1.1 404
FIGURA 1.3 – Traço de requisições HTTP com retorno de página não encontrada
1.3
Objetivos
Diante dessa problemática, este trabalho teve como objetivos implementar
mecanismos de busca, cópia e reuso de traços e realizar um experimento junto a
usuários da plataforma, procurando identificar alguns benefı́cios proporcionados pela
implementação dos mecanismos.
1.4
Organização do trabalho
O trabalho está organizado da seguinte forma: o capı́tulo 2 descreve a plataforma Trace incluindo a linguagem PTSL, a arquitetura da plataforma e a aplicação
de gerenciamento. O capı́tulo 3 detalha o projeto e a implementação dos mecanismos de busca, cópia e reuso de traços. O capı́tulo 4 apresenta uma validação das
implementações realizadas na plataforma. O capı́tulo 5 encerra o trabalho com as
conclusões obtidas no desenvolvimento deste trabalho e com perspectivas de trabalhos futuros.
8
2
A plataforma Trace
O motivo deste trabalho foi contextualizado no capı́tulo anterior juntamente
com alguns conceitos de funcionamento da plataforma Trace. Como já explicitado, a
plataforna foi desenvolvida para o gerenciamento de protocolos de alto nı́vel, serviços
e aplicações em rede. O gerenciamento e o monitoramento dos protocolos é feito
através de elementos que auxiliam no funcionamento da plataforma como gerentes
intermediários, agentes de monitoração e agentes de ação, que são administrados
por um gerente de rede através de uma aplicação de gerenciamento. Os agentes de
monitoração utilizam as especificações PTSL para realizar a monitoração e contabilização de traços, bem como a execução de tarefas de configuração, gerenciamento
de falhas, desempenho e segurança.
Neste capı́tulo serão apresentados os componentes que fazem parte desta plataforma. Na seção 2.1 será abordada a linguagem PTSL. Na seção 2.2 a arquitetura
Trace será abordada e na seção 2.3 a aplicação de gerenciamento.
2.1
A linguagem PTSL
A linguagem PTSL baseia-se no conceito de máquina de estados finitos, possui
componentes gráficos e textuais e, por essa razão, foi dividida em Graphical e Textual PTSL. As linguagens não possuem equivalência. A linguagem textual permite
a representação completa de um traço, incluindo a especificação da máquina de estados e as mensagens que provocam as transições. A linguagem gráfica, por sua vez,
equivale a um sub-conjunto da textual, oferecendo a possibilidade de representar
pictoricamente a máquina de estados e, em um alto grau de abstração, de identificar
as transições (mensagens). É possı́vel especificar um traço completo, de forma textual, sem fazer o uso de Graphical PTSL, mas o contrário não é possı́vel, uma vez
que não há como mapear toda a sintaxe textual para sintaxe gráfica [GAS 2002b].
Especificações PTSL alimentam agentes de monitoração que capturam pacotes do segmento de rede onde se encontram, observando a ocorrência dos traços.
Dessa forma, nas especificações não é necessário definir a origem e o destinatário
do traço. Todas as ocorrências do traço entre quaisquer pares de estações serão
devidamente armazenadas e contabilizadas. Mais informações sobre esse processo
são apresentadas na seção 2.2, que descreve a arquitetura Trace.
2.1.1
Graphical PTSL
Conforme já mencionado, Graphical PTSL (G-PTSL) permite a definição parcial de um traço de protocolo. Através de uma máquina de estados, o gerente da rede
pode criar uma especificação para monitorar todo ou apenas parte de um protocolo,
ou ainda, interações abrangendo mais de um protocolo [MEN 2002].
A notação gráfica oferece um construtor onde são incluı́das informações sobre o
traço, que são relevantes para a catalogação e o controle de versão das especificações.
As informações armazenadas para um traço são:
• Version: versão da especificação;
• Description: breve comentário a respeito do traço;
9
• Key: palavras-chave relacionadas ao traço;
• Port: indica a porta TCP ou UDP do protocolo a ser monitorado;
• Owner : identificação do indivı́duo que especificou o traço;
• Last Update: data e hora da última atualização da especificação.
Os elementos básicos que fazem parte da especificação de um traço são:
• Estado: descreve o estado atual de um processo cliente;
• Mensagem cliente: responsável por fazer o processo cliente mudar de estado;
essa mensagem é enviada pelo próprio processo cliente (ex: mensagem GET
do traço ilustrado na figura 1.2);
• Mensagem servidor : responsável por fazer o processo cliente mudar de estado;
essa mensagem é enviada pelo processo servidor (ex: mensagem HTTP/1.1
400 do traço ilustrado na figura 1.2);
• Agrupamento: quando duas ou mais mensagens distintas podem causar a
transição de um mesmo estado para outro, elas são agrupadas. Neste caso,
a transição ocorrerá se qualquer uma das mensagens agrupadas for observada
na rede.
Um traço inicia sempre a partir de um estado inicial denominado idle. A
partir daı́ podem ser criados outros n estados, desde que os mesmos sejam sempre
atingidos por alguma mensagem ou agrupamento (não é permitida a criação de
estados inalcançáveis). O traço encerra no estado final que é representado por dois
cı́rculos concêntricos.
Os estados são representados por cı́rculos identificados; as mensagens do cliente são representadas por setas contı́nuas e as mensagens oriundas do servidor são
representadas por setas pontilhadas.
Os textos que identificam as mensagens ou agrupamentos indicam, em um
alto grau de abstração, os pacotes que precisam ser observados para que a máquina
de estados evolua. Na representação gráfica, contudo, não é possı́vel descrever em
detalhe as propriedades que o pacote precisa ter para causar a transição. As figuras
1.2 e 1.3 ilustram a representação gráfica de um traço em G-PTSL.
2.1.2
Textual PTSL
Como já comentado na inı́cio desta seção, a linguagem Graphical PTSL (GPTSL) é um subconjunto da linguagem Textual PTSL (T-PTSL), não representando
em detalhes todas as caracterı́sticas de um traço. A linguagem T-PTSL pode representar um traço de forma detalhada, especificando-se todas as caracterı́sticas
necessárias para que a máquina de estados evolua.
A figura 2.1 ilustra o formato de uma especificação em T-PTSL. O exemplo
usado é o mesmo que foi ilustrado na figura 1.2. A especificação de um traço inicia
com a palavra-chave Trace e termina com EndTrace (linhas 1 e 42). De forma
análoga à notação gráfica, num primeiro momento o gerente deve informar o nome
do traço e, opcionalmente, os campos Version, Description, Key, Port, Owner e
Last Update (linhas 3 a 8). Em seguida, a especificação é dividida em três seções:
10
MessagesSection (linhas 10 a 23), GroupsSection (linhas 25 a 27) e StatesSection
(linhas 29 a 40).
1
Trace "Requisiç~
ao HTTP inválida"
2
3
4
5
6
7
8
Version: 1.0
Description: Acesso HTTP com resposta 400
Key: HTTP, 400, inválida
Port: 80
Owner: Rodrigo Argenta
Last Update: 2002-09-30 19:54:41
9
10
MessagesSection
11
12
13
14
15
Message "GET"
MessageType: client
FieldCounter Ethernet/IP 0 GET "Requisiç~
ao de uma página Web"
EndMessage
16
17
18
19
20
21
Message "HTTP/1.1 400"
MessageType: server
FieldCounter Ethernet/IP 0 HTTP/1.1 "Vers~
ao do Protocolo"
FieldCounter Ethernet/IP 1 400 "Código de retorno"
EndMessage
22
23
EndMessagesSection
24
25
GroupsSection
26
27
EndGroupsSection
28
29
30
StatesSection
FinalState idle
31
32
33
34
State idle
"GET" GotoState 2
EndState
35
36
37
38
State 2
"HTTP/1.1 400" GotoState idle
EndState
39
40
EndStatesSection
41
42
EndTrace
FIGURA 2.1 – Formato de uma especificação T-PTSL
Em MessagesSection são definidas as mensagens que causarão a evolução do
traço. Quando duas ou mais mensagens causam a transição de um mesmo estado
para outro, é possı́vel agrupá-las, tornando a especificação mais clara. Esses agrupamentos são definidos na seção GroupsSection. Por fim, na seção StatesSection é
definida a máquina de estados que representa o traço.
A evolução da máquina de estados ocorre quando um pacote com campos
idênticos aos especificados em uma mensagem cliente (client) ou servidor (server )
11
é observado na rede. No exemplo apresentado na figura 2.1, a máquina de estados
evolui do estado idle para o estado 2 ao observar uma mensagem GET. Nesse
caso, é preciso identificar apenas um campo, o GET, que pode ser feito indicando
a posição do mesmo (0) a partir do inı́cio do campo de dados do protocolo TCP. A
máquina de estados continua sua evolução quando uma mensagem HTTP/1.1 400
é observada entre os mesmos pares de estações que originaram a mensagem GET.
Assim a máquina de estados evolui para o estado idle fazendo com que o traço chegue
ao seu fim, contabilizando a sua ocorrência no agente de monitoração. Informações
detalhadas sobre a linguagem podem ser obtidas em [GAS 2002a, GAS 2002b].
2.2
A arquitetura
A arquitetura de gerenciamento Trace é uma infra-estrutura centralizada de
gerenciamento de redes para, através de um modelo em três camadas, suportar o
gerenciamento hierárquico de protocolos de alto nı́vel, serviços e aplicações em rede
[GAS 2002b]. A figura 2.2 ilustra os componentes da arquitetura Trace. A arquitetura oferece mecanismos para que, a partir de uma estação de gerenciamento, seja
possı́vel a delegação de tarefas de gerenciamento (scripts em Tcl) a gerentes intermediários que, por sua vez, interagem com agentes de monitoração e agentes de ação
para concretizá-las. Especificações PTSL são usadas pelos gerentes intermediários
para programar os agentes de monitoração, que passam a observar a ocorrência
dos traços. De posse de informações obtidas através da monitoração, os gerentes
intermediários podem requisitar a agentes de ação a execução de procedimentos
(scripts em Tcl, Java or Perl), viabilizando a automação de diversas tarefas de gerenciamento. A arquitetura apresenta ainda mecanismos de notificação (traps) para
que o gerente intermediário possa sinalizar a ocorrência de eventos signaficativos à
estação de gerenciamento. Trata-se de uma arquitetura hierárquica ou parcialmente
distribuı́da, onde existem relações de subordinação entre os componentes.
Estação de gerenciamento
banco de
dados
(PTSL,Java,
Perl, Tcl)
browser
(1)
servidor
web
(2)
PHP
(4)
Agente de monitoração
(3)
(20)
scripts
(PHP)
(11)
trap
notifier
agente
SNMP
(10)
(5)
(14)
(7)
(9)
agente
SNMP
MIB
Script
(12)
monitor PTSL
repositório
scripts
(PTSL)
(13)
MIB
RMON2
(19)
(17)
Agente de ação
(8)
scripts
(Java, Perl, Tcl)
(15)
agente (16)
SNMP
MIB
Script
Interpretador
Java, Perl , Tcl
MIB
Script
interpretador
Java, Perl , Tcl
(6)
(18)
scripts
(Java, Perl, Tcl)
Gerente intermediário
FIGURA 2.2 – Componentes da arquitetura Trace
O foco do trabalho é a aplicação de gerenciamento, a partir da qual o gerente
de rede administra as especificações criadas para monitorar o tráfego da rede. A
aplicação será explicitada na próxima seção.
12
2.3
A aplicação de gerenciamento
As seções anteriores apresentaram a linguagem PTSL e a arquitetura de gerencimento Trace. A presente seção apresenta o processo de especificação de traços
realizado na aplicação de gerenciamento utilizado antes da implementação deste trabalho em sua sub-seção 2.3.1 e o modelo de dados utilizado na plataforma em sua
sub-seção 2.3.2.
2.3.1
Processo convencional de especificação de traços
O mecanismo de gerenciamento de traços da plataforma Trace está baseado em
uma interface web onde todas as tarefas de criação e administração são realizadas.
A figura 2.3 ilustra a interface inicial do mecanismo de gerenciamento de traços.
FIGURA 2.3 – Interface do mecanismo de gerenciamento de traços
O processo de especificação de traços utilizado antes do desenvolvimento desse
trabalho é composto de algumas etapas que devem ser seguidas sempre que uma
nova especificação deseja ser criada. Para ilustrar todo processo de criação de uma
nova especificação apresenta-se a simulação de criação do traço “Requisição HTTP
inválida”, já ilustrado anteiormente. O processo inicia com o desejo do usuário de
criar um novo traço, selecionando “New” identificado na figura 2.3. Após esta ação
o usuário é direcionado para a interface de identificação do traço ilustrada na 2.4
onde devem ser informadas caracterı́sticas como, nome, versão, descrição, porta e
palavras-chave.
FIGURA 2.4 – Interface de identificação de traços
13
O processo de especificação prossegue com o usuário optando por “Next” que
o leva para a próxima interface, que é ilustrada na figura 2.5, onde são informados
os campos que fazem parte de cada uma das mensagens utilizadas pelo traço na
máquina de estados. As caracterı́sticas de campos de mensagens como tipo, posição,
tamanho e outras são definidas na interface ilustrada na figura 2.6.
FIGURA 2.5 – Interface de inserção de campos de mensagens
FIGURA 2.6 – Interface de detalhamento de campos de mensagens
Realizada esta ação, o usuário passa para a interface ilustrada na figura 2.7
onde são definidas as mensagens do traço. Optando por “New”, identificado nessa
figura, o usuário é levado à interface ilustrada na figura 2.8, onde são definidas as
caracterı́sticas de cada uma das mensagens que compõem o traço. Nessa interface
são definidos os campos, inseridos na interface da figura 2.5, que farão parte de cada
uma das mensagens do traço.
FIGURA 2.7 – Interface de inserção de mensagens
14
FIGURA 2.8 – Interface de detalhamento de mensagens
A seguir podem ser inseridos os agrupamentos de mensagens. A interface está
ilustrada na figura 2.9 e o detalhamento de cada agrupamento é ilustrado na figura
2.10, onde são definidos o nome do agrupamento e as respectivas mensagens que
podem fazer parte dele. As mensagens que cada agrupamento possuiu foram prédefinidas na interface de inserção de mensagens. Para esse traço não foram criados
agrupamentos.
FIGURA 2.9 – Interface de inserção de agrupamentos de mensagens
FIGURA 2.10 – Interface de detalhamento de agrupamentos
15
A próxima etapa do processo é a criação da máquina de estados. Para isso,
depois de realizar os agrupamentos de mensagens, o usuário é levado à interface
ilustrada na figura 2.11. Nessa interface, o usuário pode criar os estados e suas
transições referenciando mensagens ou agrupamentos previamente definidos.
FIGURA 2.11 – Interface de visualização da máquina de estados
Selecionando “New” identificado na figura 2.11, o usuário tem acesso a interface de criação de transições, definindo os estados e as mensagens ou agrupamentos
que deverão fazer com que a máquina de estados evolua. Essa interface é ilustrada
na figura 2.12. O usuário tem a opção para criação dos estados ao selecionar “...”
identificado na figura 2.12. A interface de criação dos estados está ilustrada na figura
2.13.
FIGURA 2.12 – Interface de transições da máquina de estados
16
FIGURA 2.13 – Interface de criação de estados
Depois da criação dos estados e de suas transições o usuário retorna para
a interface ilustrada na figura 2.11, onde ele pode visualizar o traço através da
linguagem G-PTSL. Por fim, pode-se verificar todas as caracterı́sticas do traço na
última interface de criação de especificações que é ilustrada na figura 2.14, onde
todos os campos de mensagens, mensagens, agrupamentos de mensagens, transições
e estados podem ser visualizados na forma de tabelas. Após este último passo, o
traço está finalmente criado e pode ser usado.
FIGURA 2.14 – Interface de visualização integral das caracterı́sticas do traço
17
2.3.2
Modelo de dados da aplicação de gerenciamento
A aplicação de gerenciamento de traços foi construı́da em uma base de dados
MySQL e seu modelo E-R (Entidade-Relacionamento) está ilustrado na figura 2.15.
Essa base de dados utiliza a seguinte estrutura para modelar as especificações:
• protocol trace: armazena as descrições do traço como nome, descrição,
versão, última atualização e usuário;
• keyword: armazena as palavras-chave do traço;
• message field: armazena as definições dos campos que serão utilizados em
cada mensagem como encapsulamento, posição, tamanho e valor esperado para
o campo;
• message: armazena as definições de cada mensagem do traço como nome, tipo
e timeout;
• message message field: associa mensagens com os campos de mensagens;
• grouper: armazena agrupamentos de mensagens;
• message grouper: associa mensagens a agrupamentos de mensagens;
• state: armazena a máquina de estados;
• transition: armazena as ligações entre os estados, definindo os estados que
serão conectados, bem como as mensagens ou agrupamentos que deverão fazer
parte de cada uma dessas ligações.
FIGURA 2.15 – Modelo E-R original da aplicação de gerenciamento
18
3 Mecanismos incorporados à aplicação de gerenciamento
O capı́tulo 2 apresentou a linguagem PTSL e a aplicação de gerenciamento original da plataforma Trace com exemplos de utilização de traços. Os mecanismos de
busca, cópia e reuso implementados na plataforma são apresentados neste capı́tulo.
A seção 3.1 apresenta o mecanismo de busca de especificações, a seção 3.2 apresenta
o mecanismo de cópia e a seção 3.3 finaliza o capı́tulo apresentando o mecanismo
de reuso.
3.1
Mecanismo de busca de traços
Uma das problemáticas apresentadas na introdução deste trabalho é a busca
e identificação de especificações quando o volume de traços armazenados na plataforma cresce à medida que o tempo passa. Para prevenir-se desses problemas,
justifica-se a implementação de um mecanismo de busca e identificação de traços
através de suas caracterı́sticas.
O mecanismo de busca proposto para a plataforma Trace baseia-se em ferramentas existentes na web atualmente como alguns sites de busca já bastante
conhecidos como exemplo os sites Google[GOO 2002] e Yahoo[YAH 2002]. O mecanismo permite que uma palavra seja informada e a busca seja realizada na base de
traços conforme algumas opções pré-selecionadas. As buscas podem ser executadas
com base nas principais caracterı́sticas de um traço: nome do traço, descrição de
um campo de mensagem, nome de um agrupamento de mensagens, descrição do
traço, palavras-chave, nomes de mensagens e nomes de estados. A figura 3.1 ilustra
a interface inicial de gerenciamento de traços que já foi ilustrada na figura 2.3 no
capı́tulo 2, agora modificada para suportar o mecanismo de busca de traços.
FIGURA 3.1 – Interface do mecanismo de busca de traços
A figura 3.1 ilustra o mecanismo de busca com a execução de uma consulta
realizada na base de traços utilizando-se do nome do traço como opção de busca.
A palavra de busca pode ser especificada com a ajuda do caracter coringa “percentual”, como mostra o campo “Search” identificado na figura 3.1. O mecanismo
19
realiza a busca trazendo todos os traços que possuam a palavra digitada pelo usuário
em qualquer posição das caracterı́sticas selecionadas. No exemplo ilustrado na figura 3.1, a busca foi realizada utilizando a palavra “requisição” seguida do caracter
coringa e a opção name (nome do traço) selecionada. Dessa forma, a busca trará
para a interface somente os traços que contenham a palavra de busca no inı́cio de seu
nome. A utilização do caractere coringa é opcional. Também foi implementado o
botão Show All, o qual configura o mecanismo de busca para trazer à interface todos
os traços existentes na base, deixando o campo Search sem palavras e as opções de
busca sem marcações para a realização de novas buscas.
O mecanismo permite que mais de uma opção de busca seja selecionada, isto
é, várias opções podem ser selecionadas para que a busca da palavra informada seja
executada com uma abrangência maior dentro da base de traços.
A figura 3.2 ilustra um exemplo de utilização do mecanismo de busca com
duas opções selecionadas. Neste caso as opções fields e description foram usadas
juntamente com a palavra “http” entre os caracteres coringas.
FIGURA 3.2 – Utilização do mecanismo de busca com a palavra “http”
Visto o funcionamento da interface, é importante descrever a forma de como
esse mecanismo foi implementado. Para realizar as buscas, o mecanismo relaciona
cada uma das opções de busca com a base de dados da seguinte forma:
• name: realiza a busca no campo name da tabela protocol trace;
• fields: procura pela descrição dos campos de mensagens no campo description
da tabela message field;
• groupers: quando selecionada realiza a busca pelo nome dos agrupamentos de
mensagens através do campo name da tabela grouper;
• description: procura pela descrição do traço no campo description da tabela
protocol trace;
• keyword : procura pelas palavras-chave do traço no campo word da tabela
keyword;
20
• message: realiza uma busca pelos nomes de mensagens no campo name da
tabela message;
• state: procura pelo nome dos estados no campo name da tabela state.
3.2
Mecanismo de cópia de traços
Durante o processo de especificação de traços o gerente de rede pode vir a
desenvolver uma especificação que é muito próxima de especificações existentes na
base de traços. A partir dessa observação a implementação de um mecanismo de
cópia tornou-se importante para o processo de especificação de traços. Através desse
mecanismo o gerente de rede pode realizar uma cópia completa e modificar esta nova
especificação sem comprometer a especificação original.
A figura 3.3 ilustra o funcionamento do mecanismo de cópia implementado na
plataforma Trace. Para utilizar o mecanismo, o usuário deve selecionar o traço que
deseja copiar na interface inicial de gerencimento de traços ilustrada na figura 3.1 e
após selecionar Copy identificado na figura 3.3, que o levará à interface que possibilita o processo de cópia de especificações. Opcionalmente, para realizar a seleção do
traço a ser copiado, o usuário pode utilizar o mecanismo de busca realizando uma
procura pelo traço a ser selecionado.
FIGURA 3.3 – Utilização do mecanismo de cópia
No exemplo da figura 3.3 o traço “Requisição HTTP 401” foi selecionado para
ser copiado. Após selecionar Copy, a interface de cópia de traços será visualizada
pelo usuário com a sugestão de nome para o traço que será copiado. A interface dá
como sugestão o nome do traço original adicionado da palavra copy como ilustrado
na figura 3.3. Se o campo nome for omitido antes de realizar a cópia, o nome do
novo traço será o mesmo que foi sugerido pela interface.
Um exemplo prático de utilização desse mecanismo seria a cópia do traço
“Requisição HTTP inválida” ilustrado na introdução (figura 1.2) para a criação do
traço “Requisição HTTP página não encontrada” ilustrado, também na introdução,
na figura 1.3. Os dois traços possuem praticamente as mesmas caracterı́sticas, diferenciando apenas em um campo de mensagem. Assim cria-se um novo traço sem
necessidade de recriar uma especificação partindo do ponto zero.
21
Outra funcionalidade do mecanismo de cópia seria a de realizar cópias de segurança (backups) de traços dentro da própria base de dados da plataforma. Dessa
maneira traços existentes podem ser copiados e essa versão copiada pode ser modificada para a realização de testes ou outros tipos de experimentos. Assim a versão
original do traço fica intacta.
Visto o funcionamento da interface, é importante descrever a forma de como
esse mecanismo foi implementado. Para realizar a cópia de uma especificação, o
mecanismo cria novos registros em cada uma das tabelas da base de traços, alterando somente a chave primária dos registros inseridos. Dessa forma todas as
caracterı́sticas originais são copiadas com fidelidade para o novo traço.
3.3
Mecanismo de reuso de traços
Acredita-se que o mecanismo de cópia proporcione agilidade ao processo de
especificação de traços, considerando o simples fato de que um traço pode ser copiado através de uma única interface, minimizando o tempo de criação. A limitação
desse mecanismo, no entanto, é que, quando um traço copiado é alterado, o traço
original continua intacto, não existindo nenhuma vinculação entre o traço original e
o copiado. É possı́vel imaginar uma situação onde um traço que foi criado através do
mecanismo de cópia necessite de alterações que foram realizadas no traço original.
Com a existência do vı́nculo entre o traço original e o copiado as alterações se dariam
de forma automática. Assim o gerente de rede evitaria um trabalho redundante de
alterações de mensagens e campos de mensagens, estados e transições de cada traço
que viesse a receber alterações por falta de vinculação. Diante dessa problemática
tornou-se eficaz a implementação de um mecanismo que permitisse a “herança” de
especificações.
O mecanismo de reuso foi implementado seguindo alguns conceitos básicos de
da metodologia para programação orientada a objetos [BRU 2000, UFMS 2002]. A
partir desses conceitos algumas decisões foram tomadas durante a implementação
desse mecanismo e foram usadas como regras para reuso de traços na plataforma:
• traços derivados (filhos) recebem todas as caracterı́sticas do traço pai;
• as caracterı́sticas herdadas não podem ser modificadas nos traços derivados;
• as caracterı́sticas modificadas nos traços pais são refletidas automaticamente
nos traços derivados.
A partir das decisões de projeto apresentadas, um traço pode ser representado
como ilustra a figura 3.4. O traço “Requisição HTTP página não encontrada” é
derivado do traço “Requisição HTTP”, que possui os estados idle e 2 e a mensagem
HEAD. Essas caracterı́sticas estão presentes no traço “Requisição HTTP página
não encontrada”, mas alterações nas caracterı́sticas herdadas deste traço só podem
ser realizadas a partir do traço “Requisição HTTP”. Ao traço “Requisição HTTP
página não encontrada” foi acrescentada a mensagem HTTP/1.1 404, fazendo com
que o traço se torne mais especializado, isto é, a partir de um traço com caracterı́sticas básicas, podem ser agregadas caracterı́sticas para o traço com funções
mais especializadas.
22
Traço “Requisição HTTP”
Traço “Requisição HTTP página não encontrada”
HEAD
idle
HEAD
2
idle
2
HTTP/1.1 404
FIGURA 3.4 – Traço criado com o mecanismo de reuso
A interface do mecanismo de reuso utiliza as mesmas definições da interface
do mecanismo de cópia, ilustrado na figura 3.3. A figura 3.5 ilustra a utilização do
mecanismo de reuso de traços.
FIGURA 3.5 – Utilização do mecanismo de reuso
A implementação do mecanismo de reuso envolve algumas mudanças na base
de dados da plataforma Trace. Foram criadas estruturas auxiliares para realizar a
ligação entre os traços pais e os seus respectivos filhos. Essas estruturas funcionam
como listas encadeadas, onde um traço pai pode reconhecer todos os seus filhos e
um traço filho pode reconhecer o seu pai.
A implementação das listas encadeadas envolve as seguintes adições à base de
traços: para a tabela protocol trace foi acrescentada a tabela reuse protocol
trace e o mesmo foi realizado para as tabelas message, message field, grouper,
state e transition. A figura 3.6 ilustra a implementação das estrututas auxiliares
na base de dados da plataforma Trace.
A figura 3.7 ilustra o esquema de implementação das listas encadeadas utilizando como exemplo a tabela protocol trace. A tabela reuse protocol trace
serve como lista encadeada para a tabela protocol trace. Esse mesmo esquema
foi implementado para o restante das tabelas ilustradas na figura 3.6.
As interfaces do mecanismo de gerenciamento de traços sofreram alterações
para suportar a visualização de traços criados a partir do mecanismo de reuso. Essas alterações visam separar as caracterı́sticas herdadas das caracterı́sticas criadas
23
FIGURA 3.6 – Modelo E-R da aplicação de gerencimento utilizado para suportar o
mecanismo de reuso
FIGURA 3.7 – Implementação das listas encadeadas
no próprio traço. A figura 3.8 ilustra a interface de gerenciamento de campos de
mensagens, servindo também como exemplo para as interfaces de gerenciamento
de mensagens, agrupamentos, criação de estados e visualização integral das caracterı́sticas do traço, pois seguem o mesmo padrão. Os elementos foram separados
em duas divisões: caracterı́sticas próprias (Own) e caracterı́sticas reusadas (Reuse).
Somente as caracterı́sticas que fazem parte da divisão (Own) aparecem na caixa de
seleção respeitando uma das regras estipuladas para o funcionamento do mecanismo
de reuso, onde as caracterı́sticas dos traços pais não podem ser alteradas pelos traços
filhos.
FIGURA 3.8 – Interface alterada para suportar reuso de traços
A interface de gerenciamento da máquina de estados também sofreu alterações
para permitir a visualização dos traços filhos em camadas de reuso. Foi implemen-
24
tado o conceito de camadas (layers) e uma simbologia de cores. As camadas são
utilizadas para diferenciar os nı́veis de reuso que o traço possui. A camada 0 contém
o traço em seu último nı́vel de reuso e a camada n possui o traço em seu nı́vel mais
baixo (origem de todas as outras camadas). Assim podemos ter uma visão incremental de todas as camadas de reuso que um traço possui. A simbologia de cores
foi utilizada para diferenciar os estados herdados dos estados adicionados durante
as fases de reuso. Os estados representados pela cor verde foram herdados do traço
pai e os estados em amarelo foram acrescentados posteriormente ao reuso.
A figura 3.9 ilustra o traço “Requisição HTTP 401” que foi criado com o mecanismo de reuso a partir do traço “Requisição HTTP”, onde pode ser visualizada a
camada 0 (Layer 0 ) do traço. Nesta camada o usuário pode visualizar o traço herdado com a mensagem (HEAD) e a mensagem (HTTP/1.1 401 ) que foi adicionada
posteriormente à sua criação. A figura 3.10 ilustra o mesmo traço, mas visualizado
em sua camada superior (Layer 1 ), onde somente o traço pai é visualizado. Os estados na cor verde fazem parte das caracterı́sticas herdadas do traço pai e os estados
na cor amarela fazem parte das caracterı́sticas próprias do traço (adicionadas após
sua criação).
FIGURA 3.9 – Máquina de estados suportando reuso (Layer 0 )
FIGURA 3.10 – Máquina de estados suportando reuso (Layer 1 )
25
4 Experimentação dos mecanismos implementados
O capı́tulo anterior apresentou as implementações realizadas na aplicação de
gerenciamento da plataforma Trace. Para ilustrar os resultados obtidos com essas
implementações esse capı́tulo apresenta uma experimentação realizada com usuários
da plataforma. A seção 4.1 apresenta a metodologia utilizada e a seção 4.2 apresenta
os resultados obtidos.
4.1
Metodologia utilizada
A experimentação dos mecanismos de busca, cópia e reuso procurou identificar alguns benefı́cios proporcionados pela implementação desses mecanismos. Para
realizar a experimentação foi utilizado um roteiro. Este roteiro, que se encontra no
anexo 1, visa a criação de 10 traços pré-definidos, dos quais alguns possuem relações
de semelhança e dependência entre si onde os mecanismos de cópia e reuso podem
ser utilizados. No roteiro os traços foram especificados de forma gráfica e textual.
A execução do roteiro foi realizada por quatro usuários da plataforma Trace,
todos possuiam algum tipo de conhecimento quanto ao processo de criação de traços.
Os usuários foram divididos em dois grupos, cada qual possuia um usuário com nı́vel
médio de conhecimento do processo de especificação de traços e um usuário com
elevado nı́vel de conhecimento. O primeiro grupo recebeu o roteiro para trabalhar
na versão convencional da aplicação de gerenciamento e o segundo grupo recebeu o
roteiro para trabalhar na versão implementada neste trabalho já podendo utilizar
os novos mecanismos de busca, cópia e reuso. Cabe ressaltar que o roteiro utilizado
pelos dois grupos foi o mesmo, sem quaisquer alterações.
Antes de iniciar o roteiro, os dois grupos de usuários foram convocados para
uma reunião, onde foram explicitados os processos de criação de traços. Cada grupo
recebeu instruções de como realizar o roteiro na versão da plataforma Trace a que
foi destinado.
Cada usuário deveria cumprir o roteiro de forma ininterrupta, pois o tempo
para realizar o roteiro foi monitorado. Para realizar a monitoração do tempo de
execução do roteiro foi implementado um log de acessos na aplicação de gerenciamento, onde as principais atividades de cada usuário ficavam gravadas na base de
dados indicando a tarefa realizada e a data/hora da execução dessa tarefa.
4.2
Resultados obtidos
Os resultados obtidos na realização do roteiro foram coletados logo após cada
usuário dar por terminada a sua execução. A figura 4.1 ilustra os resultados do
tempo gasto para especificar todos os traços para cada usuário dos grupos 1 e 2.
26
&('*),+!-/.!0213(-/+!15416'20+('(758 98 7:154*;-(3-20
&(')E+!-/.!0(13-/+(1(4 1F'0!+B':758 9 8 7(1*45;-3*-G0
-20<;41=-0?>(@A4.(+B-DC
-(0H;41=5-(0?>(@A4.(+(-?I
!"#$ % B"#$ % FIGURA 4.1 – Tempo gasto pelos usuários para a realização completa do roteiro
Analisando os gráficos da figura 4.1 podemos verificar que os usuários do grupo
2 obtiveram um tempo total menor na execução do roteiro. Esse fato evidencia que
os novos mecanismos contribuiram para a diminuição dos tempos de criação de
traços. As figuras 4.2 e 4.3 ilustram os tempos dispendidos por cada usuário para a
criação de cada um dos traços do roteiro.
f:g2h6ijlkm:no jligBp jrqnBqs(t u j<vxw5jykBt qBij6vrimBt m
gn2ig:z5u {u zm(t!zmwmrot m|5j
TU5VXWY
JJK RSK RS
JJK ROK LO
JJK RRK NR
JJK JQK NQ
JJK JMK OP
JJK JLK MN
JJK JJK JJ
fg2h6ijk:mno j6igBp jrqnBqsBt u jlyw5jAkBt qBijlvrim(t m
gn2igz5u {u z:mBt!zmw:mrot m|5j
TU5V<WY
JJK RSK RS
JJK ROK LO
JJK RRK NR
JJK JQK NQ
JJK JMK OP
JJK JLK MN
JJK JJK JJ
RZL[N\O]M^P]S^Q`_aRJ
T!b cdYe
R]L]N\O[M}P[S}Q~_RJ
T5b cdY:e
FIGURA 4.2 – Tempo dispendido pelos usuários do grupo 1 na criação de cada um
dos traços
26:5 65 r ! ¡2¢ £ 6¤¦¥A2¢ !A§l(¢ 
:(¨5£ © £ ¨:B¢!¨:¥:¢ ª
2«l: lB  B ¡B¢£ l§A¥5A(¢ BA§XB¢ 
2¨!£ ©£ ¨B¢!¨:¥r¢ ª5
:  
:  
5<
:  :
:  
:  
:  
:  
  
  
:5X
]]^]^`}[a
!
  
  
  
  
  
Z[\[}[}`a
5
FIGURA 4.3 – Tempo dispendido pelos usuários do grupo 2 na criação de cada um
dos traços
Pode-se verificar que os usuários do grupo 2 gastaram, em média, 11 minutos
e 43 segundos enquanto que os usuários do grupo 1 gastaram 13 minutos e 50
segundos para criar todos os traços do roteiro. Baseado nesse fato é possı́vel afirmar
que a criação dos mecanismos trouxe benefı́cios para a aplicação de gerenciamento
da plataforma Trace tanto na facilidade de criação de novas especificações quanto
27
na organização da base de traços. A figura 4.4 ilustra a taxa de utilização dos
mecanismos de busca, cópia e reuso por parte dos usuários do grupo 2.
&
#'(
) * +,-#./.10)234 0526.10(7809#:; ./<
&
$'(
) * +#,-.6.
0/2=
4# 0
2>.
0675809#:? ./@
5 !#"$%
$#
# !"#%
FIGURA 4.4 – Taxa de utilização dos mecanismos pelos usuários do grupo 2
Como ilustra a figura 4.4, os mecanismos de busca e cópia não foram muito
utilizados pelos usuários do grupo 2, por dois motivos: a base de traços estava vazia
no inı́cio da execução e o roteiro possui traços para os quais o mecanismo de reuso
possui maior aplicabilidade. Assim o mecanismo de reuso foi o mais utilizado pelos
usuários, contribuindo para diminuição do tempo gasto para a criação de todos os
traços do roteiro.
28
5
Conclusões
O capı́tulo 1 contextualizou o motivo deste trabalho ilustrando alguns conceitos e problemas da aplicação de gerenciamento. O capı́tulo 2 apresentou a linguagem
PTSL e a versão convencional da aplicação de gerenciamento de traços. No capı́tulo
3 foram apresentados os mecanismos de busca, cópia e reuso implementados neste
trabalho. E o capı́tulo 4 apresentou uma experimentação na aplicação de gerenciamento realizada com alguns usuários da plataforma Trace. Neste capı́tulo serão
apresentadas algumas conclusões através de contribuições e trabalhos futuros para
a aplicação de gerenciamento da plataforma Trace.
5.1
Contribuições do trabalho
A principal contribuição deste trabalho, com a implementação dos mecanismos
de busca, cópia e reuso foi a resolução dos seguintes problemas que haviam na
aplicação de gerenciamento de traços:
a) redução do número de traços idênticos dentro da base de traços: esse problema
ocorria porque não era possı́vel identificar um traço na plataforma sem que
se explorasse todas as suas caracterı́sticas através da navegação completa por
sua especificação;
b) diminuição do tempo de busca de traços: esse problema ocorria pelo mesmo
motivo apontado no item anterior;
c) redução do tempo despendido para criação de novos traços: somente era possı́vel
criar um novo traço a partir de seu ponto inicial, não sendo possı́vel a cópia
ou o reuso de especificações;
As melhorias alcançadas no desenvolvimento dos novos mecanismos permitem
que a aplicação de gerenciamento de traços torne-se bastante flexı́vel suportando
um maior número de especificações através de uma melhor organização da base
de traços. Com a base de traços melhor organizada, o gerente de rede pode dar
maior ênfase para as tarefas relacionadas à monitoração e execução das tarefas de
gerenciamento que a plataforma Trace permite executar.
5.2
Trabalhos futuros
A finalização deste trabalho traz algumas atividades que poderiam ser realizadas para a melhoria da interface de gerenciamento de traços:
a) reestilização da interface WEB da aplicação de gerenciamento: a criação de um
novo estilo para a interface de gerenciamento de traços facilitaria o trabalho
dos usuários da plataforma, através da criação de ı́cones e links de acesso
direto a cada traço sem a necessidade de escolha nas caixas de selecão, como
é realizado atualmente;
b) redesenho do mecanismo de visualização da máquina de estados: a visualização
da máquina de estados poderia ser redesenhada, melhorando a qualidade de
29
sua interface com a utilização de transições em curva ao invés de transições
quebradas em duas retas. Com a utilização de linhas curvas nas transições de
estados a visualização da máquina de estados tornaria-se mais legı́vel.
30
Anexo 1
Roteiro de experimentação
Estão presentes neste roteiro alguns traços que deverão ser criados na plataforma de forma ininterrupta, isto é, todo o experimento deverá ser realizado de uma
única vez, não podendo haver pausas entre a criação dos traços. O nome de cada
traço deverá possuir o nome do usuário em seu inı́cio, para que não haja nomes
de traços duplicados, pois o experimento será realizado em conjunto com vários
usuários. A plataforma deverá ser acessada via navegador web através do endereço
http://www.atendebem.com.br:8080/tracen. O login e a senha para acessar a plataforma são individuais. Após informar o login e senha, a opção ”Specification”deverá
ser clicada e logo após a opção ”Protocol Trace”. Clicando nestas opções, será
aberta a interface de gerenciamento de traços, onde este roteiro de experimentação
será realizado.
Login:
Senha:
31
1- Traço ”Requisição HTTP inválida”
Vers~
ao: 1.0
Descriç~
ao: Acesso http com resposta 400
Palavras-chave: http, 400, inválida
Porta: 80
Campos de Mensagens
"GET"
Tipo: client
Encapsulamento: Ethernet/IP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: GET
Descriç~
ao: Requisiç~
ao de uma página Web
"HTTP 1.1"
Tipo: server
Encapsulamento: Ethernet/IP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: HTTP/1.1
Descriç~
ao: Vers~
ao do protocolo
"Código 400"
Tipo: server
Encapsulamento: Ethernet/IP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: 400
Descriç~
ao: Código de retorno
Mensagens
"GET"
Tipo: client
Timeout: 0
Campos: GET
"HTTP/1.1 400"
Tipo: server
Timeout: 0
Campos: Código 400, HTTP 1.1
Estados
"idle"
Estado final: sim
32
"2"
Estado final: n~
ao
Transiç~
oes
"GET"
Tipo: message
Estado fonte: idle
Estado destino: 2
"HTTP/1.1 400"
Tipo: message
Estado fonte: 2
Estado destino: idle
33
2- Traço ”Duração de conexão TCP”
Vers~
ao: 1.0
Descriç~
ao: Medir o tempo entre um TCP SYN e um FYN/ACK
Palavras-chave: TCP, duraç~
ao, conex~
ao, SYN, FYN/ACK
Campos de Mensagens
"SYN"
Tipo: client
Encapsulamento: Ethernet/IP
Offset: Bit Counter
Posiç~
ao: 110
Tamanho: 1
Valor esperado: 1
Descriç~
ao: Flag SYN está ligado
"ACK"
Tipo: server
Encapsulamento: Ethernet/IP
Offset: Bit Counter
Posiç~
ao: 107
Tamanho: 1
Valor esperado: 1
Descriç~
ao: Flag ACK está ligado
"FYN"
Tipo: server
Encapsulamento: Ethernet/IP
Offset: Bit Counter
Posiç~
ao: 111
Tamanho: 1
Valor esperado: 1
Descriç~
ao: Flag FYN está ligado
Mensagens
"TCP SYN"
Tipo: client
Timeout: 0
Campos: SYN
"TCP FYN/ACK"
Tipo: server
Timeout: 0
Campos: ACK, FYN
34
Estados
"idle"
Estado final: sim
"2"
Estado final: n~
ao
Transiç~
oes
"TCP SYN"
Tipo: message
Estado fonte: idle
Estado destino: 2
"TCP FYN/ACK"
Tipo: message
Estado fonte: 2
Estado destino: idle
35
3- Traço ”Ataque por inundação”
Vers~
ao: 1.0
Descriç~
ao: Final do three-way handshaking
Palavras-chave: SynFlood, TCP
Campos de Mensagens
"SYN"
Tipo: client
Encapsulamento: Ethernet/IP
Offset: Bit Counter
Posiç~
ao: 110
Tamanho: 1
Valor esperado: 1
Descriç~
ao: Flag SYN está ligado
"ACK client"
Tipo: client
Encapsulamento: Ethernet/IP
Offset: Bit Counter
Posiç~
ao: 107
Tamanho: 1
Valor esperado: 1
Descriç~
ao: Flag ACK está ligado
"ACK server"
Tipo: server
Encapsulamento: Ethernet/IP
Offset: Bit Counter
Posiç~
ao: 107
Tamanho: 1
Valor esperado: 1
Descriç~
ao: Flag ACK está ligado
Mensagens
"TCP SYN/ACK"
Tipo: client
Timeout: 0
Campos: SYN, ACK client
"TCP ACK"
Tipo: server
Timeout: 0
Campos: ACK Server
Estados
"idle"
Estado final: sim
36
"2"
Estado final: n~
ao
Transiç~
oes
"TCP SYN/ACK"
Tipo: message
Estado fonte: idle
Estado destino: 2
"TCP ACK"
Tipo: message
Estado fonte: 2
Estado destino: idle
37
4- Traço ”Sondagem de Portas”
Vers~
ao: 1.0
Descriç~
ao: Acesso a service TCP n~
ao disponı́vel
Palavras-chave: portas, sondagem, TCP
Campos de Mensagens
"SYN"
Tipo: client
Encapsulamento: Ethernet/IP
Offset: Bit Counter
Posiç~
ao: 110
Tamanho: 1
Valor esperado: 1
Descriç~
ao: Flag SYN está ligado
"RST"
Tipo: server
Encapsulamento: Ethernet/IP
Offset: Bit Counter
Posiç~
ao: 109
Tamanho: 1
Valor esperado: 1
Descriç~
ao: Flag RST está ligado
Mensagens
"TCP SYN"
Tipo: client
Timeout: 0
Campos: SYN
"TCP RST"
Tipo: server
Timeout: 0
Campos: RST
Estados
"idle"
Estado final: sim
"2"
Estado final: n~
ao
Transiç~
oes
"TCP RST"
Tipo: message
Estado fonte: idle
38
Estado destino: 2
"TCP SYN"
Tipo: message
Estado fonte: 2
Estado destino: idle
39
5- Traço ”Sondagem de RPC”
Vers~
ao: 1.0
Descriç~
ao: Verificar sondagem de RPC
Palavras-chave: sondagem, RPC
Campos de Mensagens
"Type Reply"
Tipo: server
Encapsulamento: Ethernet/IP/UDP
Offset: Bit Counter
Posiç~
ao: 32
Tamanho: 32
Valor esperado: 00000000000000000000000000000001
Descriç~
ao: Type Reply
"Port Mapper"
Tipo: client
Encapsulamento: Ethernet/IP
Offset: Bit Counter
Posiç~
ao: 16
Tamanho: 16
Valor esperado: 0000000001101111
Descriç~
ao: Port Mapper
"RPC Get Port"
Tipo: client
Encapsulamento: Ethernet/IP/UDP
Offset: Bit Counter
Posiç~
ao: 160
Tamanho: 32
Valor esperado: 00000000000000000000000000000011
Descriç~
ao: RPC Get Port
"Type Call UDP"
Tipo: client
Encapsulamento: Ethernet/IP/UDP
Offset: Bit Counter
Posiç~
ao: 32
Tamanho: 32
Valor esperado: 00000000000000000000000000000000
Descriç~
ao: Type Call UDP
40
"Type Call TCP"
Tipo: client
Encapsulamento: Ethernet/IP/TCP
Offset: Bit Counter
Posiç~
ao: 64
Tamanho: 32
Valor esperado: 00000000000000000000000000000000
Descriç~
ao: Type Call TCP
"Program Mount"
Tipo: client
Encapsulamento: Ethernet/IP/TCP
Offset: Bit Counter
Posiç~
ao: 128
Tamanho: 32
Valor esperado: 00000000000000011000011010100101
Descriç~
ao: Program Mount
Mensagens
"Port Mapper 1"
Tipo: client
Timeout: 2
Campos: Port Mapper, RPC Get Port, Type Call UDP
"Port Mapper 2"
Tipo: server
Timeout: 2
Campos: Type Reply
"Port Mapper 3"
Tipo: client
Timeout: 2
Campos: Type Call TCP, Program Mount
Estados
"idle"
Estado final: sim
"RPCState2"
Estado final: n~
ao
"RPCState3"
Estado final: n~
ao
Transiç~
oes
"Port Mapper 1"
Tipo: message
Estado fonte: idle
Estado destino: RPCState2
"Port Mapper 2"
Tipo: message
Estado fonte: RPCState2
Estado destino: RPCState3
41
"Port Mapper 3"
Tipo: message
Estado fonte: RPCState3
Estado destino: idle
42
6- Traço ”Autenticação usuário POP3 inexistente”
Vers~
ao: 1.0
Descriç~
ao: Verificar tentativas de conex~
ao POP3 com username existente
Palavras-chave: e-mail, POP3
Campos de Mensagens
"USER"
Tipo: client
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: USER
Descriç~
ao: Username POP3
"ERR"
Tipo: server
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: ERR
Descriç~
ao: Operaç~
ao falhou
Mensagens
"USER"
Tipo: client
Timeout: 0
Campos: USER
"ERR"
Tipo: server
Timeout: 0
Campos: ERR
Estados
"idle"
Estado final: sim
"2"
Estado final: n~
ao
Transiç~
oes
"USER"
Tipo: message
Estado fonte: idle
Estado destino: 2
"ERR"
43
Tipo: message
Estado fonte: 2
Estado destino: idle
44
7- Traço ”Autenticação usuário/senha POP3”
Vers~
ao: 1.0
Descriç~
ao: Verificar tentativas de conex~
ao POP3 com username e password inválidos
Palavras-chave: e-mail, POP3
Campos de Mensagens
"USER"
Tipo: client
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: USER
Descriç~
ao: Username POP3
"ERR"
Tipo: server
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: ERR
Descriç~
ao: Operaç~
ao falhou
"OK"
Tipo: server
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: OK
Descriç~
ao: Operaç~
ao realizada com sucesso
"PASS"
Tipo: client
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: PASS
Descriç~
ao: Password do usuário
"QUIT"
Tipo: client
45
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: QUIT
Descriç~
ao: Encerra conex~
ao
Mensagens
"USER"
Tipo: client
Timeout: 0
Campos: USER
"ERR"
Tipo: server
Timeout: 0
Campos: ERR
"OK"
Tipo: server
Timeout: 0
Campos: OK
"PASS"
Tipo: client
Timeout: 0
Campos: PASS
"QUIT"
Tipo: client
Timeout: 0
Campos: QUIT
Estados
"idle"
Estado final: sim
"2"
Estado final: n~
ao
"3"
Estado final: n~
ao
"4"
Estado final: n~
ao
Transiç~
oes
"USER"
Tipo: message
Estado fonte: idle
Estado destino: 2
"ERR"
Tipo: message
Estado fonte: 2
Estado destino: idle
46
"OK"
Tipo: message
Estado fonte: 2
Estado destino: 3
"PASS"
Tipo: message
Estado fonte: 3
Estado destino: 4
"QUIT"
Tipo: message
Estado fonte: 3
Estado destino: idle
"OK"
Tipo: message
Estado fonte: 4
Estado destino: idle
"ERR"
Tipo: message
Estado fonte: 4
Estado destino: 3
47
8- Traço ”Requisição HTTP”
Vers~
ao: 1.0
Descriç~
ao: Requisiç~
oes HTTP
Palavras-chave: retorno, HTTP
Campos de Mensagens
"HEAD"
Tipo: client
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: HEAD
Descriç~
ao: Cabeçalho da página
"HTTP 1.1"
Tipo: server
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: HTTP/1.1
Descriç~
ao: Vers~
ao de protocolo
Mensagens
"HEAD"
Tipo: client
Timeout: 0
Campos: HEAD
Estados
"idle"
Estado final: sim
"2"
Estado final: n~
ao
Transiç~
oes
"HEAD"
Tipo: message
Estado fonte: idle
Estado destino: 2
48
9- Traço ”Requisição HTTP 401”
Vers~
ao: 1.0
Descriç~
ao: Requisiç~
oes HTTP com retorno 401
Palavras-chave: retorno, HTTP
Campos de Mensagens
"HEAD"
Tipo: client
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: HEAD
Descriç~
ao: Cabeçalho da página
"HTTP 1.1"
Tipo: server
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: HTTP/1.1
Descriç~
ao: Vers~
ao de protocolo
"401"
Tipo: server
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 1
Valor esperado: 401
Descriç~
ao: Código de retorno
Mensagens
"HEAD"
Tipo: client
Timeout: 0
Campos: HEAD
"HTTP/1.1 401"
Tipo: server
Timeout: 0
Campos: HTTP/1.1, 401
Estados
"idle"
Estado final: sim
49
"2"
Estado final: n~
ao
Transiç~
oes
"HEAD"
Tipo: message
Estado fonte: idle
Estado destino: 2
"HTTP/1.1 401"
Tipo: message
Estado fonte: 2
Estado destino: idle
50
10- Traço ”Requisição HTTP 402”
Vers~
ao: 1.0
Descriç~
ao: Requisiç~
oes HTTP com retorno 402
Palavras-chave: retorno, HTTP
Campos de Mensagens
"HEAD"
Tipo: client
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: HEAD
Descriç~
ao: Cabeçalho da página
"HTTP 1.1"
Tipo: server
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 0
Valor esperado: HTTP/1.1
Descriç~
ao: Vers~
ao de protocolo
"402"
Tipo: server
Encapsulamento: Ethernet/IP/TCP
Offset: Field Counter
Posiç~
ao: 1
Valor esperado: 402
Descriç~
ao: Código de retorno
Mensagens
"HEAD"
Tipo: client
Timeout: 0
Campos: HEAD
"HTTP/1.1 402"
Tipo: server
Timeout: 0
Campos: HTTP/1.1, 402
Estados
"idle"
Estado final: sim
"2"
51
Estado final: n~
ao
Transiç~
oes
"HEAD"
Tipo: message
Estado fonte: idle
Estado destino: 2
"HTTP/1.1 402"
Tipo: message
Estado fonte: 2
Estado destino: idle
52
Bibliografia
[BRU 2000] Bruegge, Bernd. Dutoit, ALLEN H.. Object-oriented software engineering:
conquering complex and changing systems. Upper Saddle River: Prentice-Hall, 2000.
[GAS 2001a] GASPARY, Luciano P.; BALBINOT, Luis F.; STORCH, Roberto;
WENDT, Fabrı́cio; TAROUCO, Liane R. Towards a Programmable Agent-based
Distributed Architecture for Enterprise Application and Service Management. In:
IEEE/IEC ENTERPRISE NETWORKING APPLICATIONS AND SERVICES
CONFERENCE, (ENTNET), 2001, Atlanta, USA. Proceedings Piscataway, USA:
IEEE Operations Center, 2001. p. 39-46.
[GAS 2001b] GASPARY, Luciano P.; BALBINOT, Luis F.; STORCH, Roberto;
WENDT, Fabrı́cio; TAROUCO, Liane R. Uma Arquitetura para Gerenciamento Distribuı́do e Flexı́vel de Protocolos de Alto Nı́vel e Serviços de Rede. In: SIMP ÓSIO
BRASILEIRO DE REDES DE COMPUTADORES, (SBRC), 19., 2001, Florianópolis.
Anais... Florianópolis, 2001.
[GAS 2001c] GASPARY, Luciano P.; BALBINOT, Luis F.; STORCH, Roberto;
WENDT, Fabrı́cio; TAROUCO, Liane R. Distributed Management of High-Layer
Protocols and Network Services through a Programmable Agent-Based Architecture.
In: INTERNATIONAL CONFERENCE ON NETWORKING, (ICN), 1., July 2001,
Colmar, France. Proceedings... Berlin: Springer, 2001. p. 204–217. (Lecture Notes in
Computer Science, v.2093, n. 1).
[GAS 2002a] GASPARY, Luciano P.; MENEGHETTI, Edgar; WENDT, Fabrı́cio;
BRAGA, Lucio; STORCH, Roberto; TAROUCO, Liane R. Trace: An Open Platform for High-layer Protocolos, Services and Networked Applications Management.
To appear in: IFIP/IEEE NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM, 2002, Florence.
[GAS 2002b] GASPARY, Luciano P.; Gerenciamento Distribuı́do e Flexı́vel de Protocolos de Alto Nı́vel, Serviços e Aplicações em Rede. 2002. Tese (Doutorado em Ciência
da Computação) - Instituto de Informática, Universidade Federal do Rio Grande do
Sul, Porto Alegre.
[GOO 2002] Ferramenta de busca Google. Disponı́vel em http://www.google.com.br.
Acessado em junho de 2002.
[MEN 2002] MENEGHETTI, Edgar; Uma Proposta de Uso da Arquitetura Trace como
um Sistema de Detecção de Intrusão. 2002. Dissertação (Mestrado em Ciência da
Computação) - Instituto de Informática, Universidade Federal do Rio Grande do Sul,
Porto Alegre.
53
[TRA 2002] Trace
Management
Platform
HP.
http://prav.unisinos.br/ trace. Acessado em setembro de 2002.
Disponı́vel
[UFMS 2002] Mecanismos
para
Reuso
de
Software.
Disponı́vel
http://www.dct.ufms.br/ marcelo/teaching/too. Acessado em junho de 2002.
em
em
[YAH 2002] Ferramenta de busca Yahoo. Disponı́vel em http://www.yahoo.com. Acessado em junho de 2002.