ARQUITETURA COMPUTACIONAL DE
ALTO DESEMPENHO PARA INTEGRAO
DE AMBIENTES INTERATIVOS E
IMERSIVOS REMOTOS PARA
VISUALIZAO MOLECULAR
So Carlos SP
Outubro/2010
UNIVERSIDADE FEDERAL DE SO CARLOS
CENTRO DE CINCIAS EXATAS E DE TECNOLOGIA
PROGRAMA DE PS-GRADUAO EM BIOTECNOLOGIA
ARQUITETURA COMPUTACIONAL DE
ALTO DESEMPENHO PARA INTEGRAO
DE AMBIENTES INTERATIVOS E
IMERSIVOS REMOTOS PARA
VISUALIZAO MOLECULAR
So Carlos SP
Outubro/2010
Dedico este trabalho a todos aqueles que acreditam que possvel realizar um sonho e lutam
at o fim por um ideal, dando certo ou no! Dedico, tambm, aos que no acreditam, com a
esperana de que possam mudar de ideia. Quem sabe...
melhor tentar e no conseguir do que passar a vida toda se lamentando por no ter
tentado
Agradecimentos
Dificilmente conseguirei ser justo com todos que participaram, direta ou indireta-
mente, ativamente ou no, da realizao deste trabalho. Mais difcil, ainda, seria colocar
os agradecimentos em ordem de importncia. Nem pensar! melhor faz-los em ordem
cronolgica. Sendo assim, e no aumentando nenhum fato, vamos pela ordem em que
cada um entrou na minha vida.
Agradeo a meus pais Moacyr e Martha, que nunca mediram esforos na tentativa de
dar a melhor educao possvel aos filhos. Sempre me apoiaram nos momentos de tomar
decises difceis e sempre estavam l naquela hora em que no tinha pra onde correr.
Daniela, minha querida esposa, que sempre esteve ao meu lado pro que der e vier.
Viveu, como eu e junto comigo, as alegrias das horas em que tudo caminhava para um
final feliz e as angstias dos momentos difceis... Companheira sem igual! Obrigado!
Aos meus filhos Beatriz e Gustavo, que nasceram no perodo em que este trabalho
estava sendo realizado. Razes da minha vida!
Agradeo ao amor incondicional de todos eles. Sem isso eu no seria o que sou e no
chegaria aonde cheguei. No tenho dvida disso.
Ao Arnaldo Andrade, meu amigo e guru empresarial de longa data, por me apoiar e
incentivar no final do trabalho.
Meus orientadores, Julio e Trevelin, tambm foram muito importantes. Sempre foi
gratificante conversar com eles. Nas reunies e em conversas informais aprendi muita
coisa que no podia aprender com livros e artigos. Poos de conhecimento, bom senso e
pacincia!
Agradeo ao Marcelo de Paiva Guimares, que me deu muitas dicas e nimo para
terminar o trabalho a tempo, especialmente na reta final.
Portanto, conclui-se que este doutorado no s meu. Quero dividi-lo com todos que
me ajudaram nesse perodo que no foi fcil!
Resumo
On the research for the new drugs and medicines, especially for those related to
the drug-receptor interaction, the importance of the researchers interaction is es-
sential, being inside the same room or spread in the world. The interaction in an
online environment, through shared visualization of a molecule, and the exchange
of the information and ideas thru text and/or voice allow the researchers to discuss
about aspects of the sharing molecule, increasing the new compound identification
chances. The architecture developed in this work uses the following concepts: dis-
tributed multiuser virtual reality systems, collaborative work and worldwide scope
network communication techniques for a high-performance system creation that al-
low it real-time interaction among various geographically spread molecules visuali-
zation research groups, using hardware system that goes from desktop computers to
immersive systems like CAVEs. This became possible thru each group local servers
based structure that communicate among themselves on a peer-to-peer network and
an inter server communication protocol creation that seek for the agility when mi-
nimizing the negative effects of the delay on the packet delivery and loss, typical
internet problem.
2.1 Sensorama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
CAPTULO 1 INTRODUO 16
1.4 Publicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 A Biotecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.1 Jmol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.2 VRMol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.4 VMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.5 PyMol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.6 Chimera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.7 SwissPDBViewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.4 ECCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4.2 VRDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4.3 Kinimmerse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5.2 AMMP-Vis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.5.5 MICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.1 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.3 Corba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
REFERNCIAS 134
Captulo 1
Introduo
Este trabalho descreve uma arquitetura de alto desempenho criada para viabilizar a
colaborao entre pesquisadores geograficamente dispersos, no contexto de visualizao
molecular. O diferencial dessa arquitetura, quando comparada s demais existentes,
que ela deu importncia aos problemas de comunicao via internet e buscou melhorar a
experincia colaborativa entre usurios conectados por esse meio, de maneira que possam
interagir entre si num mesmo ambiente em tempo compatvel com a aplicao, com a
possibilidade de utilizao do recurso de Realidade Virtual com multiprojeo. Considere,
por exemplo, um usurio com um computador pessoal, monitor comum, mouse e teclado;
ele pode interagir transparentemente com um grupo de pesquisadores que fazem uso de
um ambiente altamente imersivo como uma CAVE (2) localizada em qualquer outro local
do mundo. A arquitetura no limitada a dois grupos apenas; possvel a interao entre
diversos grupos.
1.2 Problemas e Objetivos 17
O objetivo deste trabalho criar um ambiente para suprir essas necessidades com
desempenho compatvel.
Para alcanar o objetivo apontado no item anterior, foi projetada uma arquitetura
composta por mltiplos servidores organizados de maneira que cada grupo de pesquisa
conte com um servidor localmente. Portanto, criou-se uma rede de servidores interligados
via internet, que trocam mensagens entre si e com seus respectivos clientes (usu-
rios) para manter o ambiente virtual sincronizado. O sistema foi desenvolvido sobre a
plataforma JAMP (Java Architecture for Multimedia Processing) (3) (4) (5) (6) (7) de
computao distribuda, qual foram feitas atualizaes para comportar tal estrutura.
A infraestrutura de multiprojeo flexvel, isto , pode ter de 1 a 5 telas de projeo
(como em uma Cave (2)), com projeo estereoscpica ou no, cada uma controlada por
um computador; todos eles so sincronizados via JAMP.
1.4 Publicaes 18
Essa arquitetura tem grande utilidade na rea educacional. Uma primeira aplicao
seria o ensino de qumica num ambiente com multiprojeo. Outro caso seria o
ensino a distncia pela internet com ambientes remotos interconectados.
1.4 Publicaes
2.1 Introduo
Embora haja forte tendncia em representar o mundo real nos sistemas de Realidade
Virtual, na simulao do imaginrio ou de situaes que vo alm dos limites humanos
que a Realidade Virtual se destaca, extrapolando o conceito de tempo e/ou de espao.
Com a Realidade Virtual possvel ver uma reao qumica acontecendo em tempo
confortvel, pode-se manipular uma molcula invisvel a olho nu ou navegar pela galxia
a uma velocidade maior que a da luz. Assim, a Realidade Virtual permite a interao
humana com situaes imaginrias ou com a reproduo fiel de ambientes da vida real,
atravs de dispositivos especficos, como culos especiais, luvas eletrnicas e outros tipos
de sensores e atuadores. A grande vantagem desse tipo de interface est no fato de as ha-
bilidades e conhecimentos intuitivos do usurio poderem ser utilizados para a manipulao
dos objetos virtuais (8).
O termo Realidade Virtual (RV) foi cunhado no final da dcada de 1980 por Jaron
Lanier (9), artista e cientista da computao que conseguiu convergir dois conceitos an-
tagnicos em um novo e vibrante conceito, capaz de captar a essncia dessa tecnologia:
a busca pela fuso do real com o virtual. Apesar de parecer um assunto novo ou at
2.2 Histria da Realidade Virtual 22
mesmo do futuro, a realidade virtual teve incio logo aps a Segunda Guerra Mundial,
impulsionada pelas indstrias de simuladores de voo e cinematogrfica. Em 1962 Morton
Heilig criou e patenteou um equipamento denominado Sensorama, ilustrado na Figura 2.1
(10). Ele era utilizado por apenas um espectador, que era exposto a uma combinao de
viso tridimensional, som estreo, vibraes, sensaes de vento e aromas (11).
Nessa mesma dcada surgiu o (Head Mounted Display (HMD), um dispositivo posi-
cionado na cabea do usurio com um visor acoplado, utilizado num circuito fechado de
televiso. No demorou a ser criado por Ivan Sutherland o primeiro capacete de visua-
lizao de imagens geradas por computador totalmente funcional (12). Esse sistema era
capaz de exibir 20 cenas por segundo e considerado o precursor da imerso em ambiente
virtual.
Na dcada de 1970 foi criada a Realidade Virtual de Projeo, que consiste de uma
cmera de vdeo (responsvel por capturar imagens dos participantes) e projees feitas
numa tela grande em 2D. Cada usurio pode interagir com os outros ou com os objetos
projetados. Seus movimentos so capturados e processados.
Pouco mais tarde a viso estereoscpica foi adicionada ao head mounted display, o que
aumentou consideravelmente a sensao de profundidade que, aliada ao rastreamento dos
movimentos da cabea do utilizador, aumentou a sensao de imerso.
Airbone Systems Simulator. 6DOF significa seis graus de liberdade, caracterizado pelos
movimentos de translao e rotao nos 3 eixos cartesianos (x, y e z), conforme ilustra a
Figura 2.2 (11).
A partir da, a RV comeou a ser utilizada nas reas educacional, mdica e comercial,
incluindo a utilizao da CAVE (2), composta por uma pequena sala, cujas paredes,
teto e cho servem para projetar imagens estereoscpicas. Nesse caso, o utilizador fica
completamente imerso nas imagens de alta resoluo.
No se pode julgar qual caso melhor, uma vez que se deve considerar o contexto
em que a avaliao feita. A Realidade Virtual No-Imersiva mais vantajosa quando se
leva em conta: i) os custos reduzidos devido a no haver necessidade de ter uma grande
estrutura apropriada como acontece com as CAVEs; ii) facilidade de uso e consequente
facilidade de disseminao; iii) possvel eliminao do desconforto de se utilizar um culos.
A Realidade Aumentada (RA) permite que o usurio veja o mundo real com objetos
virtuais superpostos ou combinados com ele. Portanto, a RA suplementa a realidade,
ao invs de substitu-la completamente. Para o usurio, os objetos reais e os virtuais
coexistem no mesmo espao.
A estereoscopia baseia-se na ligeira diferena com que cada olho do observador percebe
uma cena. A sobreposio das duas vises feita pelo crebro e isso confere noo de
tridimensionalidade. A estereoscopia pode ser classificada em ativa ou passiva. Ambas
utilizam culos para separar as imagens direcionadas para cada olho do observador.
2.4.1 Hardware
Dispositivos de entrada:
HMD (head-mounted display: exibe imagens do mundo virtual em duas telas, uma
para cada olho.
(Head-coupled display: caixa suspensa num brao mecnico, contendo dois monitores
para o qual o utilizador olha. Tem a vantagem de no apresentar o desconforto
causado pelo peso do capacete, mas o usurio deve ficar praticamente imvel.
2.4.2 Software
(Softwares de autoria englobam linguagens (como VRML (16), X3D (17), 3DMLW
(18), Collada (19), O3D (20)), bibliotecas grficas (como OpenGL (21), Java 3D (22)),
Toolkits, (como VizX3D, Eon Studio (23)). A programao envolve modelagem 3D,
preparao e manipulao de texturas, manipulao de som, elaborao de animaes e
o que mais for necessrio para o contexto do domnio explorado pela Realidade virtual.
Na parte de suporte a tempo real, o software responsvel pelas funes mais crticas
num ambiente de Realidade Virtual: interao com dispositivos especiais; processamento
da interface com o usurio; tratamento de visualizao e interao.
Captulo 3
Sistemas de Realidade Virtual Multiusurios
Distribudos e Trabalho Colaborativo
De grande importncia so as redes de dados para os AVDs, pois toda informao que
afete o ambiente virtual deve passar por elas. Elas influenciam dramaticamente na sen-
sao de realidade do AVD, uma vez que redes lentas inviabilizam a sensao de compar-
tilhamento de tempo. Para que o ambiente virtual possa ser sintetizado necessrio que
vrias mquinas participantes mantenham um conjunto de informaes variveis sobre o
ambiente: o conceito de estado compartilhado. Outra tcnica possvel de ser empregada
a regenerao frequente de estado, um modelo de distribuio de informaes no qual
cada entidade do AVD est sob controle de uma mquina participante especfica. Cada
mquina responsvel por enviar periodicamente a todos os participantes informaes
3.1 Ambientes Virtuais Distribudos 32
sobre o estado das entidades sob seu controle. Pode-se utilizar, ainda, o (Dead-Reckoning
que, alm de minimizar a troca de mensagens, suporta atrasos de comunicao, traba-
lhando com a previso da posio de um elemento, levando em conta o seu trajeto, velo-
cidade e posio anterior, decorrido um certo tempo. Todas as mquinas fazem o mesmo
clculo de previso e reposicionam o elemento; aquele que estiver gerenciando o elemento
conseguir verificar a diferena da trajetria real com a trajetria calculada. Sempre que
essa diferena atingir um valor mximo, o valor real da posio ser, ento, comunicado s
outras mquinas para devida correo. Dessa forma, no haver necessidade de informar
continuamente a posio de um elemento para outras mquinas, o que diminuir bastante
a comunicao pela rede (24).
O sistema deve ser capaz de lidar com falhas, como resolver situaes em que mquinas
travam, so desligadas ou quando ocorrem erros nas redes de comunicao. Porm, esse
gerenciamento acrescenta mais um fator de carga e atraso nesses ambientes, exigindo,
tambm, um bom projeto do AVD.
3.1 Ambientes Virtuais Distribudos 33
A arquitetura SIMNET (32) foi criada para ser um ambiente distribudo de simulao
de tticas de combate e batalha. O projeto foi baseado em trs caractersticas principais:
arquitetura orientada a eventos de objetos; noo de ns de simulao autnomos; con-
junto de algoritmos de modelagem preditiva conhecidos como (Dead-Reckoning. Todas as
interaes entre as entidades so feitas por notificaes de eventos, descrevendo o estado
instantneo da entidade. Essa arquitetura evoluiu para um padro chamado DIS, sendo
mais genrico e flexvel quanto aos tipos de entidades, alm de permitir um nmero maior
de entidades e efeitos de ambiente.
virtuais bsicos com a caracterstica de no serem totalmente idnticos aos seus parti-
cipantes. A arquitetura composta por alguns servidores e clientes. De maneira geral
os ambientes virtuais construdos com BrickNet tm algumas caractersticas em comum:
orientados a objeto (os objetos encapsulam suas propriedades grficas, comportamentais
e de comunicao), contedos diferentes do ambiente virtual (cada participante gerencia
seu prprio ambiente virtual e seu conjunto de objetos).
Trabalho Colaborativo vem se tornando uma realidade cada vez maior no mundo
atual, onde vrias pessoas necessitam interagir entre si estando geograficamente em lugares
diferentes ligados por redes de computadores. O advento da internet, o aprimoramento
3.2 Trabalho Colaborativo 37
Esta tese no depende de CSCW em si, uma vez que CSCW uma rea interdis-
ciplinar que envolve, entre outras, sociologia e psicologia, que no esto no contexto.
Especificamente na rea de computao, CSCW define diversos conceitos e formas de
desenvolvimento de softwares voltados ao trabalho cooperativo/colaborativo. Porm, a
escolha por utilizar tcnicas de AVDs (veja item 3.1) e no os tipos de sistemas definidos
por CSCW dispensa a discusso desse ltimo.
A seguir so abordados alguns aspectos importantes que devem ser considerados para
o desenvolvimento de aplicaes colaborativas.
Alm das qualidades inerentes a qualquer bom software, como confiabilidade, robustez,
compatibilidade e reusabilidade, as aplicaes colaborativas requerem algo mais.
atualizao, acesso e qualquer outra atividade que as envolva possa se dar da maneira mais
eficaz possvel. As aplicaes colaborativas devem ter ferramentas para a manipulao de
textos, grficos, sons, imagens ou animaes. No contexto deste trabalho, esses requisitos
so contemplados com o uso de tcnicas de AVDs.
Captulo 4
A Importncia da Visualizao Molecular
Interativa e Imersiva para a Biotecnologia e
Mecanismos de Ao dos Frmacos
4.1 A Biotecnologia
O termo biotecnologia tem sido definido de vrias formas, mas nenhuma delas conse-
gue descrever exatamente seu significado (36). Algumas tentativas so: Qualquer tcnica
utilizada em organismos vivos, ou substncias oriundas deles, para fazer ou modificar um
produto, para melhorar plantas ou animais, ou para desenvolver micro-organismos para
fins especficos United States Congresss Office of Technology Assessment.
Biotecnlogos japoneses definem biotecnologia como uma tecnologia que utiliza fen-
menos biolgicos para copiar e manufaturar vrios tipos de substncias.
conhecimentos sobre os processos biolgicos e sobre as propriedades dos seres vivos, com
o fim de resolver problemas e criar produtos de utilidade.
H diversas reas, entre outras, em que a biotecnologia tem papel importante (37):
Indstrias farmacuticas;
Indstrias alimentcias;
Indstrias qumicas;
Medicina;
Agricultura;
Proteo ambiental;
Controle de poluio;
Purificao de gua;
Tratamento de resduos
A maioria dos frmacos age com base em suas estruturas qumicas e propriedades
fsico-qumicas, a partir da sua interao com os componentes macromoleculares do orga-
nismo. Essas interaes alteram a funo do componente envolvido, produzindo alteraes
bioqumicas e fisiolgicas que caracterizam a resposta ao frmaco. Ao componente do or-
ganismo com o qual o frmaco interage d-se o nome de receptor farmacolgico. Daqui
em diante o termo receptor1 ser usado como referncia a receptor farmacolgico, exceto
em ocasies com indicao contrria.
Para que o frmaco produza seu efeito teraputico ou cientfico, ele deve atuar se-
letivamente sobre determinadas clulas ou tecidos, isto , deve possuir um alto grau de
especificidade de stio de ligao. O mesmo ocorre com as protenas-alvo dos frmacos, que
apresentam elevado grau de especificidade de ligante, reconhecendo precisamente apenas
os ligantes de determinado tipo e ignorando outras molculas (1).
importante citar que algumas drogas, como por exemplo diurticos osmticos, po-
dem no envolver receptores da maneira como estes normalmente so definidos (40).
Porm, o contexto desse trabalho situa-se na interao frmaco-receptor e, por isso,
dada nfase nesse caso.
Receptores podem ser de vrias classes, mas dois tipos predominam (41):
Molculas consideradas como receptores gerais, como enzimas, lipdios e cidos nu-
clicos
missores, enzimas das vias metablicas, protenas envolvidas nos processos de transporte,
protenas estruturais, protenas de membrana, etc. A Figura 5 mostra algumas prote-
nas de membrana celular agindo como receptores. Protenas so importantes receptores
farmacolgicos porque atuam como receptores de ligantes reguladores endgenos. Alguns
frmacos atuam nesses receptores fisiolgicos e, geralmente, so seletivos porque os recep-
tores fisiolgicos so especializados em reconhecer e responder com grande seletividade s
molculas sinalizadoras especficas. Por outro lado, outros componentes celulares tam-
bm podem ser receptores farmacolgicos, como os cidos nucleicos, especialmente para
frmacos quimioterpicos usados no tratamento de cncer (41).
5.1 Introduo
Em 1965 Cyrus Levinthal (42) criou o primeiro sistema de visualizao molecular inte-
rativo (SVMI). Esse programa permitia a um usurio alterar velocidade de movimentao
e orientao da molcula utilizando um dispositivo primitivo precursor do (track-ball. Era
possvel selecionar itens de menu, escolher um objeto e dar zoom em partes importantes
da molcula.
Daquela poca at os dias atuais, muitos outros sistemas de visualizao molecular in-
terativos foram desenvolvidos, alguns utilizando tecnologias imersivas e/ou colaborativas.
medida que foi surgindo cada avano tecnolgico da computao, este era incorporado
por algum SVMI.
tadas i) interface entre cientistas e o modelo molecular e ii) interface entre o software
e os dados. No primeiro caso, a realidade virtual usada para fazer uma forte ligao
entre o usurio e o modelo molecular (43).
difundidos no meio acadmico so Jmol ( (44), (45)), VMD (46), PyMol (47), Chimera
(48), SwissPDBViewer (49) e RasMol (50). Este ltimo j est obsoleto, tendo sido
substitudo pelo OpenRasMol, este pelo Chime e este pelo Jmol. A tarefa de relacionar
todos os visualizadores sem correr o risco de ignorar algum difcil, mas a maior parte
deles est listada abaixo:
VRMol (51)
VMD (46)
PyMol (47)
Chimera (48)
SwissPDBViewer (49)
RasMol (50)
Cn3D (56)
Dino3D (57)
MollyCule (62)
MolScript (64)
5.2 Visualizadores Moleculares 48
ZMM (65)
ProCreate (66)
QuteMol (71)
Raster3D (73)
SweetMollyGrace (75)
Vida (77)
ViewMol (78)
5.2.1 Jmol
Ghemical
PDB (83) - Protein Data Bank, Research Collaboratory for Structural Bioin-
formatics
Animaes
Vibraes
Seu motor grfico completamente escrito em Java, sem utilizao de Java3D, OpenGL,
DirectX ou qualquer tipo de acelerao por hardware. O mecanismo de renderizao foi
construdo especialmente para exibir molculas, fazendo um timo trabalho ao desenhar
esferas e cilindros. Jmol implementa completamente a tecnologia z-buffer, separando a
representao de cada pixel de maneira que os valores RGB sejam armazenados numa es-
trutura e a profundidade dos pontos armazenada em outra. Durante o ciclo de repintura,
a cena completa renderizada na primeira estrutura; ento, a cena desenhada como
imagem numa simples operao (Figura 5.1).
5.2 Visualizadores Moleculares 51
(a) A (b) B
(c) C (d) D
(e) E (f) F
5.2.2 VRMol
Este sistema (51) utiliza conceitos de realidade virtual e sistemas distribudos na cria-
o de um ambiente virtual distribudo para visualizao de protenas. Foi implementado
com a linguagem Java, incluindo as APIs Java 3D e Java RMI, visando permitir que
diversos pesquisadores troquem informaes de uma maneira rpida e eficiente.
Marvin Space (84) faz parte da sute de aplicativos Marvin, criada pela ChemAxon,
empresa especializada no desenvolvimento de softwares para a indstria farmacutica e
de biotecnologia (Figura 5.2).
5.2 Visualizadores Moleculares 53
O software foi desenvolvido na linguagem Java, o que permite sua utilizao em qual-
quer sistema operacional compatvel com essa tecnologia. Caracteriza-se por proporcionar
ao usurio:
Recurso de zoom;
Recurso de exibio de vrias janelas de visualizao. Cada janela pode exibir uma
estrutura diferente;
Definio de rtulos para qualquer elemento visvel; podem ser coloridos para faci-
litar a identificao;
5.2.4 VMD
(46)Software grtis, cujos exemplos de visualizao podem ser vistos na Figura 5.3,
e de cdigo aberto que se prope a resolver desafios na rea de visualizao molecular,
incluindo:
Interao direta com aplicativos de dinmica molecular para que possa exibir os
resultados obtidos por eles;
5.2.5 PyMol
5.2.6 Chimera
Software de uso livre para a comunidade acadmica ou para entidades sem fins lu-
crativos. composto por um ncleo dividido em duas camadas (a primeira escrita em
C++ e a segunda em Python), que oferece servios bsicos de visualizao (transparn-
cia, ball-and-stick, space-filling, solid surface) e por extenses (tambm escritas em C++
ou Python) para aumentar suas funcionalidades. Aceita comandos por mouse e teclado
(interface grfica) ou por texto atravs de comandos (Figura 5.5).
5.2 Visualizadores Moleculares 57
Merece especial destaque o mdulo colaborativo. Ele possibilita que vrios pesqui-
sadores compartilhem a sesso de modelagem molecular em tempo real. Esse mdulo
trabalha em baixo nvel, transmitindo pequenas mensagens (atravs de CORBA (Com-
mom Object Request Broker Architecture) (29)) que descrevem apenas os dados que foram
modificados. utilizada arquitetura em estrela, em que, por definio, um computador
central conectado a vrios nodos (usurios executando o software).
5.3 Editores/Construtores de Molculas 58
5.2.7 SwissPDBViewer
ECCE (88)
ArgusLab (89)
ChemCraft (90)
ChemBioDraw (91)
packages (92)
Ghemical (93)
gOpenMol (94)
Yasara (96)
Ascalaph (97)
Prochemist (98)
Sybyl uma sute de aplicativos. O mdulo Base fornece recursos como construo,
edio e visualizao de pequenas e grandes molculas.
Scigress (87) um pacote de modelagem grfica equipado com diversos recursos que
auxiliam a diminuir o tempo necessrio descoberta de compostos teis. Assim como o
Sybyl, o Scigress tambm um software proprietrio.
5.3.4 ECCE
Submisso remota de clculos para estaes Unix e Linux, Clusters Linux e super-
computadores. Sistemas de gerenciamento de filas suportados:
LSF
PBS
NQE/NQS
LoadLeveler
Maui Scheduler.
ssh/scp
telnet/ftp
5.4 Visualizadores Moleculares com Tecnologias Imersivas 63
rsh/rcp
Globus.
Obviamente no possvel enxergar uma molcula a olho nu, mas mesmo quando
observada na tela de um computador, a geometria tridimensional complexa e irregular
das grandes biomolculas de difcil compreenso visual. Para melhor entendimento
emprega-se a realidade virtual que, por sua vez, faz uso de tcnicas imersivas para criar a
sensao de o usurio fazer parte da molcula, apresentando ideias abstratas de maneira
intuitiva, como descrito no Captulo 2.
5.4.2 VRDD
5.4.3 Kinimmerse
O prottipo usou como base o software MolScript (64), melhorando algumas carac-
tersticas. Tornou possvel a explorao de at quatro estruturas moleculares complexas
num ambiente virtual como uma CAVE (15). Foram adicionados recursos como nave-
gao interativa utilizando um controlador parecido com um pequeno basto 6DOF, um
sensor eletromagntico para monitoramento de posio da cabea e mo do usurio e viso
estereoscpica.
1. Um cientista cria uma entrada wiki no sistema contendo uma molcula e um texto
descritivo no qual so incorporados comandos do Jmol ligados a botes;
2. Com o documento criado, Jmol usado diretamente para interagir com os dados gra-
vados, exibindo a molcula e respondendo a comandos do mouse sobre a imagem. Ao
clicar com o boto direito do mouse, todos os recursos do Jmol so disponibilizados
1 Sistema em formato de site web no qual as pessoas podem colaborar e construir juntas um contedo
5.5 Visualizadores Moleculares com Tecnologias Colaborativas 71
3. Em algum momento um segundo usurio acessa a pgina criada pelo primeiro ci-
entista. Ele pode, por exemplo, inserir um novo (script diretamente no Jmol. Ele
pode criar um comentrio, editar a pgina para incluir o novo (script ou somente
baixar para seu computador o arquivo que define a molcula;
4. Ao longo do tempo, cada cientista pode revisar o histrico do documento, com suas
vrias verses.
5.5.2 AMMP-Vis
com outros no sistema. A interao e manipulao so feitas atravs de gestos das mos.
Cada usurio pode criar sua prpria rea de interesse definindo uma caixa delimitadora;
objetos fora dessa rea so obscurecidos de forma a deixar enfatizada apenas a seleo.
Essa rea visvel aos outros participantes. Alm disso, o ambiente integrado a um
software de simulao de dinmica molecular chamado AMMP. O sistema composto
por um servidor AMMP ( responsvel pela mecnica molecular do sistema, mantm o
estado atual da molcula e recebe/transmite as atualizaes de cada cliente), um servidor
de orientao (monitora os dados do cliente, incluindo localizao e orientao, sua rea
de foco, escala e informaes de rastreamento da mo) e um servidor de comunicao.
Cada cliente se comunica com os servidores atravs de soquetes UDP e TCP. A interao
entre usurios feita pelo Skype (110). O sistema flexvel, permitindo uso de luvas e
(head-mounted display ou de apenas um monitor simples com manipulao via teclado e
mouse. Usurios podem entrar, sair e retornar ao sistema quando desejarem, voltando ao
mesmo estado de quando deixaram o ambiente (Figuras 5.18 e 5.19).
grandes, embora no se saiba se o gargalo do sistema a rede (por causa do grande nmero
de atualizaes), a placa grfica (devido ao grande nmero de polgonos do modelo) ou o
servidor AMMP (por causa das interaes entre tantos tomos).
Em 2003, o software Jmol foi adaptado para uso colaborativo utilizando a API ((ap-
plication program interface) JXTA (111). Esse sistema (112) baseou-se na interceptao
e transmisso de eventos do Jmol a outros usurios por uma rede (peer-to-peer formada
com o auxlio de JXTA. Porm, como no fazia parte do escopo do trabalho, no houve
preocupao com o desempenho devido complexidade que a comunicao representa,
especialmente no tocante latncia da rede (no caso, internet) (Figura 5.20).
5.5 Visualizadores Moleculares com Tecnologias Colaborativas 74
O sistema foi desenvolvido com o (toolkit VrTool. Cada usurio tem seu prprio ponto
5.5 Visualizadores Moleculares com Tecnologias Colaborativas 75
de vista, mas este pode ser sincronizado com todos os outros utilizadores pelo operador
principal, permitindo haver discusso sobre a mesma viso. Esse software permite apenas
2 usurios simultaneamente no ambiente virtual, embora os autores digam que a nica
limitao terica para o nmero de usurios seria a largura de banda da rede.
5.5.5 MICE
6.1 Middleware
2. Remote Procedure Calls: permitem que clientes em uma aplicao chamem funes
para acessar servidores em sistemas remotos;
4. Object Request Broquers: permitem que objetos que compem uma aplicao sejam
distribudos em redes heterogneas.
Object Request Broker (ORB) uma tecnologia que gerencia a comunicao e a troca
de dados entre objetos, provendo interoperabilidade em sistemas de objetos distribudo
6.3 Corba 78
(6).
A plataforma JAMP utiliza RMI em sua implementao, pois nativa do Java e apre-
senta a vantagem de possibilitar a passagem de qualquer tipo de informao serializvel
por parmetro, incluindo objetos e classes. Por esses motivos, importante apresentar o
padro RMI.
6.3 Corba
As aplicaes CORBA so compostas por objetos. Para cada tipo de objeto definida
uma interface, que parte do contrato que o objeto servidor oferece aos clientes que o
invocam. Qualquer cliente que deseja invocar uma operao no servidor necessita dessa
interface para especificar a operao que quer executar e serializar as propriedades envia-
das como parmetros. Quando a invocao encontra o objeto destino, a mesma interface
6.4 Java RMI 79
usada para desserializar as informaes recebidas para que o objeto possa processa-las.
A definio dessas interfaces independente da linguagem de programao. A separao
entre interface e implementao a essncia de CORBA. A interface para cada objeto
definida muito estritamente. Porm, a implementao de um objeto - seu cdigo de
execuo e seus dados - encapsulada. Os clientes acessam objetos somente atravs de
sua interface anunciada, invocando somente as operaes que o objeto expe atravs de
sua interface, com apenas os parmetros (entrada e sada) includos na invocao. Em
CORBA, cada instncia de objeto tem sua prpria referncia de objeto nica, um (token
eletrnico de identificao. Os clientes usam as referncias de objeto para direcionar suas
invocaes, identificando para o ORB a instncia exata que eles querem invocar. Quando
ele est invocando uma operao na instncia do objeto, na verdade est invocando o (stub
que atua como um (proxy. Passando pelo (stub no lado do cliente, a invocao continua
atravs do ORB e do esqueleto no lado da implementao, para chegar ao objeto onde ele
executado.
Para chamar a instncia de objeto remoto, o cliente primeiro obtm sua referncia de
objeto. Para fazer a chamada remota, o cliente usa o mesmo cdigo que ele usaria como
se estivesse acessando o programa localmente, porm substituindo a referncia de objeto
para a instncia remota. Quando o ORB examina a referncia de objeto e descobre que o
objeto de destino remoto, roteia a invocao at o objeto remoto do ORB. Esse processo
padronizado em dois nveis principais: Primeiro, o cliente sabe o tipo de objeto que est
invocando e os esqueletos do cliente e do servidor so gerados a partir da mesma definio.
Isso significa que o cliente sabe exatamente quais operaes ele pode invocar, quais so os
parmetros de entrada e onde eles tm que ir na invocao; Quando a invocao atinge o
alvo, tudo est l e no lugar certo. Em segundo lugar, ORB do cliente e ORB do objeto
deve concordar com um protocolo comum - ou seja, uma representao para especificar o
objeto de destino, operao, todos os parmetros (entrada e sada) de cada tipo que eles
podem usar, e como tudo isso representado.
ou mais interfaces remotas, que declaram os mtodos do objeto remoto. Uma invocao
de um mtodo de um objeto remoto possui a mesma sintaxe de uma invocao de um
mtodo de objeto local. O modelo RMI utiliza serializao de objetos para convert-los em
(streams de bytes para a transmisso. Qualquer tipo de objeto pode ser passado durante
a invocao, incluindo, mas no se limitando a, tipos primitivos, classes bsicas e classes
definidas pelo usurio.
RMI utiliza um mecanismo padro para comunicao com objetos remotos: (stubs e
(skeletons(Figura 6.1)((118)). Um (stub para um objeto remoto atua como representante
local de um cliente ou (proxy para o objeto remoto. O chamador invoca um mtodo no
(stub, que responsvel pela realizao da chamada do mtodo no objeto remoto. Em
RMI, um (stub para um objeto remoto implementa o mesmo conjunto de interfaces que
um objeto remoto implementa. Quando um mtodo (stub invocado, ele faz o seguinte:
Inicia uma conexo com a JVM remota que contm o objeto remoto;
Na JVM remota, cada objeto remoto pode ter um (skeleton correspondente. O (skele-
ton responsvel por despachar a chamada para a implementao real do objeto remoto.
Quando um (skeleton recebe uma chamada de mtodo, ele faz o seguinte:
JAMP (Java Architecture for Media Processing) (3) (4) (5) (6) (7) foi inicialmente
concebida para auxiliar no desenvolvimento de aplicaes multimdia cooperativas em
ambientes distribudos. Porm, sua evoluo a tornou um (middleware para computao
distribuda.
Camada de Aplicao: onde ficam as aplicaes que fazem uso dos servios dispo-
nveis na plataforma atravs dos (frameworks de acesso. Essas aplicaes utilizam
a JAMP como plataforma de distribuio;
ao servidor JBroker, que um programa que contm uma base de dados dos
servidores/servios disponveis no ambiente. Por intermdio do JBroker, os cli-
entes JAMP podem invocar mtodos em objetos remotos na rede sem conhecer
detalhes da localizao, implementao e protocolos dos objetos invocados.
Possui os seguintes servios:
Uma srie de estudos e anlises foi realizada para que a arquitetura pudesse ser pro-
jetada e construda, incluindo estado da arte em visualizao molecular, protocolos
de transportes de pacotes em redes de computadores e o problema da comunicao
em redes (best-effort.
(CAC), como o Resource Reservation Protocol (RSVP) (121). Esses esquemas exigem que
a rede mantenha informaes sobre cada conexo e decida se as conexes so admitidas
ou rejeitadas, de modo que seja absolutamente garantida a largura de banda para as
conexes admitidas, do princpio ao fim. Quando a carga das conexes solicitadas
superior capacidade da rede, alguns novos usurios sero rejeitados, a fim de manter as
garantias de banda reservadas para os usurios j admitidos. Infelizmente, muito poucos
pontos na internet funcionam assim. A grande maioria das redes est estabelecida sob
o esquema de best-effort (melhor-esforo), no qual as informaes sobre cada conexo ao
longo do caminho percorrido pelos dados no so armazenadas em roteadores e switches,
uma vez que no h nenhuma reserva de recursos para uma conexo. Os remetentes
decidem por si s se e quanto devem enviar. A se inicia o problema da comunicao em
tempo real na internet.
Uma das contribuies desta tese a minimizao dos efeitos da latncia na internet
para comunicao entre grupos de pesquisa que utilizam visualizao molecular em seus
7.1 O Problema da Comunicao em Tempo Real Via Internet 87
Tempo de propagao: o tempo que o pacote demora para percorrer todo o caminho
entre remetente e destino. Como tambm esperado que os grupos estejam dispersos
geograficamente, essa varivel tem grande peso no valor total da latncia.
Nota-se dois saltos nos tempos de resposta. O primeiro varia de menos de 10 mi-
lissegundos para pouco mais de 100 milissegundos (entre os roteadores 6 e 7). No
segundo salto os tempos passam para mais de 200 milissegundos (entre os roteadores
9 e 10). Considerando que a mquina origem est situada no Brasil e a destino est
no Reino Unido, os saltos de tempo ocorrem, respectivamente, na sada do Brasil
para os Estados Unidos e na sada deste para a Europa;
O pacote passou por 18 roteadores at chegar ao destino; alm disso, possvel que
haja switches envolvidos no caminho do pacote que no aparecem nessa lista. Cada
um desses equipamentos adiciona seu tempo de processamento soma que define o
tempo total de latncia;
O valor total mdio da latncia entre os dois pontos testados de 232 milissegun-
dos. Isso significa que nenhum pacote trafegado entre eles ter tempo inferior a
aproximadamente esse valor.
7.2 Anlise do Estado da Arte em Visualizao Molecular 88
PyMol exporta imagens moleculares com altssima qualidade, mas tambm no tem
recursos para colaborao e nem de realidade virtual;
VRMol utiliza conceitos de realidade virtual e Java RMI para a criao de um am-
biente virtual colaborativo. Porm, como acontece com outros softwares do gnero,
no foi abordado o problema de comunicao via internet; apenas discutido o tema
comunicao de maneira geral. Outra limitao importante do VRMol o fato de
ele ter sido desenvolvido para exibir somente molculas de protenas descritas em
arquivos com formato PDB.
MICE no apresenta qualquer forma de realidade virtual e, assim como os outros sis-
temas, oferece recurso para colaborao sem o devido tratamento quando os usurios
esto interligados via internet.
O sistema colaborativo
A evoluo das comunicaes atravs da Internet nos ltimos anos aumentou a procura
por uma nova classe de protocolos. A pilha TCP/IP, com o tradicional servio TCP
confivel/ordenado ou UDP no confivel/desordenado, j no mais suficiente para uma
ampla gama de aplicaes. Protocolos orientados a aplicao que ativam/controlam o
equilbrio de QoS podem oferecer uma soluo alternativa. Por exemplo, uma vez que o
vdeo ou udio podem tolerar perdas de pacotes, pode-se favorecer a largura de banda em
detrimento da confiabilidade.
TCP (126) um protocolo de transporte que trabalha sobre IP, confivel e orientado
a conexo. Sua misso entregar corretamente os dados enviados. Para atingir seu
objetivo, o TCP tem procedimentos de configurao de conexo e desconexo usando um
7.3 Anlise dos Protocolos de Transporte 93
O Real Time Protocol (RTP) (128), embora funcionando sobre TCP ou UDP, um
protocolo de transporte utilizado para trfego com requisitos de tempo real e/ou multi-
mdia, especialmente udio e vdeo, sobre servios multicast ou unicast em redes IP. RTP
foi especificado pelo Internet Engineering Task Force (IETF) para preencher as lacunas
do UDP (transmisso no confivel e sem conexo de dados) nas redes IP.
RTP fornece servios de entrega fim-a-fim para dados com caractersticas de tempo
real, como udio e vdeo interativos. No entanto, o RTP no fornece nenhum me-
canismo para assegurar a entrega em tempo adequado: ele precisa do apoio das
camadas mais baixas da rede que tm controle direto sobre os recursos em roteado-
res e switches, como RSVP (121), para fornecer os recursos necessrios.
7.3 Anlise dos Protocolos de Transporte 94
Para o transporte de dados em tempo real, o UDP seria o protocolo mais aconselhvel
principalmente por causa de sua entrega rpida. No entanto, ele apresenta problemas de
congestionamento, o que se traduz em desprezo de pacotes e/ou pacotes recebidos fora
de ordem. A soluo implementar UDP com controle de congestionamento e handshake
durante a configurao da conexo. Aqui onde entra o DCCP. Ele fornece as seguintes
funcionalidades:
Ele tem opes que dizem ao remetente, com alta confiabilidade, que pacotes atin-
giram o receptor e se os pacotes foram marcados com ECN, corrompidos ou descar-
tados no buffer de recepo.
No incio de uma conexo DCCP, os pontos finais devem concordar sobre um conjunto
de parmetros, ou seja, os mecanismos de controle de congestionamento a serem utilizados.
DCCP fornece um conjunto mnimo de opes para negociar os valores das caractersticas
gerais, onde um recurso simplesmente um valor a ser negociado.
Hardware:
Software
* Nos servidores de grupo funciona como ponte entre cada ambiente local e
o global e faz atualizaes no banco de dados do servidor onde est sendo
executado;
* o servidor central atualiza o banco de dados e pode, opcionalmente, servir
de ponte entre servidores de grupo, conforme descrito no item 8.4.2;
JMF (Java Media Framework): permite a interao entre usurios por texto
e/ou voz (o recurso de vdeo, embora disponvel no JMF, no foi implementado
nesta verso do ambiente);
(a) Abre sesso JAMP com o Servidor Central atravs da execuo do aplicativo
Comunicador. Esse servidor se registra no Servidor Central para receber/enviar
mensagens;
3. Os clientes executam o Jmol adaptado e este cria sesso Multicast com o servidor
de grupo.
Esta ao gera um evento no Jmol e este envia mensagem multicast para todos os
computadores do grupo, incluindo o servidor, contendo informaes sobre o evento;
O servidor do grupo recebe o evento via fwMol, o registra em seu banco de dados
e, atravs do Comunicador, repassa a mensagem aos outros servidores do ambiente
global (utilizando JAMP-RTEP), incluindo o servidor central;
O Ambiente Local uma clula da estrutura global. Porm, ele no tem conhe-
cimento da existncia do ambiente externo. A interface entre essas duas reas feita
pelo framework Comunicador, que executado no servidor local. O esquema lgico est
representado na Figura 8.3:
8.2.1 Jmol
Para que o Jmol fosse capaz de trabalhar em ambiente colaborativo, houve necessidade
de realizar algumas adequaes, de maneira que os eventos gerados a partir de aes
do usurio pudessem ser transmitidos e processados por instncias do software sendo
executadas em outras mquinas.
8.2 Modelo do Ambiente Local 103
Aps estudo do cdigo-fonte do Jmol, foi possvel concluir que os mtodos respon-
sveis pelas transformaes solicitadas pelo usurio na molcula em estudo esto na
classe org.jmol.viewer.Viewer. Assim, cada evento gerado por uma ao do usurio
(ao diretamente ligada visualizao) executa o mtodo correspondente na classe
org.jmol.viewer.Viewer.
Veja, como exemplo, o mtodo zoomBy, um dos responsveis por aplicar zoom na
molcula exibida. Na classe org.jmol.viewer.Viewer ele est definido originalmente como
na figura 8.4
Este mtodo foi alterado para enviar mensagem contendo informaes do evento para
o servidor do grupo (Figura 8.5)
H outras alteraes significativas no Jmol para permitir interao entre usurios via
texto/voz, mas isso ser exposto no item 8.4.3.
Este modelo utiliza uma arquitetura semelhante mestre-escravo com replicao (14),
isto , h um computador que comanda, aqui chamado de Atuador, e os ns comandados
por ele. Em todos h um Jmol sendo executado. Conceitualmente esse ambiente muito
semelhante ao Ambiente Local, pois o servidor recebe os eventos dos outros grupos e os
repassa aos seus clientes ou coordena a entrega das mensagens enviadas pelo computador
atuador.
8.4 Modelo do Ambiente Global 105
Infraestrutura fsica e layout do ambiente real sero utilizados de acordo com os re-
cursos disponveis nas salas de multiprojeo onde o sistema ser executado. Exemplos
podem ser encontrados em (132) e (133). O software funciona na configurao de multi-
projeo com estereoscopia passiva.
O modelo lgico apresentado na Figura 8.8. Nota-se que no foi mostrado o fra-
mework Multicast em Servidores de Grupo, pois ele faz sentido somente no Ambiente
8.4 Modelo do Ambiente Global 106
Uma opo interessante seria o uso de SCTP. Porm, esse protocolo no tem suporte
nativo em muitos sistemas operacionais, o que, em parte, foge proposta deste trabalho:
funcionar na maioria das plataformas de hardware/software. Existem pacotes com drivers
que podem ser instalados na maior parte dos sistemas, mas podem no ser confiveis.
SCTP tambm no disponibiliza API (Application Program Interface) na linguagem Java.
Isso no impede que SCTP seja utilizado no sistema, mas nesse momento exige um passo a
mais para fazer a interface entre Java e C++ (SCTP est disponvel nativamente somente
nessa linguagem).
8.4 Modelo do Ambiente Global 108
No h soluo ideal para o problema apontado em 7.1, uma vez que a latncia da rede
um fator contra o qual no se pode lutar, pois, como visto, as componentes distncia
e processamento realizado por roteadores tm influncia direta sobre ela. Mas o uso de
algumas tcnicas pode amenizar seus efeitos negativos. O protocolo RTEP foi criado
buscando atingir esse objetivo.
Como ser visto no item 8.4.2.3, possvel que um pacote RTEP contenha mais de
1 evento. O campo NumEventos informa a quantidade de eventos contidos no pacote.
No h necessidade de utilizar delimitadores entre cada evento e entre cada parmetro,
pois o decodificador do pacote sabe como desmont-lo e obter cada poro de informao
a partir do ID do Evento.
Cada servidor mantm um grafo de roteamento em forma de rvore sob o seu ponto de
vista e mantm em memria essa e as rvores dos outros servidores, para que possa saber
se ele deve replicar para outro servidor uma mensagem recebida. Ele envia mensagens
somente aos ns-filhos de primeiro nvel.
Conforme definido na RFC 3550, o jitter calculado para dois pacotes consecutivos
de acordo com a Equao (8.1). Seja Si o timestamp do pacote i, Sj o timestamp do pacote
j, Ri o horrio de chegada do pacote i ao receptor, Rj o horrio de chegada do pacote
8.4 Modelo do Ambiente Global 111
j ao receptor e J(i-1) o jitter anterior. O jitter atual pode ser calculado utilizando-se a
Equao (8.1):
D(i, j) = (R j S j ) (Ri Si )
|D(i 1, i)| J(i 1) (8.1)
J(i) = J(i 1) +
16
Se SB 30 SB = 30
EvPack til quando h vrias mensagens na fila a serem enviadas. Pode ser mais
vantajoso enviar vrias mensagens em um mesmo pacote ou enviar vrios pacotes com
apenas uma mensagem cada, ou com duas mensagens cada, ou com trs, e assim por
diante, at atingir o tamanho mximo de 1200 bytes. Isso se justifica pelo fato de que,
normalmente, pacotes IP no so fragmentados quando no atingem tamanho de 1200
bytes de dados. Considera-se, ainda, que os tamanhos das mensagens dependem do evento
gerado e dos parmetros a serem repassados aps serializao. Porm, o valor de 1200
bytes por pacote muito dificilmente seria atingido, pois a gerao de eventos no to
grande a esse ponto.
8.4.4 Discusso
A arquitetura descrita nesta tese tem por objetivo criar um ambiente virtual colabo-
rativo para reunir grupos de pesquisa localizados geograficamente distantes, conectados
8.4 Modelo do Ambiente Global 114
via internet, para visualizao molecular contando com elementos de realidade virtual e
multiprojeo, com foco na minimizao dos efeitos do atraso tpico na comunicao pela
internet (latncia).
A escolha por criar esse novo protocolo se deve ao fato de o sistema ser baseado em
eventos e possibilidade de buscar a minimizao dos efeitos negativos do atraso nesse
contexto, o que no tratado pelos protocolos apresentados no Captulo 7. O RTEP
utiliza RTP/RTCP e UDP em suas camadas inferiores. Essa combinao foi escolhida
porque a que apresenta recursos que mais se aproximam dos objetivos desta tese; os
mais importantes so carimbo de tempo (ou timestamp) e numerao sequencial, que
permitem melhor controle da comunicao e eventual reenvio de eventos perdidos. Uma
comparao entre esses recursos pode ser vista na Tabela 8.1.
RTEP;
Soquetes TCP;
RMI.
Em todos esses computadores foi instalado o sistema operacional FreeBSD (135) com
Kernel modificado. A escolha por esse sistema ser justificada nos itens 9.1.1 e 9.1.2.
9.1 Metodologia de Testes 116
O sincronismo de tempo entre os servidores foi obtido com o uso do software ntp
(136). Todos os servidores sincronizam seus relgios entre eles, sendo o Servidor Global
o primeiro na lista de prioridades de cada servidor. necessrio que a preciso do ntp
seja da ordem de 1 milissegundo. O FreeBSD oferece essa granularidade atravs da opo
de kernel options HZ=1000. Como curiosidade, o sistema operacional Windows oferece
granularidade de 10ms, o que tornaria os resultados do teste imprecisos.
9.1 Metodologia de Testes 118
podem trafegar por rotas diferentes e, tambm, devido diferena de trfego na rede nos
dois sentidos e em momentos distintos. Alm disso, os valores da vazo tambm podem
no ser simtricos pelos mesmos motivos.
>> Server1 Server2 Server3 Server4 Server5 Server6 Server7 Server8 Server9
Server1 - 5 3 35 230 120 420 125 240
Server2 3 - 170 22 190 260 380 210 320
Server3 12 190 - 16 70 90 480 300 220
Server4 40 30 12 - 140 290 800 150 20
Server5 260 180 65 170 - 170 210 180 80
Server6 110 230 95 300 190 - 560 290 240
Server7 420 380 480 750 210 560 - 650 360
Server8 100 190 290 130 160 310 650 - 100
Server9 220 340 230 16 110 250 360 110 -
A preparao para os testes foi feita de maneira que pudesse ser gerado um arquivo
de script contendo instrues para rotao, translao, zoom e seleo e identificao de
tomos de uma molcula. A gerao desse script se deu previamente em uma instncia
do Jmol executada em uma das mquinas do laboratrio. Os eventos foram gerados de
maneira a simular o uso realstico do visualizador e a chegar aos extremos: h momentos
com intensa gerao de eventos e outros em que nenhum ou poucos eventos so gerados.
O script inclui, ainda, marcao de tempo em que cada evento foi gerado com resoluo
de 1 milissegundo. Essa etapa de gerao do script durou 10 minutos. Ao todo foram
32.264 eventos.
9.1 Metodologia de Testes 120
>> Server1 Server2 Server3 Server4 Server5 Server6 Server7 Server8 Server9
Server1 - 1000 1500 800 600 2500 250 1500 600
Server2 1200 - 900 1000 1500 400 250 2500 4000
Server3 1800 800 - 9000 6000 7000 250 300 1200
Server4 700 1200 10000 - 300 500 250 2500 15000
Server5 700 1500 5000 200 - 1500 250 500 3500
Server6 3000 500 8000 800 2000 - 250 8000 9000
Server7 250 250 250 250 250 250 - 250 250
Server8 1200 3000 500 3000 800 10000 250 - 10000
Server9 500 4500 1000 10000 3000 8000 250 10000 -
As variveis medidas nos testes foram: Tempo Mdio de Entrega de Eventos, perda
de eventos e quantidade de eventos que chegaram ao destino em menos de 100ms.
Tempo Mdio de Entrega o tempo total decorrido desde a montagem do pacote que
carrega o evento no servidor 4 at o recebimento desse evento por cada um dos outros
servidores no ambiente de teste. uma das medidas da sensao de tempo real ao
usurio do sistema. No cdigo-fonte do prprio RTEP foram inseridas pores de cdigo
para aferio dessa varivel. Ao receber um pacote, o receptor grava o horrio de seu
relgio e a identificao do(s) evento(s) enviado(s).
9.1 Metodologia de Testes 121
TempodeEntrega = R S (9.1)
O Clculo do tempo mdio obtido pela soma dos tempos de entrega de todos os
eventos a um determinado servidor dividido pela quantidade de eventos.
EventosPerdidos
Perda = % (9.2)
EventosEnviados
Os resultados obtidos a partir dos trs testes realizados (RTEP, sockets TCP e RMI)
foram compilados em uma planilha para possibilitar o entendimento. Cada teste ser
apresentado em separado e, depois, ser feita a anlise comparativa entre os trs esquemas
de comunicao.
Os tempos mdios de entrega ficaram muito altos. Veja figura 9.4. O servidor
que recebeu os eventos mais rapidamente foi o 3. Por outro lado, o servidor 7,
cuja latncia era de 800ms, demorou 10 horas e 10 minutos para receber todos os
eventos, nmeros que mostram a inviabilidade do uso de RMI como protocolo de
comunicao de eventos quando h latncia na rede.
9.1 Metodologia de Testes 123
importante deixar claro que os esses resultados ruins se devem a alguns fatores
inerentes ao RMI:
Para a realizao desse teste, a comunicao via soquetes TCP foi implementada na
camada de infraestrutura da plataforma JAMP. Para cada evento gerado no atuador, o
9.1 Metodologia de Testes 125
Servidor 4 envia um pacote TCP diretamente para cada um dos outros servidores presentes
no ambiente.
O Tempo Mdio de Entrega ficou abaixo dos 600ms, com exceo do Servidor 7,
cuja latncia de ida de 800ms. Nesse caso, como ilustrado nas figuras 9.6 e 9.7, o
tempo foi de 1170ms.
Assim como ocorreu com RMI, aqui o trfego tambm se concentrou na sada do
Servidor 4, bem como os 258.112 eventos (32.264 para cada servidor) foram trans-
mitidos em 258.112 pacotes partindo apenas do servidor 4.
Houve descentralizao dos envios dos pacotes. O Servidor 4 enviou somente para
os Servidores 2, 3, 8 e 9. O Servidor 3 enviou para os Servidores 1, 5 e 6. Por
fim, o Servidor 5 transmitiu eventos para o Servidor 7. Isto est bem ilustrado no
grafo gerado pelo MessageRouting - veja figura 9.9. Portanto, o trfego no ficou
concentrado no Servidor 4.
So 4 os pontos principais a serem discutidos com base nos resultados dos testes:
Perda de Eventos
Tempo Mdio de Entrega dos Eventos A anlise dos dados mostra claramente
a vantagem do RTEP com relao a RMI e Sockets TCP. A figura 9.11 apresenta essa
comparao. Nota-se que o tempo mdio de entrega RTEP foi, no pior caso, 176% melhor
que sockets (para o Servidor 2) e 46556% melhor que RMI (para o Servidor 3) e, no
melhor caso, 793% melhor que sockets (para Servidor 1) e 2687007% melhor que RMI
(para Servidor 6). Na mdia dos 8 servidores, RTEP foi 419% melhor que sockets e
1024034% melhor que RMI considerando o tempo mdio de entrega de eventos.
9.1 Metodologia de Testes 129
Sem dvida pode haver casos em que esse ganho no seja to gritante. Ainda as-
sim, perceber-se- melhoria devido ao mecanismo EvPack, que mostrou-se eficiente, di-
minuindo consideravelmente a quantidade de pacotes enviados. Enquanto sockets e RMI
enviaram cada um 32264 pacotes para cada servidor, RTEP enviou apenas 19.233 pacotes,
transportando os mesmos 32264 eventos. Para garantir que no haja congestionamento,
nenhum pacote RTEP excede 640 bytes de tamanho.
10.0.1 Concluses
Este trabalho teve como objetivo a definio de uma arquitetura computacional para
visualizao molecular colaborativa com recursos de realidade virtual baseada em servi-
dores e grupos de trabalho dispostos em ambientes remotamente distribudos. Foi dada
nfase na busca pela minimizao dos efeitos negativos causados por atraso e jitter, ele-
mentos caractersticos e naturalmente presentes em redes best-effort, como o caso de
grande parte da internet atualmente.
Trabalho colaborativo
avaliar o desempenho tanto em redes best-effort como em redes prontas para QoS;
Testar o protocolo RTEP para suportar outras aplicaes com tamanhos e tipos
diferentes de mensagens
Referncias
13 PIMENTEL K; TEIXEIRA, K. Virtual Reality through the new looking glass. [S.l.]:
McGraw-Hill, 1993.
23 EON REALITY. Eon Studio. 01 2010. ltimo acesso em 20/02/2010. Disponvel em:
<https://www.eonreality.com/eon-studio/>.
52 MOLL, A. et al. BALLView: a tool for research and education in molecular modeling.
Bioinformatics, Oxford University Press (OUP), v. 22, n. 3, p. 365366, dec 2005.
56 WANG, Y. et al. Cn3d: sequence and structure views for entrez. Trends in
Biochemical Sciences, Elsevier BV, v. 25, n. 6, p. 300302, jun 2000.
58 CAN, T. et al. FPV. In: Proceedings of the 2003 ACM symposium on Applied
computing - SAC 03. [S.l.]: Association for Computing Machinery (ACM), 2003.
71 TARINI, M.; CIGNONI, P.; MONTANI, C. Ambient occlusion and edge cueing for
enhancing real time molecular visualization. IEEE Transactions on Visualization and
Computer Graphics, Institute of Electrical and Electronics Engineers (IEEE), v. 12, n. 5,
p. 12371244, sep 2006.
76 GOLOSOVA, O. et al. Unipro UGENE NGS pipelines and components for variant
calling, RNA-seq and ChIP-seq data analyses. PeerJ, PeerJ, v. 2, p. e644, nov 2014.
100 ANDERSON, A.; WENG, Z. Vrdd: Applying virtual reality visualization to protein
docking and design. Journal of Molecular Graphics and Modelling, Elsevier BV, v. 17,
n. 3-4, p. 180186, jun 1999.
104 SCHAEFFER, B.; GOUDESEUNE, C. Syzygy: native PC cluster VR. In: IEEE
Virtual Reality, 2003. Proceedings. [S.l.]: Institute of Electrical and Electronics Engineers
(IEEE), 2003. p. 1522.
125 POSTEL, J. User Datagram Protocol (RFC 768). [S.l.], 1980. Disponvel em:
<http://tools.ietf.org/pdf/rfc768.pdf>.
126 INSTITUTE, I. S. Transmission Control Protocol (RFC 793). [S.l.], 1981. Disponvel
em: <http://tools.ietf.org/pdf/rfc793.pdf>.
Referncias 142
128 KOISTINEN, T. Protocol Overview: RTP and RTCP. [S.l.]: Nokia Telecommuni-
cations, 2000.
130 KOHLER, E.; FLOYD, S. Datagram congestion control protocol (DCCP) Overview.
2003.
137 SWINK, S. Game Feel: A Game Designers Guide to Virtual Sensation. Taylor
& Francis, 2009. (Morgan Kaufmann Game Design Books). ISSN 9780123743282.
Disponvel em: <https://books.google.com.br/books?id=i9GfunWcB-oC>.
Glossrio
Ball and stick Modelo de visualizao molecular que pretende mostrar a posio tridi-
mensional dos tomos e as ligaes entre eles. Os tomos so representados por
esferas e as barras representam as ligaes. 46
Dead-Reckoning tcnica utilizada para predizer uma aproximao do estado das enti-
dades de um AVD nos perodos entre uma chegada e outra de atualizaes. 32
Feedback retorno. 23
Glossrio 144
Head Mounted Display dispositivo acoplado cabea que exibe imagens tridimensio-
nais e pode possuir sensor de movimentao. 22
Tracking rastreamento. 28
Web rede. Especificamente neste trabalho essa palavra refere-se a world wide web, o
popular WWW utilizado por navegadores para acessar sites na internet. 48