![]() |
![]() |
O objetivo deste projeto � comprimir as mensagens CORBA que s�o enviadas do cliente para o servidor e vice-versa, e descobrir em quais situa��es os interceptadores melhoram o desempenho e em quais eles introduzem um sobrecarga indesej�vel. Para tal, utilizou-se os interceptadores de mensagens propriet�rios do JacORB, implementados na linguagem Java.
Os interceptadores agem sobre as mensagens trocadas entre o cliente e o servidor, dentro do ORB. Como as pr�prias mensagens s�o alteradas, utilizar interceptadores de mensagens em detrimento dos de requisi��es foi uma decis�o natural.
O algoritmo usado pelos interceptadores para compactar as mensagens foi o das classes java.util.zip.Inflater e java.util.zip.Deflater, do JDK 1.2.2. Estas classes utilizam o algoritmo de compacta��o ZLIB.
O esquema para envio e recep��o de mensagens no sistema funciona da seguinte forma:
- Quando uma mensagem endere�ada ao servidor � montada pelo cliente, esta � interceptada ao chegar no ORB.
- No ORB, o interceptador do cliente encarrega-se de compactar a mensagem.
- A mensagem �, ent�o, formatada para envio: s�o adicionados 0's at� que o seu tamanho atinja uma pot�ncia de 2.
- Quando a mensagem chega no lado do servidor, o interceptador a descompacta e ela � reformatada (adicionando-se os 0's no seu final).
- Em seguida, o ORB retira os 0's de formata��o da mensagem, e esta chega ao servidor, onde � feito o unmarshalling.
- A resposta do servidor � ent�o enviada, an�logo aos procedimentos acima descritos, at� o lado do cliente.
O maior problema enfrentado durante a implementa��o do projeto n�o foi diretamente relacionado ao mesmo. Quando da execu��o dos testes, descobrimos que as mensagens enviadas pelo cliente e pelo servidor n�o chegavam intactas ao seu destino: elas eram modificadas de tal forma que davam problemas ou o servidor ca�a.
Atrav�s de informa��es trocadas com o grupo de Alexey A. Villas Boas, Edgard Pevidor de Miranda e Flavio Regis de Arruda, que tamb�m implementaram o mesmo projeto, soubemos que o problema n�o estava no nosso c�digo, mas na implementa��oo de interceptadores de mensagens do pr�prio JacORB. Havia um bug que os programadores do ORB n�o fixaram, o que foi confirmado pelos mesmos quando o grupo de Alexey comunicou-se com eles.
Atrav�s de modifica��es feitas por esse grupo no c�digo-fonte do JacORB, foi poss�vel fazer os interceptadores funcionarem. No entanto, devido a uma limita�ao da vers�o utilizada, tivemos de retirar do projeto o servi�o de nomes (j� em funcionamento no c�digo), substituindo-o por um arquivo mesmo.
Outra dificuldade enfrentada foi entender o modo como os interceptadores funcionam. Para enviar qualquer mensagem, o JacORB completa a mensagem com 0's, at� que o tamanho da mesma atinja uma pot�ncia de 2. Como o trabalho dos interceptadores � realizado antes da recep��o da mensagem, tivemos de formatar a mensagem descompactada para atender a esse padr�o, pois o mesmo era esperado no destino. A solu��o encontrada foi criar um m�todo que calculava a pot�ncia de 2 mais pr�xima do tamanho da mensagem j� descompactada, e preencher o final da mesma com 0's.
Fizemos testes para mensagens de aproximadamente 10, 100, 500, 1000 e 1500 bytes. Os resultados botem ser baixados daqui:
Analisando-se os gr�ficos obtidos, constatamos que o overhead de processamento causado pelos interceptadores supera o ganho de tempo originado pela compacta��o. Nas mensagens de tamanho 10 e 100, as mensagens sem compacta��o levavam grande vantagem sobre as compactadas. A situa��o come�a a mudar a partir das mensagens de tamanho 500, e os dois m�todos praticamente se equivalem em mensagens de 1000 bytes.
Com mensagens de tamanho 1500, a compacta��o j� come�a a fazer diferen�a, e as mensagens compactadas levam um tempo menor para sair do cliente, chegar ao servidor e retornar ao cliente.
- Baixe o arquivo ep3.tar.gz e descompacte-o.
- Altere o script mac440.sh e execute-o.
- Compile o c�digo-fonte.
- Abra duas janelas: na primeira, rode o servidor; na segunda, o cliente.
- Rode o GNUPlot: gnuplot plota.