Home

Thesis - Técnico Lisboa

1. Numero de bytes Tipo Valor Descri o bytesPorPixel PIXEL valor do pixel do sub rect ngulo 2 U16 posi o x 2 U16 posi o y 2 U16 largura 2 U16 altura A 5 6 Pseudo Codifica es A 5 6 1 Pseudo Codifica o do cursor Um cliente que pe a esta pseudo codifica o est a declarar que capaz de desenhar o cursor do rato localmente Isto pode melhorar significativamente a performance sobre liga es lentas O servidor define a forma do cursor enviando um pseudo rect ngulo com a pseudo codifica o do cursor como parte de uma actualiza o A posi o x e a posi o y do pseudo rect ngulo indicam a ponta do cursor e a largura e a altura indicam a largura e a altura respectivas do cursor em pixeis Os dados desta mensagem consistem em largura x altura valores de pixeis seguidos por uma m scara A m scara consiste num varrimento de linhas da esquerda para a direita e de cima para baixo onde cada linha preenchida com zeros padded at perfazer um n mero inteiro de bytes floor largura 7 8 altura Dentro de cada byte o bit mais significativo representa o pixel mais esquerda sendo que o bit 1 significa que o pixel correspondente do cursor v lido Numero de bytes Tipo Valor Descri o largura x altura x bytesporpixel Vector de PIXEL pixeis do cursor floor largura 7 8 altura Vector de U8 mascara A 5 6 2 Pseudo Codifica o do Tamanho do Des
2. 0 1 57 113 169 225 281 337 393 449 505 561 617 673 729 785 841 N mero do Pacote Tempo de descodifica o do pacote de som ms 1 56 111 166 221 276 331 386 441 496 551 606 661 716 771 826 N mero do Pacote Tempo de prepara o do player para tocar o pacote de 1200 1000 4 800 600 som ms 400 200 4 0 1 60 119 178 237 296 355 414 473 532 591 650 709 768 827 Numero do Pacote Figura V 6 Graficos relativos a transfer ncia de som por UDP durante cerca de 1 minuto Pela an lise destes resultados pelos factos apresentados na Sec o IV 3 e por se ter revelado uma solu o mais robusta resolveu se escolher o m todo de transfer ncia de som sobre TCP para a vers o final da aplica o do cliente Outro factor a favor desta op o que nem todos os modelos de telem vel suportam datagramas UDP estando o TCP mais generalizado 54 V 5 2 Actualiza es integrais ao ambiente de trabalho Para se verificar a dura o de uma actualiza o ao ambiente de trabalho nos v rios modos dispon veis na aplica o foram realizados testes sobre condi es semelhantes para todos os modos Assim tentando analisar o funcionamento da aplica o numa situa o extrema cobriu se todo o ambiente de trabalho com uma imagem de dimens es 1024 por 768 onde se podia verificar um elevado gradiente de cores utilizadas Figura V 7 tendo sido efectuados
3. key down key up key down then up ie press Mouse Move To must be four digits Click primary mouse button Move Screen To follows the same standard as m 85 B 2 Server The corresponding enhanced VNC server was the only one found on the Internet that had server side scaling extensions and was originally distributed with the PalmVNC software Besides the server side scaling extensions this software was modified to support sound transfer and user profiles It also has some new features that you may recognize from newer versions of the VNC server like RealVNC To configure the new options you simply have to right click on the VNC server icon on the taskbar Properties Users Add New Client Kill All Clients About Win NC Close VNC The Properties menu now lets you choose from 2 different security types The Normal Authentication is the standard for any VNC server application and you may want to use this if you re WinYNC Current User Properties lela using a regular VNC viewer The User Authentication is Incoming Connections an extension to the protocol which lets you use the new IV Accept Socket E ti DR Sell east user profile features This new feature allows the Display Number creation of user profiles in the server and when a viewer Password connects using a username that matches any of the Normal Authentication previously configured profiles a special application
4. o deste valor implicaria que os pacotes de som enviados pelo servidor fossem marcados com o instante de envio com um timestamp e que de tempos a tempos fossem trocadas mensagens entre o servidor e o cliente para sincronizar os rel gios respectivos V 2 Registo Log Na aplica o original para a qual se resolveu dar o contributo este registo guardava os v rios passos da troca de mensagens inicial entre o cliente e o servidor as teclas pressionadas pelo utilizador os pedidos de actualiza es realizados ao servidor e correspondentes respostas detalhadas etc Ap s a aplica o estar testada e aparentemente sem bugs resolveu se utilizar o registo para apresentar valores de par metros medida que iam surgindo mantendo deste modo um registo n o s de valores m dios no formul rio de estatisticas mas tamb m de valores instant neos Manteve se no entanto o registo da troca de mensagens iniciais com o servidor para permitir perceber porqu que eventualmente uma sess o falhou e regista se ainda alguma informa o adicional para permitir o debug da aplica o Os valores calculados e apresentados neste registo s o divididos por transfer ncia de dados mensagens RFB referentes a actualiza es do ambiente de trabalho e por transfer ncia de som Para cada transfer ncia de dados apresenta se para al m do instante de tempo em que ocorre em milissegundos desde o in cio da sess o VNC a dimens o em bytes da actu
5. o do rato sem ser necess rio aceder ao menu cada vez que se pretende colocar o ponteiro do rato na posi o desejada No entanto ap s verifica o de que esta associa o de teclas n o funciona correctamente em telem veis com teclados qwerty foi criado um menu Mouse onde s o disponibilizadas todas as op es descritas anteriormente bastando ao utilizador seleccionar uma e pressionar ok Sec o A 5 3 5 No modo em que todo o ambiente de trabalho remoto vis vel no ecr do telem vel zoom out os pedidos de actualiza o s eram efectuados para a por o do desktop seleccionada Isto obrigava o utilizador no caso de ter aberto uma janela ou aplica o que ocupasse todo o ambiente de trabalho a percorr lo sec o a sec o de forma a realizar a actualiza o na integra Para melhor se visualizar este efeito representa se na Figura IV 4 um cen rio exemplificativo onde se pode observar que o utilizador premiu o bot o Iniciar do Windows e come ou a percorrer o desktop de modo a tornar vis vel o menu expandido Neste modo zoom out as actualiza es passaram a ser efectuadas ao ambiente de trabalho completo e n o apenas por o seleccionada passando a ser incrementais Ou seja apenas as altera es que ocorreram no desktop desde a ltima actualiza o s o enviados para o telem vel Desta forma se o utilizador mexer o rato de posi o ou abrir uma janela apenas o cone do rato na nova posi o
6. IV 3 3 Compress o de som e supress o de sil ncios A compress o do udio no lado do servidor baseia se no algoritmo simples de suprimir s mbolos repetidos ou seja se no pacote de som se encontrar uma sequ ncia de bytes 000000000000 esta ser comprimida para a sequ ncia de bytes lt 0 12 onde o s mbolo lt byte indica o in cio de uma sequ ncia de s mbolos que foi comprimida o 0 byte indica o s mbolo repetido e o 12 short 2 bytes indica o n mero de repeti es deste Esta compress o s efectuada para repeti es de 5 ou mais s mbolos bytes pois a codifica o de menos s mbolos numa nota o de 4 bytes n o traz ganhos antes pelo contr rio exige mais tempo para ser descodificado no cliente No caso de ser encontrado o s mbolo lt no meio do pacote de som este ser sempre codificado no novo formato mesmo que n o apare a repetido Deste modo o s mbolo lt passar a lt lt 01 existindo uma perda de compress o necess ria para manter a coer ncia e para ser poss vel descodificar correctamente a amostra de udio no cliente Os algoritmos pseudo c digo utilizados para compress o e descompress o dos pacotes de udio podem ser consultados no Anexo C A escolha do s mbolo lt foi realizada por an lise da sequ ncia de bytes que comp em alguns pacotes de som tendo sido escolhido aleatoriamente de entre os s mbolos que aparentavam repeti
7. o RRE Os rect ngulos codificados neste formato chegam ao cliente numa forma que podem ser desenhados imediatamente e eficientemente pelo mais simples dos motores gr ficos Esta codifica o n o apropriada para ambientes de trabalho complexos mas pode ser til em algumas situa es O conceito por detr s da codifica o RRE a de dividir um rect ngulo de pixeis em sub regi es sub rect ngulos cada uma composta por pixeis de um nico valor sendo que a uni o destas comp e o rect ngulo original A parti o quase ptima de um rect ngulo em sub rect ngulos relativamente f cil de calcular A codifica o consiste num pixel de fundo V tipicamente o valor do pixel que mais se repete e do n mero de sub rect ngulos seguido da listagem destes Os sub rect ngulos consistem no tuplo lt v x y w h gt onde v V o valor do pixel x y s o as coordenadas do sub rect ngulo relativamente ao canto superior esquerdo do rect ngulo e w h s o a largura e altura do sub rect ngulo O cliente pode assim desenhar o rect ngulo original enchendo o com o pixel de fundo e depois desenhar rect ngulos menores correspondendo a cada sub rect ngulo Na rede os dados come am com o cabe alho Numero de bytes Tipo Valor Descri o 4 U32 n mero de subrectangulos bytesPorPixel PIXEL valor do pixel de fundo 77 E seguido por numero de subrectangulos repeti es da seguinte estrutura
8. 1 U8 deslocamento de azul 3 enchimento com zeros padding O formato natural dos pixeis a ser usado ser o formato de pixel do servidor a menos que o cliente pe a um tipo diferente usando a mensagem de Definir o Formato dos Pixeis Bits por pixel o numero de bits usado para cada pixel transmitido devendo ser maior ou igual que a profundidade que o numero til de bits por pixel Nas vers es actuais os bits por pixel devem ser 8 16 ou 32 menos de 8 bits por pixel ainda n o s o suportados A flag big endian ser diferente de zero se pixeis de mais do que um byte s o para ser interpretados como big endian Se a flag true colour for diferente de zero ent o os ltimos seis itens especificam como extrair as intensidades de vermelho verde e azul do formato de pixel O m ximo de vermelho o m ximo valor de vermelho 2 1 onde n o numero de bits usado para o vermelho O deslocamento de vermelho o n mero de deslocamentos necess rios para obter o bit menos significativo do valor de vermelho do pixel Se a flag true colour for zero ent o o servidor usa valores de pixeis que n o s o directamente compostos por intensidades de vermelho verde e azul mas ao inv s disso servem de ndices para um mapa de cores As entradas do mapa de cores s o definidas pelo servidor usando a mensagem de Definir as Entradas do Mapa de Cores A 5 2 Tipos de seguran a A 5 2 1 Nenhum N o necess ria autentica o e os dados
9. Remote Frame Buffer Rise and Run length Encoding Secure Shell Transfer Control Protocol Internet Protocol Time Division Duplex Time Division Multiple Access Universal Mobile Telecommunications System Virtual Network Computing Virtual Private Network Record Management System Real time Transport Protocol Real Time Streaming Protocol International Telecommunication Union W CDMA Wideband Code Division Multiple Access viii Cap tulo Introdu o 1 1 Introdu o As diferen as de funcionalidade existentes entre telem veis e computadores pessoais s o cada vez menores mas ainda assim existem devido aos requisitos espec ficos dos terminais m veis Com a crescente evolu o das capacidades dos telem veis e das respectivas redes estas poder o servir de ponte para aproximar cada vez mais um vulgar telem vel de um computador pessoal O objectivo deste trabalho foi o de desenvolver uma plataforma que permitisse aceder e controlar um computador atrav s de um terminal m vel recorrendo para isso a uma liga o de dados GPRS ou UMTS 36 Deve se no entanto ter em considera o as limita es dos telem veis comuns em termos de dimens es do ecr mem ria e interface de entrada importante diferenciar entre ferramentas de acesso remoto e ferramentas de controlo remoto do PC 6 nas primeiras as aplica es existem no cliente e o servidor de acesso remoto basicamente um comutador multi protocolo baseado em sof
10. m o tempo que devia de se ouvir esse sil ncio o que pode n o ser desej vel Por exemplo se uma m sica contiver um instante de sil ncio a meio o servidor n o enviar os pacotes de udio correspondentes a este sil ncio para o cliente mas enviar o restante som Como o cliente acumula no buffer apenas os pacotes recebidos este ir juntar o ltimo som ao 39 novo eliminando o instante de sil ncio no existente no meio parecendo ao utilizador que a m sica n o teve pausa nenhuma Para uma melhor compreens o do que foi descrito anteriormente apresenta se na Figura IV 14 os diagramas de mensagens entre cliente e servidor referentes transfer ncia de som tanto em TCP como em UDP Cliente Servidor Cliente Servidor connect hello COS e Cria thread para Cria thread para Cabe alho WAVE lidar com o som lidar com o som 44 bytes Cabe alho WAVE O cabe alho _ _ Se n o receber o ACK prossegue 44 bytes serve de ACK sem som Cria buffer Cria buffer Tamanho do pacote Datagrama de Som ee Recebe e toca Recebe e toca no player 1 Datagrama de Som no player 1 Tamanho do pacote O ice ae Pe seis no player 2 Recebe e toca Som a Datagrama de Som no player 2 io o acct add 4 bytes Recebe e toca ETERA ean go no player 1 bye Recebe e toca Som ee no player 1 Figura IV 14 Diagrama de mensagens da solu o em TCP lado esquerdo e da solu o em UDP lado direito
11. o sendo esta a evolu o para as operadoras de GSM Apesar das principais especifica es desta tecnologia terem sido definidas entre o ano de 2000 e 2002 a sua introdu o em Portugal foi efectuada pelo operador Vodafone no princ pio do ano 2004 logo seguida da TMN em Abril do mesmo ano e por ultimo a Optimus A necessidade de desenvolver esta nova tecnologia prendeu se com o facto de haver um grande aumento de utilizadores de comunica es m veis e tamb m porque o sistema GSM come ou a ficar saturado no que diz respeito s frequ ncias de r dio que lhe foram destinadas O desenvolvimento de novas aplica es e a melhoria da qualidade de servi o de algumas aplica es j existentes no 2 5G foi outra das raz es para implementa o da 3G Ao n vel de frequ ncias o UMTS utiliza a faixa entre 1900 e 2200 MHz onde 155 MHz s o para a componente terrestre e 60 MHz s o para a componente de sat lite As bandas entre 1900 e 1920 MHz e entre 2010 e 2025 MHz s o utilizadas pelo modo TDD Time Division Duplex ambas para uplink e downlink as bandas entre 1920 e 1980 MHz e entre 2110 e 2170 MHz s o utilizadas pelo modo FDD Frequency Division Duplex em uplink e downlink respectivamente e as bandas entre 1980 e 2010 MHz e entre 2170 e 2200 MHz s o utilizadas pelo modo MSS Mobile Satellite System em uplink e downlink correspondentemente A interface r dio utilizada no UMTS designada por WCDMA Wide Code Division Multiple
12. 10 pedidos de actualiza o integrais por cada teste efectuado Resolveu se ainda utilizar a rede GPRS ao inv s da UMTS para se verificar o d bito dispon vel nesta e tamb m para analisar o pior caso em termos de tempos de transmiss o www aindamelhoraom 2 Figura V 7 Imagem utilizada para os testes s actualiza es ao ambiente de trabalho Ao todo foram realizados 50 pedidos de actualiza o podendo se ver na Figura V 8 que o valor m dio registado para o d bito foi de 56 4 kbps com algumas oscila es como seria de esperar na rede GPRS utilizada O desvio padr o obtido foi de 4 5 e o intervalo de confian a a 95 55 2 57 7 q d bito kbps N w A q o oO oO oO oO oO K O Q0 O Q ANADO OT TRH O YM O OD rT eo o NNN OHO HT TFT TFT FT numero da actualiza o Figura V 8 D bito obtido na rede GPRS 55 No modo em que as altera es ao factor de escala s o efectuadas no telem vel vis vel na Figura V 9 que o facto de estar seleccionada ou n o a op o de smooth navigation em pouco ou nada influ ncia o tempo de recep o da actualiza o Isto seria de esperar visto que em ambos os casos o tempo obtido apenas influenciado pelo tempo de recep o e pelo tempo que o telem vel leva a desenhar no ecr e nos buffer s de mem ria respectivos os tr s zoom s dispon veis Poder se ia pensar que o tempo necess rio para desenhar no buffer de mem ria c
13. Access Esta sigla prov m do facto de se tratar de um sistema de banda larga com base na tecnologia CDMA Code Division Multiple Access que efectua um espalhamento do espectro de um determinado sinal na frequ ncia ou seja transforma um sinal de banda estreita num sinal de banda larga A cada utilizador atribu do um c digo atrav s do qual efectuado o espalhamento do sinal quando o utilizador pretende transmitir Na recep o atrav s do conhecimento do mesmo c digo efectuado o processo inverso Como os c digos s o ortogonais entre si poss vel ter mais que um utilizador a partilhar a mesma frequ ncia sem ocorrer o risco de perda de informa o Os ritmos de transmiss o est o directamente relacionadas com o tipo de c lula rea de cobertura e com a mobilidade do terminal m vel sendo que em situa es ideais ou seja zonas pr ximas da esta o base e com pouca mobilidade o d bito pode atingir os 2 Mbps Pelo contr rio em zonas mais afastadas da esta o de base e para mobilidades superiores o d bito pode atingir valores de 144 kbps A ITU International Telecommunication Union definiu tr s limites de d bito associados mobilidade Alta Ritmo de transmiss o na ordem dos 144 kbps quando o utilizador estiver a viajar a mais de 120 km h no exterior em ambientes rurais Total Ritmo de transmiss o na ordem dos 384 kbps para pe es que se estejam a deslocar a menos de 120 km h no exterior em ambientes cit
14. Enpe Hu OO 2 35 0 etre NO yy MeO 0 0 XN ne OCHO Oo 4 O PLU er Oe RNA mm wm nw um mm N N AME MON N TANO THON MN HANNA g MM ON TERR MN MOM NR MN NNN HAMMA Pea en a Sa RR TR RR RT TR De eS es Oe ee RR O RR RR RR Tudors DADMYN yo fh ERX SOK ee Or Delo l e cs BF H ons gio 91
15. No GSM por cada chamada de voz atribu do um time slot No GPRS de modo a maximizar o ritmo de transmiss o podem ser atribu dos ao mesmo terminal v rios time slots As especifica es definem 29 classes para os terminais conforme o n mero de time slots utilizados na recep o ou transmiss o O d bito obtido est directamente relacionado com tr s factores esquema de codifica o utilizado no canal n mero de time slots suportados pelo dispositivo m vel e n mero de utilizadores de GSM e GPRS na c lula Os esquemas de codifica o permitem a detec o e correc o de erros em caso de perda de dados e s o utilizados na interface r dio dependendo da qualidade da liga o S o definidos 4 esquemas de codifica o para o GPRS tal como se apresenta na Tabela 11 1 Tabela II 1 Esquemas de codifica o do GPRS Ritmo maximo de dados Ritmo maximo de dados C I Codifica o kbit s Camada LLC kbit s Canais f sicos min dB CS 1 8 9 05 6 CS 2 12 12 4 9 CS 3 14 15 6 12 CS 4 20 21 4 17 Pode se verificar que quanto melhor for a cobertura da c lula ou seja quanto maior for a rela o sinal ru do C I menos robusto deve ser o esquema de codifica o a utilizar Sendo o d bito obtido em fun o do esquema de codifica o e do n mero de time slots os d bitos m ximos em kbps s o apresentados na Tabela II 2 Com esta tecnologia poss vel atingir um ritmo m ximo te rico de 17
16. Nokia 6630 61 Capitulo VI Conclus es VI 1 Conclus es O presente trabalho abordou de forma abrangente o problema de proporcionar ao utilizador de um terminal m vel o controlo remoto sobre um computador Iniciou se a abordagem ao tema pela an lise das solu es existentes no mercado realizando o estudo das suas caracter sticas e funcionalidades cogitando poss veis contribui es para as mesmas e reflectindo sobre m todos alternativos para obter resultados semelhantes Posteriormente a interven o efectuada abordou as seguintes contribui es 1 Melhoramentos aplica o existente tornando a sua utiliza o mais simples eficiente e apelativa ao utilizador Incorpora o de novas funcionalidades de modo a tornar a aplica o escolhida uma alternativa vi vel s solu es comerciais 2 Implementa o de m todos alternativos para altera o ao factor de escala da imagem vis vel no ecr do telem vel e de navega o pelo ambiente de trabalho remoto Foram disponibilizados v rios modos de funcionamento para dar suporte a dispositivos com diferentes capacidades de mem ria e processamento 3 Concep o de um m todo para transfer ncia de som do servidor para o dispositivo m vel com compress o de dados e supress o de sil ncio tendo em considera o as limita es impostas pela maioria dos terminais 4 Cria o de um mecanismo de perfis de utilizador que permite configurar no servidor determinadas caract
17. WCSF 2004 Fortaleza CE October 2004 9 R Chakravorty J Cartwright and Pratt Practical Experience with TCP over GPRS Proc of IEEE GLOBECOM 2002 November 2002 10 TCP over second 2 5G and third 3G Generation Mobile Networks RFC 3481 February 2003 11 Antonis Alexiou Christos Bouras Vaggelis Igglesis Performance Evaluation of TCP over UMTS Transport Channels Whitepaper 12 Sun J2ME Mobile Media API MMAPI JSR 135 Specification June 2006 http java sun com products mmapi ltimo acesso em 28 08 2007 13 Sun J2ME Mobile Information Device Profile MIDP1 0 JSR 37 Specification December 2000 http java sun com products midp ltimo acesso em 28 08 2007 14 Eduardo Tude Tutorial de GPRS www teleco com br April 2003 15 Eduardo Tude Tutorial de UMTS www teleco com br January 2004 16 Eduardo Tude Tutorial de HSDPA www teleco com br February 2005 17 Michael Lloyd Lee J2ME VNC c digo fonte February 2005 http j2mevnc cvs sourceforge net j2mevnc VNC ltimo acesso em 10 08 2007 18 AT amp T Harakan Software WinVNC v3 3 3 r7 with Server Scaling Extensions source code January 2001 http www btinternet com harakan PalmVNC ltimo acesso em 10 08 2007 19 General Packet Radio Service GPRS Wikip dia article August 2007 http en wikipedia org wiki General Packet Radio Service ltimo acesso em 28 08 200
18. altura O servidor normalmente responde a um Pedido de Actualiza o ao Framebuffer enviando uma mensagem de Actualiza o ao Framebuffer Note se no entanto que uma nica mensagem de Actualiza o ao Framebuffer pode ser enviada como resposta a m ltiplos Pedidos de Actualiza o ao Framebuffer O servidor assume que o cliente mant m c pias de todas as partes do framebuffer nas quais est interessado o que significa que normalmente o servidor s precisa de enviar actualiza es incrementais ao cliente No entanto se por alguma raz o o cliente perdeu o conte do de alguma rea em particular que precisa ent o envia ao servidor o Pedido de Actualiza o ao Framebuffer com o campo incremental a zero pedindo assim ao servidor que envie o mais rapidamente poss vel o conte do desta rea Se o cliente n o perdeu o conte do da rea em que est interessado ent o envia o campo incremental diferente de zero o que faz com que o servidor envie uma Actualiza o ao Framebuffer se e quando ocorrerem mudan as na rea especificada note se que pode ocorrer um tempo indefinido entre o pedido de actualiza o e a resposta No caso de um cliente r pido este pode querer regular o ritmo a que envia os Pedidos de Actualiza o ao Framebuffer incrementais para evitar sobrecarregar a rede Numero de bytes Tipo Valor Descri o 1 U8 3 tipo de mensagem 1 U8 incremental 2 U16 posi o x 2 U16 posi o y 2 U16
19. cliente e servidor Deste modo considerando que os telem veis v o tendo cada vez mais capacidade de mem ria e que a fluidez com que se navega pelo ambiente de trabalho sem a necessidade de realizar actualiza es constantes um factor importante e apelativo ao utilizador resolveu se manter dispon vel a alternativa descrita anteriormente e acrescentou se uma nova dando ao utilizador a possibilidade de optar entre ambas A alternativa encontrada passou por reduzir o tamanho do buffer de mem ria utilizado no telem vel para armazenar o zoom normal 100 que em vez de ter capacidade para armazenar todo o ambiente de trabalho passou apenas a armazenar uma por o deste das dimens es do ecr do telem vel Voltou se assim ao modo original de como era efectuada a navega o ou seja voltou a ser necess rio no modo de zoom normal fazer pedidos de actualiza o constantes medida que se navega pelo ambiente de trabalho No entanto o modo de zoom fifty 50 manteve se inalterado conseguindo se manter uma navega o fluida e sem necessidade de pedidos de actualiza o Tal revelou se poss vel porque a quantidade de mem ria ocupada por este buffer inferior ocupada pelo zoom normal ver Sec o V 5 5 n o se tendo verificado que os telem veis testados acusassem falta de mem ria O modo mais afectado com esta modifica o quando a altera o ao factor de escala efectuado pelo servidor Neste caso como apenas util
20. comportar a mesma com v rios clientes em simult neo e se esta transfer ncia de som deve ser unidireccional ou bidireccional para permitir por exemplo caso se esteja a efectuar uma assist ncia remota que o auxiliado e o auxiliando possam comunicar entre si Descreve se em seguida esta solu o A solu o adoptada passa por transferir todo o udio do servidor para o telem vel atrav s de uma sess o paralela utilizada pelo VNC dedicada para o efeito Podem ser os sons do Windows que v o para a placa de som m sica o som capturado pelo microfone ou uma mistura de tudo 27 dependendo das capacidades da placa de som do computador alvo e do que estiver seleccionado nas op es de grava o de udio do sistema operativo Esta selec o tem de ser realizada pelo utilizador nas configura es de udio do sistema pois dependente da placa de som e por consequente n o foi poss vel fazer com que o servidor de VNC activasse automaticamente a captura de udio pretendida Dado que este trabalho especifico para clientes em telem veis e que apenas dispomos de uma API e hardware limitada para manter a compatibilidade com um maior n mero de plataformas poss veis resolveu se n o utilizar nenhum protocolo de streaming RTP RTSP RFC 3550 2326 pois estes apenas s o suportados nos player s nativos da maioria dos telem veis e apenas modelos mais recentes e topo de gama suportam nos sobre as API s do J2ME Isto significa que a
21. de transfer ncia de som 32 O porto associado transfer ncia de som por comodidade o porto imediatamente a seguir ao utilizado pelo VNC e se este ltimo for alterado durante a execu o do servidor o socket associado ao som fechado e reaberto no novo porto e a thread correspondente terminada e iniciada uma nova thread comportamento an logo ao efectuado pelo socket e threads de comunica o usados pelo VNC Deste modo garante se que durante este processo todos os clientes com uma liga o de udio s o correctamente terminados O socket ao ser fechado liberta a thread que est bloqueada no accept podendo esta terminar a liga o a eventuais clientes ligados e fechar se A nova thread ent o criada j estar associada ao novo socket Se algum cliente efectuar uma liga o para transfer ncia de udio o servidor cria um cabe alho no de 44 bytes no formato WAVE como pode ser visualizado na Figura IV 10 5 e envia o ao cliente Este utiliza a informa o nele contida para dimensionar o buffer de recep o e buffer s auxiliares para deste modo utilizar apenas o m nimo de mem ria necess ria O cabe alho posteriormente cedido aos players que carecem desta informa o O formato do cabe alho foi escolhido para manter uma compatibilidade com um maior n mero de dispositivos poss veis The Canonical WAVE file format File offset field name Field Size endian bytes bytes big a A The RIFF ch
22. dimens o do pacote a que est o associados Isto torna se necess rio pois com a compress o utilizada os pacotes n o t m todos o mesmo tamanho e sendo que em TCP os dados s o enviados numa sequ ncia de bytes stream necess rio para o cliente saber como separ los para os poder depois descodificar 34 O som transferido em pacotes de 4 segundos 32000 bytes ou menos se comprimido sendo este facto explicado na implementagao do cliente na Secgao IV 3 2 2 Na solu o em UDP como n o existe estabelecimento de sess o necess rio que o cliente coloque na rede uma mensagem que informe o servidor de que pretende receber som Esta mensagem apenas um datagrama contendo o byte 1 no campo de dados O servidor ao receber o pedido de liga o armazena o endere o do terminal que efectuou a solicita o num vector de estruturas do tipo struct sockaddr in viewer MAX CLIENTS para de uma forma an loga ao que acontece na solu o em TCP poder transferir o som capturado para todos os clientes que est o espera de o receber No caso do UDP n o necess rio enviar para o cliente o tamanho do pacote de udio pois os datagramas UDP t m as suas fronteiras bem definidas Deste modo o cliente ao receber um datagrama sabe que aquele foi exactamente o pacote transmitido Ao receber uma mensagem contendo o byte 0 o servidor sabe que o cliente n o pretende continuar a receber udio e portanto pode apagar o seu ende
23. e n o deve ser usado novamente Deste modo se houver udio para reproduzir um player estar a reproduzi lo enquanto o outro estar a carregar para mem ria a pr xima amostra de som que est a ser recebida Esta solu o que pode ser analisada na Figura IV 11 necess ria para reduzir o sil ncio que um s player introduz entre amostras de udio sucessivas Actualmente apenas algumas vers es mais recentes das plataformas disponibilizadas pela Sony Ericsson pela Motorola e pela terceira edi o da s rie S60 da Nokia suportam o protocolo RTP RTSP poder o haver outras das quais n o tive conhecimento S a t tulo de exemplo o suporte para streaming RTSP foi adicionado na s rie S60 2nd Edition Feature Pack 3 da Nokia sendo que o telem vel dispon vel para desenvolvimento e testes foi o 6630 que pertence s rie S60 2nd Edition Feature Pack 2 o N70 j um dispositivo S60 2nd Edition Feature Pack 3 Deste modo para n o limitar a utiliza o da aplica o resultante aos telem veis mais recentes e topo de gama resolveu se adaptar a solu o de ter dois players para reproduzir o efeito de streaming e assim manter a aplica o o mais abrangente poss vel em termos de plataformas alvo 36 e ec de AE Player 2 Ce ee tempo a recebe e prepara a amostra de udio b reproduz a amostra de udio Figura IV 11 Representa o temporal do funcionamento alternado dos dois players Mesmo com este siste
24. kilobytes o que permite obter estimativas com alguma precis o Durante uma actualiza o ou mesmo durante uma transfer ncia de som apenas s o transferidos dados do servidor para o cliente podendo se atrav s de uma simples opera o de divis o calcular o d bito de downstream da rede sendo que este representado pelo n mero de bits transferidos por unidade de tempo kbps Quando se est a transferir som em paralelo com uma actualiza o a estimativa do d bito j n o real pois parte da largura de banda est a ser utilizada pela transfer ncia de som e a outra parte pelos dados referentes actualiza o Tendo isto em considera o o c lculo mais exacto do d bito da rede obt m se quando apenas se transfere udio durante um certo intervalo de tempo sem proceder a actualiza es nenhumas durante esse mesmo per odo Como a quantidade de dados transferidos do cliente para o servidor upstream bastante reduzida achou se irrelevante estar a calcular o d bito nesta direc o Na Figura V 1 pode ser visualizado um exemplo de um registo capturado no in cio de uma sess o onde apenas foi realizada uma actualiza o ao ambiente de trabalho e transferido apenas um pacote de udio Time 58578 CE ms Connection Open Creating VNC Canvas 8 O Canvas Created Creating RFBProto RFBProto Created run started Init Start portatil Init End Time 6265 ms UThroughput 59 kbps UpdateSize 3059
25. largura 2 U16 altura 73 A 5 3 4 Eventos de Teclado S o considerados Eventos de Teclado o pressionar ou libertar de uma tecla sendo que a flag pressionada diferente de zero se a tecla estiver agora pressionada e zero se foi agora libertada A tecla em si especificada usando os valores de Keysym definidos no sistema X Window o que para a maioria das teclas igual ao seu valor ASCII correspondente Numero de bytes Tipo Valor Descri o 1 U8 4 tipo de mensagem 1 U8 flag pressionada 2 enchimento com zeros padding 4 U32 tecla A 5 3 5 Eventos de Rato Estes eventos indicam se houve movimento do rato ou se foi pressionada ou libertada alguma tecla do rato O rato encontra se na posi o x posi o y e o estado dos bot es de 1 a 8 s o representados pelos bits de 0 a 7 da mascara de bot es respectivamente sendo que 0 indica que o bot o est descarregado e 1 indica que o bot o est pressionado Num rato convencional os bot es 1 2 e 3 correspondem ao bot o da esquerda do meio e da direita do rato Se o rato tiver roda de scroll cada passo da roda para cima representado por um pressionar e libertar do bot o 4 e cada passo da roda para baixo representado por um pressionar e libertar do bot o 5 Numero de bytes Tipo Valor Descri o 1 U8 5 tipo de mensagem 1 U8 mascara de bot es 2 U16 posi o x 2 U16 posi o y
26. maioria dos telem veis apenas permite reproduzir udio ou mesmo v deo em blocos depois de os carregar na ntegra para mem ria e portanto outra solu o teve de ser equacionada para reproduzir o efeito de streaming desejado Deste modo resolveu se fazer uma an lise aos protocolos de comunica o poss veis de utilizar nomeadamente o TCP Transmission Control Protocol e o UDP User Datagram Protocol com o intuito de escolher o que melhor se adapta situa o em quest o IV 3 1 TCP vs UDP Apesar de ambos os protocolos serem bastante conhecidos algumas caracteristicas especificas sao introduzidas pelas redes GPRS UMTS e por isso segue se uma breve descri o e an lise de cada um deles IV 3 1 1 TCP Transmission Control Protocol Definido no RFC 793 o TCP o protocolo mais comum na Internet e mais utilizado para transfer ncia de dados sem falhas Isto deve se principalmente ao facto do TCP oferecer protec o contra erros garantia de entrega dos dados pela ordem por que s o enviados e oferece ainda um mecanismo de controlo de congest o O TCP um protocolo orientado conex o respons vel pela comunica o fi vel entre dois equipamentos interligados atrav s de uma rede IP Os dados s o transferidos numa sequ ncia de bytes stream sendo que cada conjunto de bytes de dados precedidos de um cabe alho TCP chamado de segmento Sendo um protocolo orientado conex o significa que antes de transmitir d
27. may User Authentication Accept CORBA Connections be run and the viewer will only have access to it instead Disable Local Keyboard amp Pointer of the whole desktop and a few more properties may be Update Handling configured for each profile If no match is made the Poll Console E Windows Only standard user profile will be used 5 Poll On Event E a 7 Poll Foreground Window Recehed Dri Another new functionality is sound support This lets the Poll Full Screen Pall Window Under Cursor viewer listen to whatever is playing on the server or being When last client disconnects captured by the microphone depending on how you Do nothing configure the windows recording settings You may Lock workstation choose to compress the transferred sound or not and C Logoff user you may choose a silence threshold if you want to have Sound Setti PE Ne some sort of silence suppression The silence MV Compress Sound ression only works if you choose to compress th Silence Threshold O suppressio y s If you choose to press the transferred sound and a good value for it may be 10000 but you may want to play with this number A value of zero means that no sound suppression will be made and a value of 32000 or higher means that every sound will be suppressed and therefore no sound will be transferred to the viewer 86 To choose between capturing the audio from the microphone and capturi
28. no mesmo mbito Em termos de caracter sticas e funcionalidades dispon veis nas v rias aplica es mencionadas neste cap tulo pode ser visualizado um resumo das mais importantes na Tabela III 2 13 Tabela III 2 Resumo das principais caracter sticas das varias aplica es de controlo remoto Z J2MEVNC RDM TSMobile vNC VNC2Go J2MEVNC vers o Cyers o original final Sim Sim Sim requer requer requer N o N o N o MIDP2 0 MIDP2 0 MIDP2 0 A E z Sim Sim Sim Sim N o Sim melhorado Sim Sim Sim N o N o Sim Sim Sim Sim requer requer requer N o N o N o MIDP2 0 MIDP2 0 MIDP2 0 F a E Sim Sim Sim Sim N o Sim melhorado Sim N o N o N o N o N o Sim Sim N o N o N o N o Sim Sim N o N o N o N o Sim Sim Sim N o N o Sim Sim Sim Sim Sim poe ique Simplese Sim duplo clique Apenas o ctrl alt shift meta e o enter s o disponibilizados Sim n o Sim n o Sim n o Sim n o e existe a Sim n o exaustiva exaustiva exaustiva exaustiva possibilidade de o exaustiva utilizador configurar combina es de teclas N o N o N o N o N o Sim N o N o N o N o N o Sim N o N o N o N o N o Sim N o N o N o N o N o Sim Em termos de software necess rio no servidor a escolha recaiu no VNC por ser multi plataforma de distribui o gratuita e open source permitindo assim o desenvo
29. o suporta a extens o de perfis de utilizador A segunda op o e a que foi implementada tem a caracter stica de apenas ter de se criar um novo tipo de seguran a do qual o cliente e o servidor tenham conhecimento para assim se fazer a verifica o do utilizador Como na vers o 3 3 do protocolo RFB que a vers o utilizada neste projecto quem decide o tipo de seguran a a utilizar o servidor foi necess rio acrescentar mais um par metro nas configura es deste para dar a possibilidade de se escolher o tipo de autentica o a utilizar No caso de se optar pela autentica o normal permite se que clientes j existentes se liguem ou mesmo o cliente de telem vel sendo neste caso ignorado o campo de utilizador No caso de ser utilizada a autentica o que permita a utiliza o dos perfis de utilizador o servidor fica espera de receber do cliente um nome de utilizador e alterar as suas propriedades consoante o que estiver definido no perfil associado Deste modo caso seja escolhido este ltimo tipo de autentica o o servidor durante a troca de mensagens iniciais e na fase da escolha do tipo de seguran a a utilizar enviar ao cliente a mensagem representada na Tabela IV 3 Tabela IV 3 Formato da mensagem indicando o tipo de seguran a a utilizar Numero de bytes Tipo Valor Descri o 4 U32 FFFF tipo de seguran a 16 U8 desafio 42 Esta mensagem contendo um desafio para confirm
30. os seus valores m nimos e m ximos e apresentados na Tabela V 1 e na Tabela V 2 59 Tabela V 1 Tempos de Ida e Volta obtidos no dispositivo HTC TyTn TCP UDP area min m dio max min m dio m x GPRS ms 4086 4414 5887 617 684 869 UMTS ms 2832 3099 4040 354 428 I 473 HSDPA ms 1940 2205 3223 145 171 242 Tabela V 2 Tempos de Ida e Volta obtidos no dispositivo Nokia 6630 E TCP UDP Nokial6s30 min m dio m x min m dio m x UMTS ms 437 672 1391 312 502 828 Os valores te ricos esperados para a rede GPRS s o de 600 a 700 ms alcan ando por vezes um segundo 19 Para a rede HSDPA os valores esperados s o de 100 a 200 ms e a rede UMTS sofre um incremento de aproximadamente 100 ms sobre a HSDPA 20 Comparando os valores te ricos com os valores obtidos sobre a implementa o em UDP verifica se que os resultados auferidos encontram se dentro da gama prevista com excep o das estimativas sobre UMTS que se revelam superiores ao esperado em cerca de 200 ms Este facto pode dever se dist ncia do terminal esta o de base implementa o do protocolo UMTS utilizada no dispositivo m vel e s capacidades deste etc Em termos das estimativas obtidas com a implementa o do Ping em TCP estas revelaram se bastante dispares dos valores te ricos Outro facto interessante que ao contr rio do que acontece com a implementa o em UDP
31. pacotes de som recep o Se existirem mais de 4 segundos de udio armazenado o player 1 reprodu los se o player 2 tiver terminado Armazena os pacote de som em mem ria Se existirem mais de 4 segundos de udio armazenado o player 2 reprodu los se o player 1 tiver terminado Figura IV 13 Diagrama de blocos da solu o em UDP para a transfer ncia de udio Foi escolhido um tamanho de buffering de 16 segundos correspondente a 4 amostras de 4 segundos para permitir que esteja sempre udio dispon vel para um player carregar enquanto o outro est a tocar tendo sido entre a alternativa de 8 segundos o que apresentou melhores resultados Esta solu o apesar de minimizar o inconveniente de uma poss vel redu o tempor ria da largura de banda dispon vel encontrado na solu o por TCP introduz no entanto outras situa es inoportunas Por exemplo se tiver a ser reproduzida uma m sica no servidor se a largura de banda for suficiente para permitir encher o buffer do cliente e se de um momento para o outro o cliente resolver mudar a m sica ou parar a sua reprodu o no servidor existir o 16 segundos de intervalo entre a ac o do cliente e a reac o ao n vel do som aud vel Outro inconveniente que o sistema de supress o de sil ncio deixa de funcionar como inicialmente previsto isto funciona mas para al m de suprimir o sil ncio suprime tamb
32. por o rectangular do canto superior esquerdo do desktop se encontra dispon vel Na figura do lado direito verifica se que na nova vers o da aplica o todo o ambiente de trabalho est automaticamente dispon vel ao utilizador no in cio de uma sess o e o navegar pelo desktop apenas selecciona a por o do ambiente de trabalho qual se pretende fazer zoom Figura IV 1 In cio de uma sess o VNC na aplica o original esquerda e numa vers o modificada direita 16 Para permitir ao utilizador um acesso a teclas que podem ser acedidas facilmente num teclado normal de computador mas n o num telem vel a vers o original continha um modo de definir combina es de teclas macros que o utilizador podia utilizar Estas macros definidas no MIDlet About apareciam directamente nos itens do menu principal durante o decorrer de uma sess o VNC o que fazia com que a lista de itens crescesse com o aumento do n mero de macros dispon veis tornando este menu pouco pr tico de utilizar Para um utilizador inexperiente e n o familiarizado com o formato utilizado para a defini o das macros referido no Anexo B era imposs vel utilizar teclas que n o existissem no teclado limitado do telem vel Foi criado um novo formul rio Special keys Figura IV 2 a acess vel pelo menu principal com uma lista de teclas predefinidas no c digo da aplica o s quais se juntam as macros definidas pelo utilizador Basta selecc
33. que mant m a coer ncia das estimativas obtidas entre dispositivos em TCP o dispositivo HTC TyTn apresentou valores bastante superiores aos obtidos no telem vel Nokia 6630 na ordem dos poucos segundos Tal ocorr ncia pode dever se s diferentes implementa es do protocolo TCP IP nos sistemas operativos distintos que suportam os dispositivos em quest o Tal ordem de grandeza explica os atrasos existentes entre os pedidos efectuados pelo terminal m vel e as correspondentes respostas do servidor mas n o revela nenhuma raz o para o tempo de recep o das actualiza es no HTC TyTn serem t o demoradas pois ap s o atraso inicial introduzido pela rede toda a informa o transferida recebida prontamente como sugerido pela boa performance obtida na transfer ncia de som V 5 5 Mem ria requerida para o funcionamento da aplica o Sendo este um aspecto importante a ter em considera o dadas as limita es dos dispositivos m veis n o foi no entanto poss vel obter valores representativos dos requerimentos da aplica o Uma das raz es para tal deve se ao facto da mem ria requerida pela aplica o depender das dimens es d spares dos ecr s dos telem veis do n mero de cores dispon veis dos diferentes mecanismos de gest o de mem ria utilizados pelos aparelhos etc Nomeadamente n o foi poss vel obter valores concretos para a mem ria utilizada pelo telem vel Nokia 6630 nos diversos modos dispon veis pois este utili
34. se compat vel com o RFB nem com o VNC A 5 Mensagens de Protocolo Existem duas fases do protocolo uma fase inicial de handshaking seguido da interac o normal do protocolo O handshaking inicial consiste nas mensagens de Vers o do Protocolo enviado pelo cliente e pelo servidor Seguran a Inicializa o do Cliente e de Inicializa o do Servidor O protocolo depois prossegue com a fase de interac o normal onde o cliente pode enviar as mensagens que pretender e pode receber mensagens do servidor como resultado destas Todas estas mensagens come am com um byte message type seguido dos dados espec ficos do tipo de mensagem Os tipos de mensagens que ser o abordados nos pontos seguintes usam os tipos b sicos U8 U16 U32 S8 S16 S32 que representam respectivamente 8 16 e 32 bit unsigned integer e 8 16 e 32 bit signed integer 68 O tipo PIXEL significa um valor de pixel de bytesPerPixel bytes onde 8 x bytesPerPixel o n mero de bits por pixel acordados pelo cliente e servidor na mensagem de Inicializa o do Servidor ou na mensagem de Definir o formato dos Pixeis A 5 1 Mensagens de handshaking inicial A 5 1 1 Vers o do Protocolo O handshaking come a com o servidor a enviar ao cliente a mensagem de Vers o do Protocolo Esta faz com que o cliente saiba qual o n mero de vers o do protocolo RFB mais alta que o servidor suporta O cliente depois responde com uma mensagem semelhante indicando o n mero da
35. sec es do desktop que sofrem altera es etc Comparando com outras solu es existentes no mesmo mbito resolveu se optar pelo VNC por n o ser uma solu o propriet ria e por disponibilizar o c digo sobre licen a GPL 24 Tudo isto fez do VNC numa primeira aproxima o o candidato ideal para correr no computador alvo Para utilizar o servidor VNC ser necess rio construir um cliente para correr no telem vel compat vel com o protocolo RFB Remote Frame Buffer 2 utilizado por este Novo cliente vs Cliente open source existente Tendo se descoberto que j existem algumas aplica es concebidas neste mbito e sendo que a ideia seria a de desenvolver a aplica o em Java para ser compat vel com o maior n mero poss vel de terminais m veis optou se por contribuir para um projecto open source existente que est desenvolvido em Java e que utiliza o protocolo RFB descrito no Anexo A Como este cliente est numa fase j funcional mas ainda bastante limitada o seu desenvolvimento est parado desde 2005 revelou se conveniente contribuir para este projecto continuando o seu desenvolvimento Analisadas as hip teses descritas anteriormente chegou se conclus o que a melhor op o a adoptar para o desenvolvimento deste projecto seria a de utilizar como base o servidor VNC assim como o cliente VNC existente para telem veis desenvolvendo todas as funcionalidades adicionais que se considerem necess rias par
36. servidor faz o processamento desta informa o e actua correspondentemente Estas entradas podem tamb m ser sintetizadas de outros dispositivos de entrada sa da n o standard como por exemplo utilizando uma caneta pen e um software de reconhecimento de caligrafia para gerar eventos de teclado A 3 Representa o de um pixel A interac o inicial entre o cliente e o servidor envolve a negocia o do formato e codifica o utilizada para representar os pixeis transmitidos Esta negocia o foi concebida para tornar o trabalho do cliente o mais simples poss vel ou seja o servidor deve poder sempre fornecer pixeis na forma que o cliente quer O formato dos pixeis refere se representa o das cores individuais pelos valores destes Os formatos mais comuns s o os de 24 bits ou de 16 bits true colour onde os valores dos pixeis s o traduzidos directamente para as intensidades de vermelho verde e azul e os de 8 bits mapa de cores onde um mapeamento arbitr rio pode ser utilizado para traduzir o valor dos pixeis para as intensidades das cores 67 A codifica o refere se a como que um rect ngulo de pixeis enviado pela rede Cada rect ngulo de pixeis precedido por um cabe alho que indica a posi o x y do rect ngulo no ecr o seu comprimento a sua altura e o tipo de codifica o utilizada O conte do destes segue depois a codifica o especificada Os tipos de codifica o definidos actualmente s o Ra
37. situa es particulares pode se tornar numa ferramenta bastante til Tendo em considera o as limita es impostas pelos dispositivos m veis e pelas redes de dados que os suportam foram realizados estudos de viabilidade do projecto contornaram se obst culos introduzidos pelas API s utilizadas e teve se especial aten o para limitar o m nimo poss vel em termos de plataformas alvo o uso da aplica o resultante Para isso foram disponibilizados v rios modos de funcionamento que se adequam a telem veis com diferentes capacidades de mem ria e de processamento Algumas das principais inova es introduzidas passam por permitir a transfer ncia de som do computador remoto para o telem vel concedendo ao utilizador uma ideia mais aproximada de estar efectivamente sentado em frente ao computador a ser controlado e passam tamb m por permitir definir perfis de utilizador restringindo o acesso dos terminais m veis a aplica es especificas e introduzindo restri es de seguran a Por ltimo para estudo das capacidades e caracter sticas das redes m veis celulares foram efectuados testes com o intuito de se estimarem alguns par metros espec ficos destas nomeadamente a lat ncia e o tempo de ida e volta Palavras chave Controlo remoto de computadores Redes m veis celulares Telem veis Interfaces de entrada e sa da Protocolo de comunica o Java Abstract The development of new data services supported by new t
38. tocar foi conseguida No entanto n o se conseguiu eliminar a pequena pausa existente durante a altern ncia entre os players e assim obter um verdadeiro fluxo de som sem interrup es Ainda assim obteve se uma melhor performance utilizando o HTC TyTn onde as pausas entre amostras eram quase impercept veis e nem sempre ocorriam devendo se tal facto ao menor tempo dispendido pela inicializa o dos players neste dispositivo As nicas solu es encontradas para solucionar este problema passam ou por codificar os players na linguagem nativa do telem vel em quest o ou por desenvolver esta funcionalidade para um modelo de telem vel que j suporte streaming RTSP na esperan a de que todos os modelos futuros a suportem 51 800 700 4 600 500 400 4 300 5 200 100 eee ee eee aae 12 3 45 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Numero do Pacote D bito kbps 30000 25000 20000 15000 4 10000 5000 Tamanho do pacote de som bytes Tempo de recep o do pacote 04 TT TT TT TT TT TT TIA 0 TT TT TT TT TT IT TIA 123 45 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 123 45 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Numero do Pacote Numero do Pacote 1000 4 pacote de som ms Eq Q Q o Q O O O N S Tempo de descodifica o do 123 45 6 7 8 9 1011 12 13 14 15 16 17 18 19 20 123 45 6 7 8 9 10 11 12 13 14 15 16 17 1
39. um servi o de dados como o acesso Internet isto a tarifa aplicada durante o tempo em que o circuito esteja estabelecido e n o sobre a quantidade de informa o transmitida II 2 GPRS O crescimento das aplica es de dados como o acesso Internet e mail e entretenimento levou necessidade de desenvolver solu es que permitissem a transmiss o de dados a ritmos superiores em comuta o de pacotes Em 1999 foi lan ado em Portugal a n vel comercial tamb m pelos operadores TMN Vodafone antiga Telecel e Optimus a tecnologia GPRS 14 que est inserida na segunda gera o e meia 2 5G e foi a principal tecnologia que serviu como ponte entre 2G e 3G O GSM foi implementado tendo como principal objectivo o servi o de voz enquanto que o GPRS utilizando a rede GSM pretende disponibilizar servi os de transmiss o de dados como por exemplo o acesso Internet Com este prop sito o GPRS utiliza m ltiplos time slots para efectuar a transmiss o dos pacotes de dados com a diferen a que n o existe uma reserva permanente dos mesmos Os time slots s o reservados conforme a necessidade de transmitir informa o conseguindo se desta forma um servi o de dados com liga o permanente always on sem a necessidade de reservar continuamente os time slots para o transporte de dados Deste modo uma das vantagens a factura o ser efectuada sobre o volume de informa o transaccionado e n o sobre o tempo da liga o
40. uma sess o VNC V 5 Testes V 5 1 Transfer ncia de Som Para comparar os dois m todos de transfer ncia de som foram realizados alguns testes e recolhidos dados para analisar tendo estes sido resumidos na Figura V 5 e na Figura V 6 Em ambos os casos realizou se a transfer ncia de som durante cerca de um minuto enquanto se reproduzia musica no servidor Estes testes serviram tamb m para verificar o d bito obtido numa rede UMTS durante o per odo de execu o dos testes utilizando para tal um cart o de dados com contracto com a operadora para velocidades at 384 kbps downstream Posteriormente foram realizados testes tamb m sobre a rede HSDPA com velocidades at 3 6 Mbps downstream No caso dos gr ficos apresentados para a vers o em TCP podem se observar os resultados de dois testes realizados em instantes de tempo diferentes a azul e a vermelho utilizando o telem vel Nokia 6630 e de dois testes efectuados com o dispositivo HTC TyTN sobre uma liga o HSDPA a verde e preto No caso do UDP apesar de tamb m terem sido efectuados diversos testes sobre UMTS resolveu se n o sobrepor os gr ficos que se revelaram semelhantes pois s ia complicar a observa o dos mesmos Deste modo apresentado apenas o resultado de uma experi ncia efectuada V 5 1 1 TCP A partir da Figura V 5 facilmente se verifica que o valor m dio obtido para o d bito durante a execu o destes testes foi de 119 kbps para a rede UMTS e de 5
41. vers o que deve ser usada podendo ser igual ou inferior enviada pelo servidor As vers es do protocolo existentes actualmente s o as 3 3 3 7 3 8 sendo que a adi o de uma nova codifica o ou pseudo codifica o n o requer uma mudan a da vers o do protocolo j que o servidor pode sempre ignorar as codifica es que n o suporta A mensagem Vers o do Protocolo consiste numa cadeia de caracteres ASCII de 12 bytes no formato RFB xxx yyy n onde o xxx representa a parte inteira da vers o e o yyy representa a parte fraccion ria desta preenchidos padded com zeros A 5 1 2 Seguran a Assim que a vers o do protocolo utilizada est decidida o cliente e o servidor t m de concordar no tipo de seguran a que v o utilizar na liga o Vers o 3 7 e 3 8 O servidor lista os tipos de seguran a que suporta Numero de bytes Tipo Valor Descri o 1 U8 n mero de tipos de seguran a n mero de tipos de seguran a Vector de U8 tipos de seguran a Se o servidor listou pelo menos um tipo de seguran a suportado pelo cliente ent o o cliente envia de volta um nico byte indicando qual o tipo de seguran a a ser usado na liga o Numero de bytes Tipo Valor Descri o 1 U8 tipo de seguran a Se o tipo de seguran a zero ent o por alguma raz o a liga o falhou Isto seguido por uma cadeia de caracteres descrevendo a raz o para tal ter acontecido a cadeia
42. 0 bytes Duration 4109 ms Opening sound Input Stream Sound Input Stream created Time 58578 ms SThroughput 68 kbps PacketSize 6807 bytes RecvTime 797 ms DecodeTime 125 ms PrepPlayer 0 ms Options Figura V 1 Exemplo de um registo capturado no in cio de uma sess o Foi realizada uma colagem de v rias partes da imagem para poder concentrar o registo numa s figura 46 Para permitir o facil acesso a esta informagao foi introduzida a possibilidade deste registo ser transferido por uma liga o TCP para o servidor Por sua vez o servidor a correr a aplica o Netcat ou outra similar envia toda a informa o recebida para um ficheiro Posteriormente com o auxilio de um script elaborado para o efeito converte se a informa o relevante para um ficheiro csv comma separated values que pode ent o ser interpretado por um editor de folha de c lculo como o Excel V 3 Estat sticas Stats Neste formul rio pode ser visualizado o ltimo valor calculado para o d bito da rede bem como o valor m nimo m dio e m ximo deste Indica se a quantidade de bytes recebidos pela aplica o referentes aos dados mensagens do protocolo RFB referentes ao udio e soma total dos dois e apresenta se tamb m o n mero de actualiza es efectuadas e os valores m nimos m dios e m ximos da dimens o e dura o das mesmas ainda poss vel ao utilizador verificar a mem ria utilizada p
43. 1 2 kbps para o esquema com menos redund ncia CS 4 e com a utiliza o dos 8 time slots O n mero de time slots utilizado depende da classe do terminal m vel e da configura o da rede Na configura o da rede GPRS o operador pode reservar um determinado n mero de time slots s para tr fego de dados ou ent o pode dar prioridade voz e o tr fego de dados utiliza apenas os canais livres Desta forma o tr fego de dados depende do n mero de utilizadores activos de GSM numa c lula Na realidade os operadores utilizam normalmente o esquema de codifica o CS 2 e a maioria dos terminais m veis s o de classe multislot 6 Slots Rx 2 e Tx 2 ou Rx 3 e Tx 1 o que implica um d bito em uplink entre 13 4 e 26 8 kbps e em downlink entre 26 8 e 40 2 kbps Estes d bitos est o ainda dependentes do n vel de congestionamento da c lula que serve o terminal ou da exist ncia de time slots dispon veis Tabela 11 2 D bito m ximo em fun o do esquema de codifica o e do n mero de time slots Slots CS 1 kbit s CS 2 kbit s CS 3 kbit s CS 4 kbit s 1 9 05 13 4 15 6 21 4 2 18 1 26 8 31 2 42 8 3 27 17 40 2 46 8 64 2 4 36 2 53 6 62 4 85 6 5 45 25 67 0 78 0 107 0 6 54 3 80 4 93 6 128 4 7 63 35 93 8 109 2 149 9 8 72 4 107 2 124 8 171 2 II 3 UMTS UMTS 15 designada por Universal Mobile Telecommunication System a sigla utilizada para especificar o padr o 3G terceira gera
44. 28 328 328 ms Low Compression RevTime m avg M 3859 3969 4188 ms Decode m avg M 15 67 172 ms PrepPlayer m avg M 0 260 453 ms Memory Used 828932 1000000 bytes Options Figura V 2 Exemplo das estat sticas de uma sess o Foi realizada uma colagem de v rias partes da imagem para poder concentrar as estat sticas numa s figura 47 V 4 Ping Dado que o J2ME n o suporta pacotes ICMP s como sendo o de ping as alternativas para o c lculo do tempo de ida e volta RTT da liga o s o 1 Utilizar um servidor de eco sobre UDP e calcular o tempo entre o instante em que o pacote enviado e o instante em que este depois recebido Para este efeito o cliente envia um pacote UDP contendo um n mero de sequ ncia e o instante em que est a ser colocado na rede No lado do servidor est implementado uma thread que se limita a estar escuta num porto predefinido e a reenviar para a origem os pacotes recebidos faz eco dos pacotes Quando um pacote chega ao cliente este verifica o seu n mero de sequ ncia para averiguar se n o houve reordena o dos pacotes Seguidamente analisa o instante de tempo nele contido e compara o com o instante de tempo actual obtendo assim uma estimativa do tempo de ida e volta Resolveu se n o utilizar o porto normalmente associado ao servidor de eco porta 7 pois este servi o foi retirado dos sistemas operativos mais recentes por ser facilmente alvo de ataques de D
45. 7 20 V Rivoira and F Pascali HSDPA High speed internet over your mobile phone IEC newsletter June 2007 http www answers com topic gprs cat technology ltimo acesso em 28 08 2007 21 John W Muchow CORE J2ME TECNOLOGIA E MIDP Makron Books 2004 22 Microsoft Microsoft Developer Network MSDN http msdn2 microsoft com en us default aspx 23 3rd Generation Partnership Project GPP http www 3qpp org 65 24 GNU General Public License http www gnu org licenses gpl html 25 Global System for Mobile communications GSM http www gsmworld com 26 Institute of Electrical and Electronics Engineers IEEE http www ieee org 27 Sun Java Platform Micro Edition Java ME http java sun com javame index jsp 28 Eric Giguere Databases and MIDP Part 1 Understanding the Record Management System Sun article February 2004 http developers sun com mobility midp articles databaserms index html 29 International Telecommunication Union ITU UIT http www itu int 30 H lio Candeias Sistema de Tele Vigil ncia Suportado em GSM GPRS CDMA2000 e UMTS Trabalho final de curso ISEL 6 16 April 2006 66 Anexo A Protocolo RFB A 1 Protocolo de Display A parte de display deste protocolo baseia se numa nica primitiva gr fica Colocar um rect ngulo de pixeis na posi o x y especificada Numa primeira aproxima o isto pode parecer uma forma ineficiente d
46. 8 19 N mero do Pacote N mero do Pacote o Tempo de prepara o do player para tocar o pacote de som ms Figura V 5 Gr ficos relativos transfer ncia de som por TCP durante cerca de 1 minuto duas sess es distintas sobre UMTS e duas mais sobre HSDPA V 5 1 2 UDP Na Figura V 6 comparando com a transfer ncia de som por TCP rapidamente se verifica que para aproximadamente o mesmo intervalo de tempo s o trocados bastantes mais pacotes de som Isto deve se ao facto do tamanho m ximo de um datagrama UDP ser de 512 bytes e assim por cada pacote de som de 32000 bytes 4 segundos o servidor envia 64 datagramas de 500 bytes cada Como cada datagrama tem 8 bytes de cabe alho overhead a efici ncia na transfer ncia de um pacote de som n o comprimido de 98 4 Este valor foi calculado atrav s da f rmula 1 bytes uteis 1 efici ncia total de bytes transferidos No caso do TCP o overhead existente o relativo troca de mensagens de in cio e fim de sess o e o provocado pelos cabe alhos dos segmentos TCP 20 bytes No entanto n o poss vel dar um valor de efici ncia concreto para este m todo pois est dependente da segmenta o dos 52 pacotes efectuada pelo sistema operativo e pelos comutadores desprezando os bytes transferidos durante o inicio e fim de sess o Deste modo a efici ncia deste protocolo para a transfer ncia de um pacote de som de 32000 bytes p
47. 93 kbps sobre HSDPA Dado que estes valores s o praticamente constante nestes testes tirando algumas oscila es observadas nos gr ficos referentes aos testes efectuados sobre HSDPA de esperar que o tempo de recep o dos pacotes seja proporcional ao tamanho dos mesmos o que de facto se verifica Ou seja quando se recebe um pacote de dimens es menores o tempo que se leva a receb lo tamb m menor e vice gt Foi realizada uma colagem de v rias partes da imagem para poder concentrar o formul rio de Ping numa s figura 50 versa O desvio padrao obtido para o d bito na rede UMTS foi de 15 36 kbps e o intervalo de confian a a 95 114 0 123 4 Para a rede HSDPA obteve se um desvio padr o de 94 0 kbps e o intervalo de confian a a 95 542 4 604 7 No gr fico a azul pode se tamb m observar que o pacote n mero 15 representando momentos de sil ncio entre duas faixas de m sica foi comprimido de 32000 bytes para 5954 bytes Neste caso se estivesse a ser utilizada supress o de sil ncio com por exemplo um limiar de 10000 bytes este pacote n o teria sido enviado pelo servidor e no cliente nada seria reproduzido Como a supress o de sil ncio n o estava a ser utilizada tornou se aud vel o ru do de fundo caracter stico do sil ncio electr nico durante os 4 segundos de dura o da amostra de som Por an lise dos gr ficos verifica se que o tempo de descompress o de um pacote n o depende do s
48. A 5 3 6 Texto enviado pelo cliente Actualmente a nica forma de transferir texto atrav s do formato Latin 1 ISO 8859 1 Os fins de linha s o representados por um n linefeed e n o s o precisos r carriage return Numero de bytes Tipo Valor Descri o 1 U8 6 tipo de mensagem 3 enchimento com zeros padding 4 U32 comprimento comprimento Vector de U8 texto 74 A 5 4 Mensagens do servidor para o cliente A 5 4 1 Actualiza o ao Framebuffer Uma Actualiza o ao framebuffer consiste numa sequ ncia de rectangulos com dados de pixeis que o cliente deve p r no seu framebuffer enviada em resposta a um Pedido de Actualiza o ao Framebuffer por parte do cliente podendo existir um per odo indefinido entre pedido e resposta Numero de bytes Tipo Valor Descri o 1 U8 0 tipo da mensagem 1 enchimento com zeros padding 2 U16 n mero de rect ngulos Esta mensagem inicial seguida por n mero de rect ngulos rect ngulos com dados de pixeis Cada rect ngulo consiste em Numero de bytes Tipo Valor Descri o 2 U16 posi o x 2 U16 posi o y 2 U16 largura 2 U16 altura 4 32 tipo de codifica o Seguido pelos dados de pixeis no formato especificado A 5 4 2 Definir as Entradas do Mapa de Cores Quando o formato dos pixeis usa um mapa de cores esta mensagem diz ao cliente que os valores de pix
49. FA WinvVNC UDP TCP Heade Figura IV 5 Navega o pelo ambiente de trabalho em zoom normal na aplica o original IV 2 1 Altera es efectuadas Apesar deste m todo requerer pouca memoria no telem vel para navega es intensivas pelo ambiente de trabalho o acesso rede consider vel e constante e n o apelativo ao utilizador Deste modo foi criado um novo m todo para efectuar altera es ao factor de escala da imagem vis vel e foi criado um novo modo de navega o Para al m disso foi ainda introduzido um n vel de zoom em que o ambiente de trabalho reduzido para metade 50 zoom fifty Numa primeira fase passaram a existir buffer s em mem ria para armazenar todo o ambiente de trabalho nos 3 zoom s diferentes vis veis na Figura IV 6 Um deles consegue acomodar as dimens es reais do ambiente de trabalho do servidor zoom normal um outro acomoda metade destas dimens es zoom fifty e um terceiro acomoda somente as dimens es do ecr do telem vel pois todo o ambiente de trabalho reduzido at ser vis vel por completo neste zoom out A ideia ap s efectuada uma primeira actualiza o total ao ambiente de trabalho poder se navegar por todo este incluindo mudar de factor de escala sem serem realizados novos pedidos de actualiza o 23 o Ni Gogi se F F B AHDE ANADTFAL Fian Parra Figura IV 6 Representa o dos 3 zoom s disponiveis na aplica o Da esquerda par
50. V 1 Formato da mensagem de pedido de mudan a de factor de escala 25 Tabela IV 2 Formato da mensagem indicando uma altera o ao factor de escala 25 Tabela IV 3 Formato da mensagem indicando o tipo de seguran a a utilizar 42 Tabela IV 4 Formato da mensagem contendo o nome de utilizador e a resposta ao desafio 43 Tabela V 1 Tempos de Ida e Volta obtidos no dispositivo HTC TyTn 60 Tabela V 2 Tempos de Ida e Volta obtidos no dispositivo Nokia 6630 60 vii 3G AMC API ARP ASCII DES DoS FDD FDMA GPL GPRS GSM HSDPA HTTP IEEE J2ME JPEG MMAPI MIDP MTU PCM QoS RFB RRE SSH TCP IP TDD TDMA UMTS VNC VPN RMS RTP RTSP ITU Lista de Siglas Terceira Gera o terminais m veis Adaptive Modulation and Coding Application Programming interface Address Resolution Protocol American Standard Code for Information Interchange Data Encryption Standard Denial of Service Frequency Division Duplex Frequency Division Multiple Access GNU General Public License General Packet Radio Services Global System for Mobile Communications High Speed Downlink Packet Access Hyper Text Transfer Protocol Institute of Electrical and Electronics Engineers Java 2 Micro Edition Joint Photographic Experts Group Mobile Media API Mobile Information Device Profile Maximum Transmission Unit Pulse Code Modulation Quality of Service
51. a o a este porto deve ser concedido pela firewall proxy Requer a instala o do software gr tis no computador alvo Requer a instala o da aplica o adicional a Ea Eai a pica a N o requer aplica es adicionais propriet ria no UltraVNC computador alvo RealVNC TightVNC TCP directo ou HTTP TCP directo TCP directo Sim RDM Propriet rio VNC RFB RDP Windows Remote Desktop Protocol Todas estas ferramentas requerem que os telem veis suportem Java J2ME com a especifica o MIDP2 0 que s se encontra dispon vel nos telem veis mais recentes Para n o limitar o uso da aplica o resultante neste projecto resolveu se utilizar o MIDP1 0 por ser suportado por um maior n mero de plataformas m veis Outras duas aplica es dispon veis para este mesmo efeito s o a VNC2Go www freeutils net e a j2mevnc http 2mevnc sourceforge net sendo que ambas s o de distribui o gratuita mas s a segunda open source com licen a GPL A primeira apresenta se como um ferramenta mais simples n o permitindo altera es ao factor de escala do ambiente de trabalho e revelando se mais limitada nas funcionalidades comparando com as outras solu es Tendo este facto em considera o a escolha para cliente m vel recaiu sobre a segunda op o por ser open source Deste modo n o se despendeu tempo a conceber uma aplica o de raiz visto que j existem solu es realizadas
52. a a direita zoom out zoom fifty e zoom normal Na aplica o original existiam apenas dois buffer s com as dimens es do ecr do telem vel um por cada zoom mas enquanto o correspondente ao zoom out permitia armazenar todo o ambiente de trabalho reduzido ao ponto de ser vis vel no ecr do telem vel o correspondente ao zoom normal apenas armazenava uma por o do ambiente de trabalho com as dimens es do ecr do telem vel Isto fazia com que a navega o pelo ambiente de trabalho implicasse pedidos de actualiza es constantes Com esta nova implementa o realizou se uma troca de quantidade de dados transferidos e tempo gasto ao navegar pelo ambiente de trabalho por mem ria necess ria no telem vel e uma navega o mais suave e fluida A navega o efectuada utilizando o bot o de navega o ou as teclas 2 4 6 e 8 e em qualquer altura se pode fazer mais zoom com a tecla 3 ou menos zoom com a tecla 9 para alternar entre os tr s factores de escala dispon veis Foi ainda introduzida a possibilidade de o utilizador poder optar por ter as altera es ao factor de escala realizadas do lado do servidor bastando para isso seleccionar essa op o no formul rio inicial e garantir que o servidor alvo suporta esta funcionalidade Caso isto n o se verifique a liga o ser terminada e dever se utilizar o modo em que as altera es ao factor de escala s o processadas no telem vel Ao estabelecer a sess o de VNC o cliente
53. a cumprir os requisitos identificados A alternativa de construir tudo de raiz levaria mais tempo e implicaria um maior risco alcan ando se no fim provavelmente um desenvolvimento an logo ao existente Deste modo todo o projecto baseia se na aplica o VNC que um sistema de partilha do ambiente gr fico de um computador que utiliza o protocolo RFB para controlo remoto deste Para alcan ar tal objectivo transmitem se os eventos relacionados com o teclado e com o rato de um dispositivo para o outro sendo as actualiza es ao ambiente gr fico transferidas pela rede no sentido inverso O VNC independente da plataforma que o suporta Deste modo um cliente de VNC que esteja a operar sobre um qualquer sistema operativo pode se ligar a um servidor de VNC a funcionar sobre outro qualquer sistema operativo existindo clientes e servidores desenvolvidos para quase todos os sistemas com ambientes gr ficos conhecidos e tamb m para Java A utiliza o mais popular desta tecnologia inclui a assist ncia remota e o acesso a ficheiros no computador do trabalho a partir do computador de casa ou vice versa O VNC foi desenvolvido pela AT amp T e o c digo fonte original e muitos dos seus derivados s o open source sobre licen a GPL O sistema VNC consiste num cliente num servidor e num protocolo de comunica o ver Figura 1 1 O servidor de VNC o programa que opera na m quina que partilha o seu ambiente de trabalho O cliente de VNC
54. a suportarem a extens o ao protocolo utilizada Deste modo o utilizador n o necessita de aceder a todo o ambiente de trabalho e lan ar as aplica es desejadas bastando para tal que seja efectuada uma simples configura o pr via no servidor Para melhor se descrever esta situa o apresenta se na Figura IV 15 um cen rio em que um utilizador acedeu ao servidor para ter acesso somente linha de comandos e um outro caso em que acede somente para ter acesso ao jogo Minesweeper do Windows N o representado nas 41 imagens est o facto de num dos casos o utilizador apenas poder controlar o teclado remoto e no outro apenas poder controlar o rato Figura IV 15 Exemplo de perfis de utilizador para acesso a aplica es distintas Para o servidor saber qual o utilizador que est a aceder existiam duas possibilidades ou se concebia uma nova mensagem para o protocolo RFB como se fez para as altera es ao factor de escala do lado do servidor ou se introduzia uma extens o ao protocolo inserindo um novo tipo de seguran a Sec o A 5 1 2 e Sec o A 5 2 A primeira op o tinha o aspecto negativo de fazer com que a sess o VNC fosse terminada abruptamente caso o cliente enviasse essa nova mensagem para um servidor que n o a conhecesse Para al m disso esta mensagem s poderia ser trocada depois de estabelecida a sess o e portanto era tempo desaproveitado at o cliente ter conhecimento de que o servidor em quest o n
55. adinos Limitada Ritmo de transmiss o na ordem dos 2Mbps para um utilizador que se esteja a deslocar a menos de 10 km h dentro de um edif cio Actualmente em Portugal apenas o modo FDD est em funcionamento No caso em que estejam ambos os modos a operar em conjunto o modo FDD pode ser aplicado em ambientes macro e microcelulares permitindo liga es sim tricas e para elevada mobilidade disponibilizando ritmos de transmiss o at aos 384 kbps Por sua vez o modo TDD pode ser utilizado em ambientes micro e picocelulares permitindo liga es assim tricas e sim tricas disponibilizando ritmos de transmiss o at 2 Mbps para baixa mobilidade 10 ll 4 HSDPA O servi o HSDPA High Speed Downlink Packet Access 16 foi desenvolvido com base no WCDMA e tem como principais objectivos aumentar o ritmo de transmiss o em downlink fornecido ao utilizador e melhorar a qualidade de servi o QoS O HSDPA atribui ao utilizador um canal de dados em downlink com um ritmo de transmiss o m ximo que pode chegar aos 14 Mbps A utiliza o desta tecnologia adequada para servi os em que o tr fego recebido superior ao tr fego enviado tal como acontece quando se navega na Internet ou na transmiss o de v deo em tempo real multicast Uma das principais t cnicas empregues nesta tecnologia para obter um elevado ritmo de transmiss o em downlink a utiliza o de uma modula o e codifica o adaptativa AMC Adaptive Modulation a
56. ados necess rio estabelecer a sess o entre os dois pontos de comunica o A transfer ncia de informa o pode ser efectuada em ambos os sentidos e quando esta termina necess rio terminar a sess o para libertar os recursos do sistema Ambos os terminais sabem quando uma sess o iniciada e terminada e ambos podem iniciar ou terminar uma liga o Sendo a transfer ncia de dados efectuada numa sequ ncia de bytes stream n o existem fronteiras na informa o transferida ou seja os segmentos enviados podem ser fragmentados ou agrupados a outros dependendo do n vel de carga da rede dos algoritmos de comuta o utilizados de erros aleat rios e de outros par metros que n o se podem controlar A nica garantia oferecida 28 que todos os dados ser o recebidos no destino sem erros e na ordem correcta Na eventualidade de surgirem erros durante a transmiss o de dados os segmentos afectados ser o retransmitidos Na Figura IV 7 pode se ver o formato do cabe alho de uma trama TCP one roves oe GRR ac mm 20 TCP Options optional a 2 Be 20 We Siva S67 8 Gra OT SGA A Ss CMB Gn je Nibble e Byte Word TCP Flags Congestion Notification TCP Options Offset e DC DO e C E U A PUR SF ECN Explicit Congestion O End of Options List Number of 32 bit words in Notification See RFC 1 No Operation NOP Pad TCP header minimum Congestion Window 3168 for full details valid 2 Maximum segment s
57. ados ao assunto duas solu es para solucionar esta lacuna foram identificadas Introduzir uma extens o ao protocolo para acomodar a transfer ncia de sons associados a eventos Desta forma caso um evento ocorra o servidor envia uma mensagem ao cliente contendo uma cadeia de caracteres com o nome do evento Se o cliente tiver conhecimento de que som tocar para esse evento particular toca o se n o souber envia uma resposta ao servidor pedindo lhe que envie o ficheiro com o som a reproduzir formava se assim uma esp cie de cache no cliente Esta solu o encontra no entanto alguns reveses Para al m do protocolo RFB existente apenas permitir extens es ao n vel de codifica es pseudo codifica es e tipos de seguran a ver Anexo A sec es A 4 A 5 2 A 5 5 A 5 6 fazendo com que a cria o de novas mensagens possa por em risco a compatibilidade com clientes e servidores j existentes tamb m o facto desta alternativa apenas permitir transferir sons relacionados a eventos e n o todo o udio dispon vel no servidor m sica sons exteriores capturados pelo microfone etc fez com que esta solu o fosse descartada Utilizar uma liga o paralela sess o RFB especificamente criada para transferir o som A ideia fazer streaming de todo o udio que chega placa de som atrav s de uma sess o dedicada do servidor para o cliente Com esta alternativa levantaram se algumas quest es pertinentes nomeadamente como se
58. aliza o o tempo que esta demorou a ser recebida por inteiro e com estes dois valores calcula se uma estimativa do valor m dio do d bito downstream da rede durante este intervalo de tempo O valor do d bito da rede neste caso vem afectado pelo tempo de processamento dos dados medida que estes v o sendo recebidos e pelo correspondente desenhar no ecr por parte do telem vel Deste modo este valor n o pode ser considerado uma estimativa exacta mas serve para dar uma ideia deste par metro at 45 porque realizando as altera es ao factor de escala no lado do servidor onde o processamento efectuado pelo telem vel inferior as estimativas s o razoavelmente id nticas No caso da transfer ncia de um pacote de som s o apresentados para al m dos valores referidos no caso anterior o tempo que a amostra leva a ser descodificada e o tempo que se levou a preparar o player para reproduzir essa mesma amostra O valor aqui obtido para o d bito da rede pode ser considerado mais exacto que o anterior pois o pacote recebido por inteiro e s posteriormente efectuado o seu processamento Seleccionaram se estes m todos para c lculo do d bito da rede porque utilizam as transfer ncias de informa o nativas aplica o n o obrigando a tr fego adicional e porque para actualiza es ao ambiente de trabalho completo e nas transfer ncias de som em TCP a quantidade de informa o transferida na ordem das dezenas de
59. ante uma sess o VNC 50 Figura V 5 Gr ficos relativos transfer ncia de som por TCP durante cerca de 1 minuto 52 Figura V 6 Gr ficos relativos transfer ncia de som por UDP durante cerca de 1 minuto 54 Figura V 7 Imagem utilizada para os testes s actualiza es ao ambiente de trabalho 55 Figura V 8 D bito obtido na rede GPRS eee aeee aerea naaraana 55 Figura V 9 Dura o das actualiza es quando a altera o ao factor de escala realizada no telem vel hte eeteietii a A A iin eee hr dave Het een hie a Cee i gil 56 Figura V 10 Dura o das actualiza es quando a altera o ao factor de escala realizada no lado GO SCRVIGOR ii DR PE EN PDR aie hee ec eta E ead CU DR RENO NEN RR CD DN RR O RR 57 Figura V 11 Gr ficos relativos utiliza o da aplica o num cen rio t pico 59 vi Lista de Tabelas Tabela 11 1 Esquemas de codifica o do GPRS eee 9 Tabela 11 2 D bito m ximo em fun o do esquema de codifica o e do numero de time slots 9 Tabela 11 3 Evolu o da Tecnologia GSM rr eaeeaacaaeeea aeee anna 11 Tabela III 1 Compara o entre as tr s solu es oferecidas pela SHAPE services 4 13 Tabela III 2 Resumo das principais caracter sticas das v rias aplica es de controlo remoto 14 Tabela I
60. anterior mais o tempo de descodifica o e prepara o do player A varia o do d bito da rede relativa a testes efectuados transfer ncia de som pode ser observado na Sec o V 5 1 Na solu o em UDP o c digo que trata da implementa o do som divide se em duas threads e pode ser interpretado no diagrama de blocos apresentado na Figura IV 13 A thread de recep o que se dedica a receber os pacotes de som a descomprimi los se vierem comprimidos e a armazen los em mem ria buffering A thread de gest o do udio que inicialmente envia uma mensagem para o servidor pedindo o in cio de uma sess o de transfer ncia de som Posteriormente recebe o 38 cabegalho WAVE enviado pelo servidor que para al m de servir para dimensionar o buffer de recep o serve tamb m de confirma o de que a mensagem de pedido de inicio de sess o foi transmitida com sucesso De seguida cria a thread de recep o e gere o udio armazenado por esta distribuindo o pelos dois players Isto sempre que o udio armazenado corresponder a mais de 4 segundos de som um player preparado para reproduzi lo e assim que o outro player deixe de tocar caso o esteja a fazer este inicia a reprodu o da pr xima amostra de udio Thread Recep o Thread de gest o do udio recebido Envia pedido de in cio de sess o Recebe cabe alho Recebe pacotes de som WAYE e cria buffers Descomprime os Cria a thread de
61. ao utilizador esta escolha Scaling no servidor com smooth nav 40000 35000 4 30000 4 Pe ad cmd ee SUNS am 25000 4 20000 zoom 50 15000 4 zoom 33 3 10000 A A sa 5000 444 a zoom 100 dura o ms 1 2 3 4 5 6 7 8 9 10 numero da actualiza o Figura V 10 Dura o das actualiza es quando a altera o ao factor de escala realizada no lado do servidor Estes valores s o no entanto apenas indicativos para a situa o em quest o pois para ambientes de trabalho menos complexos os tempos gastos por actualiza o em GPRS podem baixar para valores entre 5 a 15 segundos e at menos para uma liga o sobre UMTS O facto de se realizarem actualiza es integrais tamb m um caso extremo porque tirando a actualiza o inicial e algum pedido para tal por parte do utilizador a maioria das actualiza es ser o incrementais ou seja apenas ser o transferidas as por es do ambiente de trabalho que sofreram altera es Por consequente os tempos associados a este tipo de actualiza es ser o consideravelmente menores Utilizando um telem vel PDA HTC TyTn processador Samsung a 400Mhz para realizar o mesmo ensaio deparou se com um tempo dispendido por actualiza o bastante superior Neste caso obtiveram se tempos na ordem dos 7 minutos ao inv s dos 30 segundos obtidos no Nokia 6630 Para analisar se o motivo para tal acontecimento num disposit
62. ar a palavra chave a ser utilizada pelo cliente faz com que este ltimo responda enviando n o s a resposta ao desafio como acontece no modo de autentica o normal mas tamb m o nome do utilizador associado ao perfil pretendido como se pode ver na mensagem representada na Tabela IV 4 Tabela IV 4 Formato da mensagem contendo o nome de utilizador e a resposta ao desafio Numero de bytes Tipo Valor Descri o 16 U8 nome do utilizador 16 U8 resposta ao desafio Para conseguir este objectivo foi gerada uma estrutura de dados no servidor de facil configura o atrav s de uma interface gr fica representada na Figura IV 16 que armazena as propriedades dos diferentes perfis de utilizador O formato utilizado para a estrutura em quest o pode ser visualizado na Figura IV 17 WinYNC User s Configuration User cmd standard cond mines Apply Remove Disable Remote Keyboard Cancel Disable Remote Pointer App to Run c windows system32 cmd exe While Connected V Remove Wallpaper V Remove background pattern MV Disable User Interface effects Figura IV 16 Interface grafico para configura o dos perfis de utilizador typedef struct _users char user 16 BOOL wallpaperDisabled BOOL patternsDisabled BOOL effectsDisabled char App 200 BOOL keyboardDisabled BOOL mouseDisabled UserProfile Figura IV 17 Estrutura de dados utilizada pa
63. bstituir os sistemas anal gicos utilizados at ent o na Europa o GSM foi concebido para dar suporte principalmente a servi os de voz mas posteriormente passou a suportar tamb m servi os de dados O GSM 1800 foi disponibilizado tamb m a n vel Europeu no ano de 1997 com a finalidade de diminuir a sobrecarga em termos de capacidade do GSM 900 No que diz respeito ao espectro de frequ ncia o GSM 900 utiliza a banda entre 935 e 960 MHz nos canais de downlink e utiliza a banda entre 890 e 915 MHz para os canais de uplink enquanto que o GSM 1800 utiliza a bandas entre 1805 e 1880 MHz para os canais de downlink e utiliza a banda entre 1710 e 1785 MHz para os canais de uplink No GSM 900 cada banda subdividida em 124 portadoras e no GSM 1800 em 374 portadoras espa adas de 200 kHz Cada portadora ainda dividida em 8 time slots correspondendo a cada time slot um canal a atribuir a cada utilizador uma tecnologia que utiliza para acesso ao canal r dio a combina o das t cnicas de divis o no tempo TDMA e na frequ ncia FDMA dadas as limita es do espectro O GSM foi desenvolvido tendo como principal objectivo a conquista do mercado de voz e apenas posteriormente surgiram alguns servi os de dados limitados pelo baixo ritmo de transmiss o dispon vel Tais servi os apresentam um ritmo de transmiss o m xima de 14 4 kbps e uma vez que esta tecnologia utiliza a comuta o de circuitos evidente a desvantagem na tarifa aplicada a
64. cala unit rio o que fazia com que a por o da imagem vis vel no telem vel correspondesse a uma por o do ambiente de trabalho com exactamente as dimens es do ecr do telem vel zoom normal A navega o no modo de zoom out era realizada pelo deslocamento de uma pequena sec o com o objectivo de seleccionar a rea qual se deseja alterar o factor de escala Todas as passagens para o modo de zoom normal implicavam um pedido de actualiza o ao servidor pois o 22 cliente apenas guardava em mem ria uma c pia do ambiente de trabalho em zoom out Para percorrer todo o ambiente de trabalho do servidor em modo zoom normal visto que apenas era guardado em mem ria uma por o deste correspondente s dimens es do ecr do telem vel cada movimento em qualquer direc o implicava um pedido de actualiza o ao servidor de uma parcela do ambiente de trabalho correspondente ao deslocamento efectuado Assim se um movimento para a direita implica um deslocamento de X pixeis nesta direc o a imagem vis vel no telem vel sofrer um deslocamento igual para a esquerda revelando um rect ngulo branco com X pixeis de largura e a ocupar toda a altura do ecr do telem vel Seguidamente efectuado um pedido de actualiza o ao servidor correspondente por o do ambiente de trabalho que falta para completar a imagem vis vel na nova posi o Este efeito pode ser observado na Figura IV 5 Ba WinvINC TCP script PNG
65. colos utilizados pelo GRPS j por si garantirem a entrega de pacotes ou seja esta caracter stica do TCP torna se redundante A especifica o do GPRS define protocolos para o plano de transmiss o e para o plano de sinaliza o Entre eles encontram se o LLC Logical Link Control e o RLC R dio Link Control sendo que o primeiro prov uma liga o l gica bastante fi vel entre a MS Mobile Station e a SGSN Serving GPRS support nodes associado a ela Suas funcionalidades incluem controle de sequ ncia entrega 29 em ordem detec o e correc o de erros e retransmiss o O RLC tem como principal objectivo estabelecer uma liga o fi vel entre a MS e a BSS Base Station System Entre as suas fun es encontram se fragmenta o e reconstru o dos quadros LLC em blocos de dados RLC e correc o de erros atrav s de um mecanismo de retransmiss o selectiva desses blocos Apesar disto pode existir perda de pacotes numa liga o GPRS mas a sua incid ncia relativamente rara e dif cil de quantificar 8 9 10 N o tem fronteiras nos pacotes recebidos Ou seja como referido anteriormente pode receber v rios segmentos juntos quando estes foram enviados separados ou pode receber um nico segmento quando foram enviados v rios preciso criar essas fronteiras para se poder fazer uso da informa o recebida N o pode ser utilizado para broadcast ou multicast IV 3 1 2 UDP User Datagram Protocol Definido n
66. de caracteres especificada como sendo o comprimento desta seguido desse mesmo numero de caracteres ASCII Numero de bytes Tipo Valor Descri o 4 U32 comprimento da razao comprimento da razao Vector de U8 cadeia de caracteres descrevendo a razao 69 O servidor termina a liga o depois de enviar a cadeia de caracteres descrevendo a raz o Vers o 3 3 O servidor decide o tipo de seguran a a ser usado e envia o ao cliente Numero de bytes Tipo Valor Descri o 4 U32 tipo de seguran a O valor zero significa que a liga o falhou e seguido por uma cadeia de caracteres descrevendo a raz o conforme descrito anteriormente Os tipos de seguran a definidos s o Numero Tipo 0 Invalido 1 Nenhum 2 Autentica o do VNC 5 RA2 6 RA2ne 16 Tight 17 Ultra 18 TLS Quando o tipo de seguran a decidido os dados espec ficos para esse tipo de seguran a s o enviados de seguida Depois vers es 3 8 e posteriores o servidor envia uma mensagem ao cliente informando se foi bem sucedida a troca de mensagens de seguran a Numero de bytes Tipo Valor Descri o 4 U32 status 0 OK 1 failed Note se que depois da fase de troca de mensagens de seguran a poss vel que os restantes dados do protocolo sejam trocados por um canal cifrado ou de qualquer outra forma alterado No caso de ser bem sucedi
67. de requisitos acerca do cliente facilitando o desenvolvimento de clientes nos mais variados tipos de hardware no caso deste projecto no hardware limitado dos telem veis Possui ainda caracter sticas que permitem reduzir a largura de banda utilizada como por exemplo reduzindo o n mero de cores a utilizar retirando o Wallpaper e padr es de fundo permitindo transferir s as partes que sofrem altera es no ambiente de trabalho fazendo actualiza es s quando solicitadas pelo cliente etc Estas caracter sticas tornam se bastante teis dadas as capacidades limitadas das redes m veis celulares e o pre o cobrado pelas operadoras ao kilobyte transferido Esta aplica o permite ainda que v rios utilizadores estejam ligados ao mesmo servidor ao mesmo tempo possibilitando o desenvolvimento de trabalho cooperativo No lado do cliente terminal m vel resolveu se utilizar Java J2ME no seu formato MIDP1 0 CLDC1 0 pois a maioria dos telem veis existentes no mercado suportam o uso desta tecnologia tentando se assim abranger o maximo de plataformas m veis poss veis Existem j alguns programas dispon veis concebidos para este efeito sendo um dos objectivos deste projecto o de melhorar e contribuir para a aplica o open source existente http j2mevnc sourceforge net e adicionar lhe novas funcionalidades Nomeadamente acrescentou se a possibilidade de transfer ncia de udio entre o servidor e o cliente Sec o IV 3 tendo
68. destes gr ficos o que o utilizador est a realizar nos instantes da recep o dos pacotes Por exemplo o primeiro pacote 63898 bytes representa a actualiza o inicial ao ambiente de trabalho remoto O quarto pacote 33069 bytes indica que o documento Word foi aberto e por consequente uma maior rea do ambiente de trabalho remoto sofreu altera es Seguem se actualiza es de dimens es reduzidas entre 230 e 5419 bytes que indicam altera es posi o do cursor selec o de texto escrita de uma pequena frase e mudan a de linha etc Depois de gravar o documento deparamo nos com algumas actualiza es de dimens es superiores entre 22006 e 57395 bytes que representam o fecho do documento de Word a altera o para a aplica o Thunderbird e o abrir da janela referente cria o do novo e mail Sucedem se v rias actualiza es referentes a deslocamentos do cursor e escrita do destinat rio e do assunto entre 159 e 3500 bytes e uma actualiza o referente ao abrir da janela onde se escolhe o documento a anexar ao e 58 mail 23428 bytes Facilmente se interpretar o tamb m as restantes actualiza es efectuadas mas tentou se apenas dar aqui uma ideia da an lise dos gr ficos Verifica se ainda que o tempo de recep o dos pacotes tende a ser directamente proporcional s dimens es das actualiza es mas nota se que em alguns casos o tempo de recep o maior que o suposto possivelmente devido a atrasos i
69. do o protocolo continua com a mensagem de Inicializa o do cliente A 5 1 3 Inicializa o do cliente Depois de o cliente e o servidor acordarem o tipo de seguran a o cliente envia uma mensagem de inicializa o Numero de bytes Tipo Valor Descri o 1 U8 flag partilha de desktop A flag partilha de desktop sera diferente de zero se o servidor deve tentar partilhar o ambiente de trabalho deixando outros clientes ligados e sera zero se o servidor deve dar acesso exclusivo ao cliente terminando a ligagao com todos os outros clientes ja ligados 70 A 5 1 4 Inicializagao do servidor Depois de receber a mensagem de Inicializa o do cliente o servidor envia lhe uma mensagem de inicializa o indicando as dimens es do seu framebuffer o formato dos pixeis que pretende utilizar e o nome associado ao ambiente de trabalho Numero de bytes Tipo Valor Descri o 2 U16 largura do framebuffer 2 U16 altura do framebuffer 16 PIXEL_FORMAT formato de pixel do servidor 4 U32 comprimento do nome comprimento do nome Vector de U8 cadeia de caracteres do nome Onde PIXEL_FORMAT Numero de bytes Tipo Valor Descri o 1 U8 bits por pixel 1 U8 profundidade 1 U8 flag big endian 1 U8 flag true colour 2 U16 maximo de vermelho 2 U16 maximo de verde 2 U16 maximo de azul 1 U8 deslocamento de vermelho 1 U8 deslocamento de verde
70. do de autentica o normal ser o utilizadas as propriedades definidas no utilizador base standard que n o pode ser apagado do servidor mas apenas alterado Se um cliente normal ou seja um cliente que n o cont m a extens o para este novo tipo de seguran a se tentar ligar ao servidor quando este est a exigir autentica o para a utiliza o dos perfis de utilizador ser apresentado um erro de seguran a e a sess o n o ser estabelecida 44 Capitulo V Ferramentas e testes de desempenho V 1 Introdu o Sendo outro dos objectivos do trabalho o estudo das capacidades e caracter sticas das redes m veis celulares GPRS UMTS e da consequente viabilidade do projecto a operar sobre as mesmas foram realizados alguns testes com o intuito de estimar alguns par metros espec ficos destas redes Para este efeito existe um registo Log onde s o armazenados os valores referentes a cada transfer ncia de dados som efectuada existe um formul rio de estat sticas stats onde se podem visualizar os valores totais m nimos m dios e m ximos relativos s transfer ncias de dados som anteriores e existe um formul rio onde se pode observar o decorrer de um Ping ao servidor e os correspondentes tempo de ida e volta obtidos Um dos par metros que n o aqui calculado a varia o de atraso na rede jitter porque implica uma sincroniza o dos rel gios entre o cliente e o servidor que n o foi poss vel obter A obten
71. do protocolo s o enviados sem serem cifrados 71 A 5 2 2 Autenticagao do VNC usada a autentica o pr pria do VNC e os dados do protocolo s o enviados sem serem cifrados O servidor envia um desafio aleat rio de 16 bytes Numero de bytes Tipo Valor Descri o 16 U8 desafio O cliente cifra o desafio com DES usando a palavra chave fornecida pelo utilizador e envia o resultado de 16 bytes de volta ao servidor Numero de bytes Tipo Valor Descri o 16 U8 resposta O protocolo depois prossegue normalmente A 5 3 Mensagens do cliente para o servidor A 5 3 1 Definir o formato dos pixeis Esta mensagem define o formato em que os valores dos pixeis devem ser enviados nas mensagens de Actualiza o ao Framebuffer Se o cliente n o enviar uma mensagem a Definir o formato dos pixeis ent o o servidor envia os valores dos pixeis no seu formato natural conforme foi especificado na mensagem de Inicializa o do servidor Se a flag de true colour estiver a zero isto indica que o mapa de cores para ser usado O servidor pode definir qualquer das entradas do mapa de cores usando a mensagem Definir as Entradas do Mapa de Cores Imediatamente depois de o cliente ter enviado esta mensagem o mapa de cores fica vazio mesmo que tenha sido previamente preenchido pelo servidor Numero de bytes Tipo Valor Descri o 1 U8 0 tipo da mensagem 3 enchimen
72. e foram adicionadas novas funcionalidades e realizados alguns melhoramentos aplica o tentando se n o alterar significativamente o modo de funcionamento desta De seguida apresenta se uma lista de novas funcionalidades e altera es efectuadas 1 Quando se estabelecia uma conex o apenas se recebia uma por o do ambiente de trabalho das dimens es do ecr do telem vel e o utilizador tinha de ir navegando para descobrir o resto do ambiente de trabalho A aplica o passou a iniciar se num modo em que todo o ambiente de trabalho encontra se reduzido ao ponto de ser vis vel no ecr do telem vel zoom out sendo efectuado um pedido de actualiza o a todo o ambiente de trabalho mal se estabelece a liga o ao servidor Deste modo o utilizador obt m um panorama geral do que se passa no computador remoto podendo posteriormente fazer um zoom parte que lhe interessa mais e interagir com esta Apesar da transfer ncia inicial de todo o ambiente de trabalho implicar mais tr fego na liga o de dados as actualiza es posteriores tornam se menores pois apenas s o enviadas as sec es do desktop que sofreram altera es desde a ltima actualiza o Este efeito pode ser melhor compreendido atrav s da Figura IV 1 onde no lado esquerdo se pode constatar o in cio de uma sess o na aplica o original e a necessidade de se navegar pelo ambiente de trabalho para obter um panorama do que este nos reserva Inicialmente apenas a
73. e navega o cursor SMS e escrita assim como as que permitem modificar o factor de escala n o funcionam Para solucionar isto foi adicionado um novo menu Change Mode onde se pode escolher o modo desejado e fazer zoom in e zoom out sem o recurso s teclas predefinidas 21 Como a maioria destes telem veis t m tamb m um estilete stylus que pode ser utilizado para mexer o cursor do rato independentemente do modo seleccionado passou tamb m a ser permitido no modo de escrita navegar pelo ambiente de trabalho com as teclas de navega o do telem vel Deste modo para utilizadores de telem veis com estilete e teclados qwerty poss vel navegar pelo ambiente de trabalho mexer o cursor do rato e escrever utilizando o teclado integrado tudo sem ter de alternar entre modos como acontece nos telem veis mais usuais 13 No caso de perda ou furto do telem vel os endere os dos sistemas anfitri es e correspondentes palavras chave armazenadas na aplica o davam a quem tivesse acesso ao telem vel a possibilidade directa de os controlar remotamente Para evitar tal situa o tornando mais segura a aplica o foi introduzido um mecanismo de seguran a que passa pela utiliza o de uma palavra chave a restringir o acesso ao formul rio do livro de endere os Deste modo dentro deste formul rio existe a op o Set Master Pass que permite definir a palavra chave para acesso ao mesmo No caso de nenhuma palavra chave ser i
74. e depois de comprimidas tiverem uma dimens o inferior ser o consideradas representativas de momentos de sil ncio e n o ser o enviados ao cliente Alguns valores para a compress o dos pacotes de audio podem ser observados na Figura V 5 IV 4 Perfis de Utilizador Tendo em considera o que a interface do telem vel ainda relativamente limitada comparada com a interface do PC teclado rato e que por isso o controlo deste ltimo atrav s do telem vel requer alguma habilidade e paci ncia por parte do utilizador uma nova funcionalidade implementada foi um perfil de utilizadores do lado do servidor A ideia permitir a cria o de novos tipos de utilizadores concedendo ou n o a estes o controlo remoto do rato e ou do teclado a escolha ou n o de uma aplica o espec fica para o servidor disponibilizar ao cliente o ambiente de trabalho vis vel no telem vel fica limitado rea da aplica o seleccionada e a possibilidade de para certos utilizadores desactivar ou n o o Wallpaper padr es de fundo e efeitos do Windows que s o recursos que consomem largura de banda A ideia tamb m a de permitir diferenciar clientes de telem vel onde a largura de banda um factor importante de clientes a aceder atrav s de um computador pessoal numa rede local ou mesmo pela Internet onde a largura de banda j n o um factor t o crucial Claro que para tal ser poss vel necess rio alterar os clientes existentes para PC s par
75. e desenhar as coisas no entanto disponibilizando v rios tipos de codifica o para os pixeis isto permite bastante flexibilidade em par metros como sendo a largura de banda rapidez de desenhar do cliente e velocidade de processamento do servidor Uma sequ ncia destes rect ngulos faz uma actualiza o update Uma actualiza o representa uma mudan a de um estado do framebuffer v lido para outro portanto em certos aspectos parecido com uma frame de v deo As actualiza es s o requisitadas pelo cliente ou seja uma actualiza o s enviada do servidor para o cliente em resposta a um pedido expl cito do cliente Isto d ao protocolo uma qualidade adaptativa pois quanto mais lento o cliente e a rede forem mais lento ser o ritmo de actualiza es Por exemplo ao arrastar uma janela no ambiente de trabalho as altera es no framebuffer acontecem umas a seguir s outras mas com um cliente ou rede lenta os estados transientes podem ser ignorados o que resulta em menos tr fego na rede e em menos processamento e correspondente desenhar no ecr por parte do cliente este pode s desenhar a janela na sua posi o inicial e depois na sua posi o final A 2 Protocolo de entrada input A parte de entrada deste protocolo baseia se nos modelos standard de um teclado e de um rato multi bot es ou dispositivos an logos O cliente envia eventos ao servidor consoante o utilizador carrega nas teclas ou mexe no rato e o
76. e estiver comprimido Prepara player 2 e reproduz amostra de som se o player 1 j tiver terminado Inicia Sess o be cabegalho WAVE ecra buffers Player 1 recebe udio Player 1 reproduz e Player 2 recebe udio Player 2 termina enquanto o player 1 prepara a amostra e inicia a sua reprodu o Player 1 termina enquanto o player 2 prepara a amostra e inicia a sua reprodu o Player 2 reproduz e Player 1 recebe udio Figura IV 12 Diagrama de blocos da solu o em TCP para a transfer ncia de audio Antes de enviar cada pacote de som o servidor envia 4 bytes contendo o tamanho deste O cliente utiliza esta informa o para saber a quantidade de informa o que comp e o pr ximo pacote isto porque o TCP enviando os dados numa sequ ncia de bytes stream n o delimita os pacotes Este sistema t m o inconveniente de estar merc das varia es da rede ou seja se a rede durante um intervalo de tempo tiver uma quebra de largura de banda abaixo dos 64kbps requisito necess rio para transferir 1 segundo de som em 1 segundo de tempo no formato utilizado ou um pouco menos dependendo da compress o do pacote este n o ser recebido na totalidade durante a reprodu o do pacote anterior Por consequente o sil ncio entre pacotes ser acrescido do tempo que leva a terminar de receber o novo pacote para al m da dura o da reprodu o do pacote
77. e que o utilizador se encontra em desloca o como passageiro de um ve culo sem acesso a computadores e lembra se que precisa de enviar um documento urgente pessoa X mas que esse documento se encontra no seu computador de casa Os passos necess rios que o utilizador tem de efectuar para realizar tal tarefa passam por 1 Aceder ao computador remoto Abrir o documento em quest o neste caso um ficheiro Word de uma p gina Dar uma revis o geral r pida e acrescentar uma pequena frase ao mesmo 2 3 4 Gravar o documento e fech lo 5 Abrir o Thunderbird 6 Criar novo e mail colocar assunto destinat rio e anexar o documento 7 Enviar Este teste foi realizado utilizando a rede GPRS e o telem vel Nokia 6630 sendo os resultados obtidos apresentados na Figura V 11 Todos os pedidos de actualiza es foram incrementais excepto o inicial Atrav s de uma primeira observa o dos gr ficos resultantes constata se que os valores obtidos para o d bito da rede oscilam bastante Tal ocorr ncia deve se ao facto da maioria dos pacotes transferidos serem de dimens es reduzidas do tempo de recep o destes ser afectado pelo processamento e correspondente desenhar no ecr do telem vel e pela baixa precis o do rel gio interno do Java tamb m evidente que a dimens o das actualiza es efectuadas varia ao longo do teste assim como o tempo dispendido na recep o e processamento das mesmas Pode se ainda perceber atrav s da an lise
78. eeeeeeeeeeeeeeeeseeeeeeeeeeeeeeeeenees 45 V 1 Introdu o Eus sa datas dm ne ole ado al Susto cedo ao oe lend al oe eaces ace cee ae a SR ete 45 V 2 Registo LOG isa iss heii eh IN e Hie dae o radade eo ROU Sheetal 45 V 3 Estatisticas Sais ccfeciat set sgcechs T 47 V 4 PING PRESA SEDE RN De O REP ee ae ee ee ee 48 V 5 TESTES ficoachatuttat is Sumos a eatetelbcber antag vaga RLL DRA RS ets eed E bat Ud a B cat Malu ta otha cee td 50 Vo Transfer ncia de SOM rruna eds a a ea EAE a q nad A ea aira load aide 50 V 5 2 Actualiza es integrais ao ambiente de trabalho ii irrireeeeeeanaaane 55 V 5 3 Exemplo de um poss vel cen rio de aplica o raraeeearrreaaa 58 V 5 4 Tempos de lda e Volta iirrrraenaanaaaaaaaa aeee ana aa aaa aa aaaaaaeaanaaaaaannas 59 V 5 5 Memoria requerida para o funcionamento da aplica o err 60 Cap tulo VI Conclus es e a a a aea aa a a aa aE A a A a a r ar ea aE anma atada aco casca irao sea 62 VI 1 CONGCIUSGOS 284 ci tA Rite n ad i ee ee aLi 62 VI 2 Trabalho l q0 o SOPRANO DD E AN EN DONA ND RU ah 63 Refer ncias uses sina ss io beu Sao DESSAS Da gas oe ised be GORE O os uence SL aa dao ieee tape 65 Anexo A Protocolo RFB ss sitiscoseedadostisiiid pecssicee foass lo Galo ia doa c sia s Les puaceds Ye cdesebeevsuscinvcenctiashs 67 A 1 Protocolo de DiSplay 22s ssts cre cots cos estara Ste cagas netos asia dhe a a afim dr gusb as Leste delisas sta tan 67 A 2 Prot
79. eis especificados devem ser mapeados nas intensidades RGB Red Green and Blue fornecidas Numero de bytes Tipo Valor Descri o 1 U8 1 tipo de mensagem 1 enchimento com zeros padding 2 U16 primeira cor 2 U16 numero de cores Seguido por n mero de cores repeti es do seguinte Numero de bytes Tipo Valor Descri o 2 U16 vermelho 2 U16 verde 2 U16 azul 75 A 5 4 3 Som beep Reproduz um som beep no cliente se este tiver capacidade para tal Numero de bytes Tipo Valor Descri o 1 U8 2 tipo de mensagem A 5 4 4 Texto Enviado pelo Servidor Actualmente a nica forma de transferir texto atrav s do formato Latin 1 ISO 8859 1 Os fins de linha s o representados por um n linefeed e n o s o precisos r carriage return Numero de bytes Tipo Valor Descri o 1 U8 3 tipo de mensagem 3 enchimento com zeros padding 4 U32 comprimento comprimento Vector de U8 texto A 5 5 Codifica es As codifica es definidas neste documento s o Numero Nome 0 Raw 1 CopyRect 2 RRE 239 Pseudo Codificagao do Cursor 223 Pseudo Codificagao do Tamanho do Desktop Outras codifica es registadas s o Numero Nome 4 CoRRE 5 Hextile 6 7 8 zlib tight zlibhex 256 at 240 238 at 224 222 at 1 Opc es do TightVNC A 5 5 1 C
80. ela aplica o e a dura o da liga o ao servidor o que pode ser til para redes GPRS onde alguns operadores fornecem tarif rios com taxa o por unidades de tempo Quando se encontra estabelecida uma sess o de transfer ncia de som pode ainda ser visualizado neste formul rio os valores m nimos m dios e m ximos do tempo de recep o dos pacotes de udio do tempo que levam a ser descomprimidos e do tempo que os players levam a se preparar para os reproduzir Como os pacotes de som podem vir comprimidos com dimens es consideravelmente discrepantes para permitir o c lculo de valores m dios com algum significado estes foram agrupados em 3 segmentos de igual dimens o Os valores utilizados para efectuar esta divis o s o relativos dimens o do buffer de som valor retirado do cabe alho WAVE que enviado inicialmente pelo servidor Na Figura V 2 pode ser visto um exemplo de um formul rio contendo as estat sticas de uma sess o Decode m avg M 15 15 16 ms em PrepPlayer m avg M 297 UtUAS 297 297 ms Throughput m avg M Middle Compression eat e d RevTime m avg M 15627 Data 4377 bytes Toa Ae mis Sound 157330 bytes Total 161707 bytes Duration of the Connection 1m Os Updates 2 Size m avg M 1 15 30 kB Duration m avg M 0 2 4 s Compressed Sound Packets 7 out of 8 High Compression RevTime m avg M 250 849 1641 ms Decode m avg M 0 0 0 ms PrepPlayer m avg M 3
81. elecommunication networks allowed the conception of a variety of software applications over mobile communications that usually only made sense in personal computers with Internet access Knowing this the purpose of this work was to develop an application that allows the remote control of a desktop computer using a mobile device Although a mobile phone is not the friendliest interface to remote control a desktop computer it can however become an important tool in several situations Considering all the limitations imposed by the mobile devices and by the data network that supports them several tests were made to determine the viability of the project and some work was done to solve the problems related with the APIs used in this project Also through the development of several navigation and scaling modes special attention was given in order to make the application work with as many different types of mobile devices as possible both in terms of memory and processing capabilities Original features like the possibility of sound transfer from the remote computer to the mobile device giving the user a closest idea of really being sited in front of the computer and the definition of user profiles making the access to a specific application much easier by the mobile device were introduced in this work Finally tests were made to measure specific parameters of the mobile cellular networks services used i e throughput and round trip time Ke
82. em considera o que a maior parte dos telem veis actuais n o suportam streaming sobre a API do Java utilizada MMAPI 12 mas apenas em players criados na linguagem nativa aos mesmos Permitiu se a defini o de perfis de utilizador Sec o IV 4 ou seja quando um utilizador se liga dependendo do que estiver definido no servidor para ele este poder aceder a uma aplica o espec fica em vez de ter acesso a todo o ambiente de trabalho Acrescentou se a possibilidade de as altera es ao factor de escala da imagem vis vel no ecr do telem vel serem efectuadas no lado do servidor Sec o IV 2 para minimizar os requisitos de processamento exigidos aos dispositivos m veis Por ltimo tornou se o uso da aplica o mais pr tico directo e parecido com o existente nos computadores tendo sempre em considera o as limita es impostas pelas interfaces dos telem veis Sec o IV 1 e IV 2 Para a comunica o entre telem vel e computador pessoal cliente e servidor utiliza se no telem vel as actuais redes m veis celulares existentes GPRS e UMTS e utiliza se qualquer tipo de acesso Internet por parte do computador Para provar a validade deste projecto que opera sobre redes sem fios com caracter sticas particulares foi ainda realizado o estudo do funcionamento destas redes dos seus par metros e das suas limita es Sec o V 5 1 2 Enquadramento Para o desenvolvimento deste projecto come ou se por analisar as l
83. em mpeg 4 A ideia seria a de realizar streaming do ambiente de trabalho do servidor para o telem vel No entanto foram encontradas algumas contrariedades que numa primeira abordagem n o tornaram esta op o apelativa Existiam duas solu es poss veis gt Utilizar o player nativo do telem vel para aceder ao servidor e receber em streaming o ambiente de trabalho remoto Tornava se depois necess rio conceber um m todo para interac o com o servidor pois os players comuns apenas permitem receber informa o gt Criar uma aplica o em J2ME para receber o streaming enviado pelo servidor e desenvolver um protocolo de comunica o para se poder interagir com este Esta op o n o se revelou exequivel pelas dificuldades encontradas na grande maioria dos telem veis em realizar streaming RTSP utilizando o J2ME VNC vs Criar uma nova aplica o de servidor No caso de se criar uma aplica o de raiz para correr no computador esta deveria ser multi plataforma para limitar o m nimo poss vel a sua utiliza o A alternativa seria utilizar a aplica o VNC que de distribui o gratuita e j independente da plataforma utilizada O servidor de VNC tem tamb m v rias possibilidades para reduzir a largura de banda utilizada tais como retirar o papel de fundo do ambiente de trabalho Wallpaper reduzir o n mero de cores utilizadas v rios tipos de codifica es para os formatos dos pixeis enviados permite enviar apenas as
84. envia um pedido para definir o factor de escala a utilizar caso o servidor n o reconhe a esta mensagem n o faz parte do protocolo RFB original enviar uma mensagem de erro que o cliente utiliza para terminar a sess o e informar o utilizador Esta op o permite v rios factores de escala 1 1 1 2 1 3 at todo o ambiente de trabalho ser vis vel no ecr do telem vel bastando pressionar as teclas 3 e 9 para fazer zoom in e zoom out respectivamente Ao contr rio do modo em que as altera es ao factor de escala s o processadas no telem vel neste caso por cada zoom efectuado realizado um pedido de actualiza o ao servidor Este por sua vez envia como resposta o ambiente de trabalho j afectado pelo novo factor de escala No entanto a navega o sem alterar o zoom mant m se inalterada ou seja pode se percorrer todo o ambiente de trabalho sem serem efectuados novos pedidos de actualiza o Mesmo considerando que esta funcionalidade implica a utiliza o de um buffer no servidor que ser tanto maior quanto maior for o ambiente de trabalho a armazenar e que este coloca algumas quest es negativas de performance e de utiliza o de mem ria como j existe pelo menos um servidor que disponibiliza esta funcionalidade WinVNC Version 3 3 3r7 with server side scaling 24 extensions resolveu se oferecer suporte a mesma Apesar de hoje em dia os computadores terem capacidades de memoria cada vez maiores e processadore
85. er sticas diferenciar clientes e dar acesso aos mesmos a aplica es espec ficas 5 Realiza o de testes para estudo da viabilidade do projecto sobre as v rias redes m veis celulares existentes e para estudo das caracter sticas das mesmas Durante todo o projecto um factor valorizado que se teve em considera o foi a de manter a aplica o resultante compat vel com o maior n mero de plataformas m veis poss veis Manteve se tamb m a aplica o compat vel com as diversas vers es de servidores VNC existentes com o prejudico de n o estarem dispon vel algumas das funcionalidades desenvolvidas sobre a vers o do servidor adoptada Dos testes efectuados revelou se que as redes m veis celulares existentes possuem caracter sticas suficientes para o correcto funcionamento da aplica o No entanto para a transfer ncia de som revelou se necess ria uma largura de banda superior a 64 kbps que s obtida pelas redes UMTS e HSDPA Em termos dos clientes espera se que dentro de poucos anos as interfaces inerentes aos terminais m veis estejam mais maduras para aplica es como esta com ecr s de maiores dimens es melhores resolu es e mecanismos de entrada mais simples para o utilizador 62 VI 2 Trabalho Futuro Em cada area deste trabalho existem novas funcionalidades que podem ser integradas para produzir um sistema cada vez mais robusto e apelativo ao utilizador S a titulo de exemplo sao de seguida apresentado
86. eu grau de compress o Seria de esperar que quanto maior fosse a compress o da amostra recebida maior seria o tempo que a aplica o demoraria a descomprimi la No entanto isto n o se verifica Nos testes realizados utilizando o Nokia 6630 tirando o primeiro pacote todos os outros levam cerca de 15 ms a serem descomprimidos Utilizando o HTC TyTn existe uma maior varia o dos tempos de descodifica o mas que em nada est o relacionados com a compress o efectuada pois os pacotes recebidos t m aproximadamente todos 32000 bytes No lado do servidor a compress o dos pacotes de som leva menos de 10 ms tendo este valor sido obtido por debug aplica o J a an lise do ltimo gr fico indica nos que o tempo que um player leva a preparar um pacote de 4 segundos de som para o reproduzir 32000 bytes de cerca de 300 a 400 ms no caso do telem vel Nokia 6630 e de menos de 20 ms para o HTC TyTn Este tempo no entanto n o se revelou proporcional ao tamanho dos pacotes mantendo se aproximadamente constante para pacotes de dimens es inferiores Como era desejado o tempo total que um pacote leva a ser recebido descodificado e preparado pelo player cerca de 2 5 segundos no Nokia 6630 sobre UMTS e cerca de 600 ms no HTC TyTn sobre HSDPA menor do que a dura o em termos de udio de um destes pacotes 4 segundos Deste modo a ideia de ter um player a reproduzir um pacote de som enquanto o pr ximo pacote recebido e preparado para
87. fi INSTITUTO SUPERIOR T CNICO Te A Q Controlo remoto de um PC atrav s de uma plataforma 3G em comuta o de pacotes 52208 Nuno Filipe Canoilas Freire Disserta o para obten o do Grau de Mestre em Engenharia Electrot cnica e de Computadores J ri Presidente Prof Jos Ant nio Beltran Gerald Orientador Prof M rio Serafim Nunes Vogais Prof Rui Gustavo Crespo Novembro de 2007 Agradecimentos No decorrer desta disserta o de mestrado muitos foram os incentivos e apoios que me foram dirigidos Quero agradecer em primeiro lugar ao Professor Orientador M rio Serafim Nunes e aos acompanhantes do trabalho realizado Lu s Silva Carlos Anjos e Nelson Escravana sem os quais certamente n o estaria conclu do Gostaria tamb m de agradecer os preciosos coment rios e sugest es realizadas pelos colegas de curso assim como todo o apoio oferecido pelos amigos e fam lia Resumo O desenvolvimento de novos servi os de dados suportados por novas redes de telecomunica es veio permitir a implementa o de determinadas aplica es sobre comunica es m veis que antigamente apenas faziam sentido em computadores pessoais com acesso Internet Deste modo o objectivo deste projecto foi o de desenvolver uma aplica o que permitisse o controlo remoto de um PC atrav s do uso de um simples terminal m vel Um telem vel n o tem uma interface apropriada para controlar remotamente um PC no entanto em
88. iderando que uma compressao complexa exigiria um descompressao tamb m ela complexa no hardware limitado dos telem veis No cliente associa se o cabe alho WAVE inicialmente recebido aos pacotes de udio para poderem assim ser reproduzidos pela maioria dos players existentes nos telem veis No servidor utiliza se um sistema de double buffering para a captura de som para permitir que um dos buffer s esteja a ser preenchido com uma nova amostra de udio enquanto o conte do do outro est a ser codificado e enviado para o cliente Deste modo elimina se o risco de provocar atrasos no driver do som por este n o ter um buffer dispon vel para armazenar o udio que vai capturando Este sistema funciona at um m ximo de MAX CLIENTS clientes definido a 128 no VNC para permitir que o ambiente de trabalho seja partilhado por v rios utilizadores funcionalidade do VNC e que todos possam ter acesso ao udio O primeiro cliente a estabelecer uma liga o para transfer ncia de udio faz com que o servidor reduza o volume do som do Sistema Operativo Isto necess rio para o udio ser percept vel no telem vel sendo transferido num n vel bastante reduzido para posteriormente ser amplificado pelo terminal Caso contr rio s era aud vel ru do nos telem veis testados Esta solu o foi seleccionada pela sua simplicidade por n o exigir processamento adicional dos pacotes de udio e por poder ser desej vel a redu o do volume de
89. imita es das redes m veis celulares para deduzir se seriam capazes de suportar os requisitos do projecto Verificou se que as redes UMTS 3G t m uma capacidade m xima dependente do contracto com a operadora entre 384 kbps e 14 Mbps te ricos utilizando HSDPA 3 Como se pretende abranger o mais vasto leque de telem veis poss vel verificou se tamb m que as redes GPRS permitem entre 28 kbps e 64 kbps de Downlink e 14 kbps de Uplink valores estes bastante mais limitativos Desde modo tendo em considera o as capacidades e limita es das redes analisaram se as v rias alternativas poss veis para transferir o ambiente de trabalho do servidor para o cliente para assim optar por uma via de trabalho Algumas das hip teses ponderadas foram Sequ ncia de imagens JPEG Uma imagem de 176x208 pixeis dimens es do ecr de um telem vel Nokia 6600 fica codificada neste formato com cerca de 10 kB Deste modo podia se reduzir as dimens es do ambiente de trabalho do computador para as dimens es do ecr do telem vel durante a compress o da imagem e envi la correndo o risco da imagem ser impercept vel por estar demasiado pequena Em alternativa poder se ia transferir o ambiente de trabalho em sec es com as dimens es do ecr do telem vel cortados em redor da posi o do cursor do rato Desde que o ritmo de actualiza es n o fosse bastante elevado esta hip tese pareceu nos fact vel Compress o v deo
90. ionais oferecidos pelos operadores tais como por exemplo o envio ou supress o da identifica o do chamador possibilidade de chamadas em confer ncia chamada em espera e reencaminhamento de chamadas Dependendo da rede utilizada os servi os s o estabelecidos por comuta o de circuitos ou de pacotes sendo que a principal diferen a e vantagem dos servi os que utilizam a comuta o de pacotes sobre os servi os com estabelecimento de circuitos prende se com o facto de n o utilizarem os recursos da rede quando n o se est a enviar ou a receber informa o podendo ser estabelecida uma liga o permanente que permita a transmiss o de dados de uma forma cont nua Uma outra vantagem dos servi os estabelecidos por comuta o de pacotes a factura o ser efectuada sobre o volume de informa o transferida e n o sobre o tempo da liga o Ao contr rio do que acontece numa liga o atrav s da comuta o de circuitos os recursos atribu dos numa liga o em comuta o de pacotes n o s o constantes o que faz com que a qualidade de servi o tamb m n o seja constante ll 1 GSM O GSM uma norma de comunica es m veis adoptada inicialmente ao n vel da Europa a partir do ano de 1992 para fornecimento de servi os de comunica o baseados em comunica o digital Concretamente em Portugal esta tecnologia surgiu inicialmente atrav s do operador TMN e em seguida pelos operadores Telecel e Optimus Com o intuito de su
91. ionar se a tecla desejada neste formul rio e pressionar ok que esta automaticamente enviada para o servidor No caso de teclas como shift ctrl alt left alt right meta estas s o mantidas pressionadas no servidor e aparece uma indica o no ecr do telem vel para o utilizador n o se esquecer das mesmas este efeito pode ser visualizado na Figura IV 2 b Deste modo podem ser efectuadas combina es de teclas para al m das definidas nas macros por exemplo pressionar o ctrl depois o shift ambas ficam pressionadas no servidor at nova ordem e depois o escape N o foi realizada uma lista exaustiva de todas as teclas mas tentou se disponibilizar as mais comuns sendo sempre poss vel ao utilizador definir mais macros Enter O Escape 1 1 Introdu o O BackSpace O Delete As diferen as de func A Lah mas ainda assim existem Dk crescente evolu o das ca Sair ponte para apr am 3 Escolher Cancela Op es Exi a b Figura IV 2 Teclas especiais a Parte do menu Special Keys b Exemplo de teclas mantidas pressionadas A defini o de macros efectuada no formul rio Edit Commands dispon vel no MIDlet About Figura IV 3 sendo que a sua interpreta o segue o formato introduzido pelo criador da aplica o original podendo este ser consultado no Anexo B 17 Edit Commands 240 Abe p Ctrl Alt Del lt tc lt talid gt la gt ic Figura IV 3 Formul
92. ivo de n vel superior se deve ao desenhar no ecr da imagem vis vel foram efectuados testes em que o ambiente de trabalho vai ou n o sendo desenhado no ecr medida que a actualiza o recebida Obteve se no primeiro caso tempos a rondar os 7 minutos e 30 segundos e no segundo caso 6 minutos e 55 segundos o que revela um incremento de velocidade na ordem dos 8 Dado os valores em quest o e o desespero do utilizador confirmou se assim que a diferen a entre a imagem ir sendo ou n o redesenhada no ecr ao longo da actualiza o n o um factor crucial e acarreta o benef cio do utilizador estar a par do estado da actualiza o Deste modo a nica raz o encontrada para justificar tal ocorr ncia prende se com o facto de a m quina virtual Java ser parte integrante do sistema operativo do Nokia 57 6630 Symbian e n o o ser no caso do HTC TyTn existindo uma aplica o a correr sobre o sistema operativo Windows Mobile 68 que faz a gest o dos MIDlets Java o que poder tornar mais lento o processamento dos dados tal como acontece nos emuladores utilizados para testes nos computadores V 5 3 Exemplo de um poss vel cen rio de aplica o Com o intuito de simular o funcionamento da aplica o desenvolvida num poss vel cen rio real de utiliza o da mesma foi concebida uma situa o simples em que o utilizador possa sentir a necessidade de recorrer ao controlo remoto do seu computador pessoal Deste modo imagine s
93. izado um buffer com as dimens es do ecr do telem vel para armazenar as actualiza es recebidas e como as altera es ao factor de escala implicam comunica o com o servidor necess rio efectuar pedidos de actualiza o constantes medida que se navega pelo ambiente de trabalho Com estas modifica es ficaram dispon veis 4 modos distintos de navega o e altera o ao factor de escala tentando se abranger os v rios tipos de utilizadores e os v rios modelos de telem veis existentes CS client side Scaling com Smooth Nav Modo que requer mais mem ria dispon vel da parte do telem vel mas que ser provavelmente o mais apelativo ao utilizador pela sua navega o suave e fluida CS Scaling sem Smooth Nav Requer menos mem ria que o modo anterior mas perde o sentido de navega o suave e fluida quando em zoom normal mantendo o apenas em zoom fifty A navega o em zoom normal implica pedidos de actualiza o constantes SS server side Scaling com Smooth Nav Segundo modo que requer mais mem ria permitindo tamb m uma navega o suave No entanto s o efectuados pedidos de actualiza o quando se procede a altera es ao factor de escala Este modo requer menos capacidade de processamento da parte do telem vel SS Scaling sem Smooth Nav o modo que exige menos do telem vel requerendo pouca mem ria e pouco processamento til para telem veis mais antigos e limitados mas implica actualiza es c
94. ize value of 5 Multiply by 4 to C 0x80 Reduced CWR states below 3 Window Scale get byte count E 0x40 ECN Echo ECE Packet State D B EON bis 4 Selective ACK ok U 0x20 Urgent Syn 00 1 8 Timestam A 0x10 ne O oo 1 P RFC 793 K 1 Ss P 0x08 Push E Se Checksum Please refer to RFC 793 for R 0x04 Reset No Congestion 01 00 the complete Transmission S 0x02 Syn No Condenser a TO SO Checksum of entire TCP Control Protocol TCP F 0x01 Fin Congestion 11 oo segment and pseudo Specification Reciever Response ne s d header parts of IP header TCP Header M ieee a eed Kees aa Mees Sec Se Gee a a end b Ged hia a demand a minis mis i fs a ines Lim fosse mio uni as em Sh Sequence Number Acknowledgment Number Sender Response Copyright 2004 Matt Baxter mjb fatpipe org IV 3 1 IV 3 1 Figura IV 7 Cabe alho de uma trama TCP 1 1 Vantagens do TCP Como est incorporado no Sistema Operativo gerir os segmentos recebidos implica menos mudan as de contexto do n cleo do sistema para o espa o do utilizador pois todo o processo de confirma o de segmentos controlo de congest o jun o de segmentos etc efectuado no n cleo do sistema O TCP garante que os dados chegam ao destino que s o entregues por ordem e que n o existe duplica o dos mesmos 1 2 Desvantagens do TCP O protocolo pode estar optimizado para condi es diferentes daquelas que se v o encontrar Neste caso os proto
95. ktop Um cliente que pe a esta pseudo codifica o est a declarar que capaz de aceitar uma altera o largura e ou altura do framebuffer O servidor altera o tamanho do ambiente de trabalho enviando um pseudo rect ngulo com a pseudo codifica o de Tamanho do Desktop como o ultimo rect ngulo de uma actualiza o A posi o x e a posi o y do pseudo rect ngulo s o ignoradas e a largura e a altura indicam as novas dimens es do framebuffer Mais nenhuma informa o associada a este pseudo rect ngulo 78 Anexo B Manual de Utilizagao User Guide USER GUIDE J2ME VNC by Michael Lloyd Lee modified by Nuno Freire WinVNC Version 3 3 3 r7 modified by Nuno Freire B 1 Viewer The J2ME VNC original version made by Michael Lloyd Lee has been slightly changed improved hope in this release It now supports some new features like server side scaling sound transfer and user profiles requiring a modified VNC server which is distributed with this version of the software The initial form looks like the following Password ee EER Host Name IP Address tl Username Connect Shared Desktop O NCM Address Book O SS Scaling Add Host Smooth Nav Sair Select Cancel Options Vv Close In the left figure you can see some text boxes where you can enter the host s address to which you wish to connect the password to authenticate the viewer and a username The conten
96. lo sistema operativo de referir que um duplo clique envolve 4 eventos de rato e logo implicava 4 invoca es sucessivas ao m todo correspondente pressionar do bot o libert lo pressionar e libert lo novamente Com o novo m todo implementado a thread de comunica o certifica se de que as mensagens necess rias s o colocadas na rede de forma ininterrupta Uma alternativa resolu o deste problema passa por introduzir uma nova mensagem ao protocolo RFB em que se indica claramente ao servidor que se pretende efectuar um duplo clique No entanto esta op o traria problemas de compatibilidade com os servidores existentes pois a nova mensagem ao n o ser reconhecida por estes e sendo interpretada como um comando inv lido provocaria a termina o da sess o Foram ainda simulados o bot o do lado direito do rato com a tecla 0 e o bot o de scrolling com as teclas 3 e 9 scroll up e scroll down respectivamente 18 O duplo clique ficou na tecla e o clique simples ficou na tecla 5 ou pressionando o bot o de navega o do telem vel O pressionar largar a tecla esquerda do rato diferente de clique ficou a cargo da tecla 7 e foi associada tecla 1 a op o de menu Call mouse que coloca o rato na posi o correspondente ao centro do ecr do telem vel Este ltimo ponto tem como objectivo tornar mais f cil e intuitiva uma interac o entre o modo de navega o e o modo de utiliza
97. lvimento de novas funcionalidades que envolvam programa o tanto no lado do cliente como no lado do servidor No caso do presente trabalho foi mesmo necess rio desenvolver em ambos os lados da arquitectura cliente servidor para permitir por exemplo a transfer ncia de som a realiza o das altera es ao factor de escala por parte do servidor e a defini o de perfis de utilizador Foi ainda 14 necess rio estender o protocolo de comunica o utilizado para suportar tais funcionalidades A escolha de entre as vers es de servidores VNC dispon veis recaiu sobre a vers o WinVNC Version 3 3 3r7 with server side scaling extensions pois mostrou se mais acess vel reproduzir nesta as funcionalidades existentes nas vers es posteriores do que reproduzir nas vers es mais recentes a extens o que permite realizar as altera es ao factor de escala no lado do servidor Funcionalidades como o que fazer quando o ltimo utilizador se desconecta permitir retirar o Wallpaper padr es de fundo e efeitos do Windows entre outras que s estavam dispon veis em vers es posteriores foram implementadas nesta vers o Para isso utilizou se a ideia existente e concretizou se para o c digo da vers o de VNC utilizada 15 Capitulo IV Novas Funcionalidades desenvolvidas IV 1 Melhoramentos aplica o existente Tendo em considera o um dos objectivos deste trabalho que a contribui o para o projecto open source existent
98. mO0fRep bufOut currentPos num0fRep copia dois bytes short currentPos 2 SENAO currentPos num0fRep l 89 C 2 Descompressao SE tamanho do pacote recebido tamanho do buffer ENTAO se vier comprimido Int currentPos 0 Int numO0fRep 0 PARA i 44 ATE tamanho do pacote recebido come a em 44 que depois do Cabe alho SE Som i lt ENTAO num0fRep Son i 2 copia dois bytes short PARA j 0 ATE numOfRep copia o simbolo em i 1 numOfRep vezes SE currentPos lt tamanho do buffer ENTAO Buffer temporario currentPos Som i 1 i 3 SENAO SE currentPos lt tamanho do buffer ENTAO Buffer temporario currentPos Som i Som o buffer que vai ser usado pelos players Os primeiros 44 bytes s o o cabe alho WAVE e o restante ser udio Copia buffer temporario PARA Som 90 Anexo D Repeti es de s mbolos num ficheiro de audio 3357 dddddddddAddadAddddAdddAdAS IR RR ae ee aca ome Vein TD Cd TOR TS Je ce mor e UtdWroooMms LON Demoron Ema aparece nesta lista s mbolo lt utilizado diferente do que nem sequer A ONAN ANNAN TM MN NM tA IN ANANN ANN NANTON A A AN MN edn ANS SORA ESSES ATE i ee tea pe Wa ee ma NONNOeK gt OF DHE TUD onana IVN USCH SES VSreontgwWoMmeds MODEM XK IA 75790266 Mm TAM AAR AMAMMBNNNAMOANM AN ge nA AM E A a dA ANAMN AAMT AN KT o E Plea Salah Sieh eS Shaye hate sis ihe Se TDR TR al ea a ell Eee ah sl
99. ma de dois players nota se uma pequena falha entre as amostras de udio quase impercept vel durante os testes efectuados no emulador do ambiente de desenvolvimento mas bastante mais acentuada nos testes efectuados no telem vel Isto deve se ao facto de no emulador o m todo realize do player apenas retirar a informa o relativa ao cabe alho do udio a reproduzir e quando o m todo start do player invocado s o realizadas leituras sucessivas da fonte de udio com buffer relativamente curto lt 1 Kbyte o que torna quase instant nea e impercept vel a troca entre players No entanto dos telem veis Nokia dispon veis para testes nenhum apresentou um comportamento semelhante por utilizarem buffers maiores Apenas o telem vel HTC TyTn se aproximou do comportamento obtido nos emuladores Apesar deste facto esta falha no udio bastante inferior encontrada numa solu o com um s player Por exemplo no caso do telem vel Nokia 6630 um player leva entre 300 a 400 ms a preparar uma amostra de som para reproduzir Sec o V 5 1 e mais um tempo indeterminado poucas centenas de milissegundos at inicializar realmente a sua reprodu o Isto significa que a falha existente no som de poucas centenas de milissegundos no caso dos dois players passar para cerca de 500 ms ou superior no caso de um s player No dispositivo HTC TyTn esta diferen a n o t o acentuada pois o tempo de prepara o do player inferior a 20 ms e
100. membros da equipa n o se encontrarem na proximidade uns dos outros torna se necess rio recorrer a m todos alternativos de comunica o para debaterem ideias tirarem d vidas fundamentarem op es de projecto delinear tarefas individuais etc Neste caso toda a equipa pode combinar aceder por VNC ao computador de um dos seus membros e este poder explicar atrav s de uma pequena demonstra o o que t m vindo a fazer pedir ajuda numa sec o de c digo que apresenta um erro ou inclusive utilizando uma ferramenta de desenho tentar explicar as op es de projecto consideradas ou tentar ilustrar algum conceito Durante todo este processo os restantes membros da equipa podem n o s visualizar o que se est a passar no computador remoto mas tamb m interagir com o mesmo O protocolo RFB utilizado n o mant m no cliente informa o de estado Deste modo se um cliente se desligar e se voltar a ligar ao mesmo servidor o estado do ambiente de trabalho no servidor preservado Se um segundo cliente se conectar ao mesmo servidor ele ir ter acesso exactamente ao mesmo ambiente de trabalho que o primeiro cliente e que qualquer outro cliente que se ligue posteriormente Com efeito obt m se assim o que pode ser chamado de ambiente de trabalho m vel ou seja onde quer que exista uma liga o Internet o utilizador pode aceder s suas aplica es pessoais e o estado destas preservado entre acessos VNC server VNC viewer clie
101. menta o Tendo em considera o os pr s e contras de ambas as alternativas utilizar o protocolo TCP ou o protocolo UDP resolveu se implementar a transfer ncia de som sobre ambos os protocolos de comunica o para se poder realizar uma an lise comparativa e assim seleccionar a que apresente melhores resultados Para este efeito foram efectuadas altera es tanto do lado do servidor como do lado do cliente mantendo se sempre a compatibilidade com os clientes e servidores de VNC existentes A an lise dos resultados obtidos por ambas as implementa es pode ser vista na Sec o V 5 IV 3 2 1 Altera es no lado do servidor Incorporou se no servidor uma nova thread que inicialmente abre os dispositivos de captura de udio da API do Windows e posteriormente fica bloqueada espera num socket que algum cliente se ligue Se nenhum cliente se ligar a este socket o servidor de VNC proceder como se n o tivesse sido alterado garantindo deste modo a compatibilidade com dispositivos que n o exijam som A ideia por detr s do que foi dito no par grafo anterior pode ser visualizada na Figura IV 9 onde se constata que a transfer ncia de som efectuada separadamente da comunica o VNC e que poder existir uma sess o VNC estabelecida sem correspondente sess o de transfer ncia de som O contr rio no entanto j n o se verifica Cliente telem vel Servidor Cliente normal Figura IV 9 Incorpora o do mecanismo
102. mir se o m nimo sobre a rede de dados que suporta a comunica o e sobre os players dispon veis no cliente tal como foi implementado mas permitindo negociar se uma melhor qualidade de udio transferido e mesmo diferentes formatos de codifica o Dado que algumas plataformas m veis mais recentes j come am a suportar streaming em RTSP sobre o J2ME poder se ia implementar tamb m esta solu o e permitir ao utilizador a selec o do m todo de transfer ncia de som que mais se adequasse ao seu dispositivo Uma outra caracter stica que podia ser interessante oferecer era a possibilidade da transfer ncia de som ser bidireccional Isto permitia por exemplo no caso de se estar a efectuar uma assist ncia remota que o auxiliado e o auxiliando pudessem comunicar entre si Exportar para outras plataformas Linux Mac as novas funcionalidades introduzidas no servidor de VNC para Windows Cifrar toda a informa o trocada entre cliente e servidor Neste momento toda a informa o trocada depois de estabelecida uma sess o VNC pode ser capturada por algu m alheio comunica o e deste modo ter acesso a informa o privada O nico mecanismo de seguran a existente neste momento encontra se no in cio de sess o para autenticar o utilizador atrav s da palavra chave sendo esta informa o trocada de forma segura Para proteger de um eventual furto do telem vel o acesso ao livro de endere os onde s o armazenados os si
103. n 3 ports to be able to access all the new functionalities If you have the Display Number set to zero this means that the port used by the VNC to communicate is the 5900 the port used to accept a sound transfer request from the viewer is the 5901 and the port used to be able to ping the server is the 5902 You may not allow access to the last two mentioned ports but this way you won t have access to the corresponding functionalities For other information about the VNC server please refer to the original WinVNC manual 88 Anexo C Algoritmos de compressao e descompressao C 1 Compressao Char codecRep 4 tomar conta dos s mbolos repetidos Char buf0ut tamanho do pacotes de som buffer de sa da que conter o pacote comprimido Short numOfRep tindica o n mero de repeti es 1 do simbolo actual Int currentPos findica a posi o actual no buffer de sa da Bool hotSymbol fIndica se foi encontrado um s mbolo lt codecRep 0 bufOut 0 Som 0 num0fRep 0 currentPos 0 SE Som 0 lt ENTAO Som o buffer que cont m o udio a comprimir hotSymbol verdadeiro bufOut l Som 0 currentPos 2 dewao hotSymbol falso PARA i 0 ATE tamanho do pacote de som SE currentPos gt tamanho do pacotes de som ENTAO sai do ciclo SE Som i lt ENTAO hotSymbol verdadeiro 40 s mbolo actual igual ao anterior mas ainda n o foi repetido 4x SE Som i codecRep num0fRep E numOfRep l
104. nd Coding Na Tabela II 3 vis vel a evolu o da tecnologia GSM dando se especial aten o aos ritmos de transmiss o em downlink disponibilizados pelas v rias gera es Tabela 11 3 Evolu o da Tecnologia GSM 2 56 WCDMA HSDPA GSM GPRS UMTS 900 e 1800 900 e 1800 200 200 11 Capitulo Ill An lise de Solu es Existentes A possibilidade de aceder e controlar remotamente um PC a partir de outro computador h muito que real Inclusive o n mero de produtos e ferramentas que permitem tal ocorr ncia aumentou recentemente em n mero e capacidades No entanto estes produtos s o ainda em escasso n mero quando toca a aplica es para correrem sobre plataformas m veis dadas as suas limita es inerentes Neste mbito a SHAPE services http www shapeservices com oferece algumas ferramentas de controlo remoto para correr sobre telem veis ou PDA s todas elas propriet rias e comerciais n o sendo este facto apreciado em meios acad micos Entre elas incluem se tr s variantes RDM Remote Desktop for Mobiles TSMobiles Terminal Service for Mobiles e VNC Virtual Network Computing for Mobiles A primeira solu o RDM um servi o composto por tr s componentes ver Figura II1 1 que permite aceder ao computador de casa ou da empresa quando n o se pode abrir um acesso directo a este por alguma raz o O primeiro destes componentes uma aplica o a ser instalado no com
105. nexo B Manual do Utilizador do cliente e das novas funcionalidades do servidor que foi disponibilizado comunidade open source onde o projecto original se inclui o Anexo C S o descritos os algoritmos pseudo c digo de compress o e descompress o dos pacotes de udio o Anexo D apresentado um exemplo de um ficheiro onde se podem analisar as repeti es de s mbolos ocorridos numa amostra de udio Capitulo Il Redes Moveis Celulares O sistema de controlo remoto de um computador pessoal proposto neste projecto pode ser suportado por v rias redes de acesso m vel tais como o GSM GPRS UMTS e HSDPA permitindo deste modo utilizar as v rias gera es dispon veis at hoje Neste cap tulo s o abordadas as caracter sticas gerais de cada uma destas tecnologias de acesso m vel dando se particular nfase ao ritmo m ximo de transmiss o disponibilizado para downlink sendo que esta a principal caracter stica necess ria para a viabilidade do trabalho em quest o Os servi os disponibilizados pelas redes m veis celulares podem ser divididos em tr s categorias Servi os de Suporte ou de Transporte Permitem efectuar o transporte de dados entre terminais m veis Tele Servi os Definidos em fun o dos servi os de transporte e disponibilizam as capacidades necess rias incluindo fun es no terminal que permitem a comunica o entre utilizadores Servi os Suplementares Servi os adic
106. ng the audio that is being played internally on the computer you may want to go the Wave In window Recording section and select WERA I the appropriate channel Typically only one live Options Help channel is live but once you find it it always works Ro lime CD Audio Unfortunately each audio card uses different channel Volume Volume names so you must look for a channel named something like this aE va Stereo Mix Record Master What U Hear Sum eolsctlerid turn up Sel Balance Stereo Mixer Mixed Output Wave Out Mix Wave MIDI CC C Select C Select To record external audio use the Microphone channel To create change and or delete user profiles you need to access the Users menu There you may differentiate the users by selecting different properties for each one You may also want to restrict the user control to a specific application For that you need to enter the full location of the application you want to run when the client connects substituting all the V by V At the time this new feature only allows one client to be connected at one given moment or the viewer will became all mixed up ANE EER Configuration OK New Apply Remove Disable Remote Keyboard Cancel IV Disable Remote Pointer App to Run c windows system32 cmd exe While Connected IV Remove Wallpaper V Remove background pattern IV Disable User Interface effects 87 If you re behind a router or a firewall you need to ope
107. nt faa fi m q RFB protocol A Figura 1 1 Arquitectura da VNC 1 3 Estrutura do documento Primeiro cap tulo realizada uma pequena introdu o ao trabalho desenvolvido e apresentado um resumo do racioc nio efectuado durante a fase de projecto do sistema onde foi estabelecido a base para a sua implementa o Foi ent o realizado um enquadramento abordagem seleccionada Segundo cap tulo Apresenta um pequeno enquadramento hist rico das redes m veis celulares e uma descri o geral das caracter sticas das mesmas Terceiro cap tulo realizada uma an lise global s solu es existentes e efectuada a escolha da aplica o de cliente e de servidor a utilizar Quarto cap tulo S o descritas ao pormenor todas as altera es efectuadas no cliente e no servidor revelando as novas funcionalidades implementadas Documentou se todas as decis es de projecto e problemas encontrados Quinto cap tulo S o descritos os v rios m todos implementados para aquisi o de dados que permitem efectuar uma an lise s redes m veis celulares e aos tempos inerentes ao bom funcionamento da aplica o S o ainda apresentados os resultados de alguns testes realizados Sexto cap tulo Apresentam se as conclus es e perspectivas de trabalho futuro Os Anexos cont m informa o adicional o Anexo A Apresenta o do protocolo de comunica o RFB utilizado pelo VNC o A
108. ntroduzida este mecanismo desactivado e qualquer utilizador ter acesso directo ao livro de endere os Este mecanismo apresenta no entanto um n vel de seguran a bastante simples de contornar pois apesar de proteger o acesso alheio aos sistemas anfitri es armazenados de indiv duos sem conhecimentos da aplica o poss vel atrav s do acesso ao sistema de ficheiros do telem vel e sabendo o que procurar aceder a toda esta informa o que se encontra armazenada num ficheiro criado pela API RMS Record Management System do Java IV 2 Modos de navega o e altera es ao factor de escala Sendo este um ponto importante a ter em considera o dado que os ecr s dos telem veis s o de dimens es reduzidas foram encontrados melhoramentos ao m todo existente de forma a tornar mais intuitiva f cil e apelativa a navega o e as altera es ao factor de escala scaling utilizados na aplica o Fala se em navega o porque o ecr de um telem vel apenas acomoda uma pequena por o do ambiente de trabalho de um computador comum e por isso necess rio permitir que se navegue por todo este para o utilizador ter acesso total sobre o mesmo No cliente original apenas existiam dois factores de escala ou zoom s utilizados Um deles acomodava todo o ambiente de trabalho do servidor reduzido de um factor de escala suficiente para que fosse vis vel por inteiro no ecr do telem vel zoom out O outro utilizava um factor de es
109. ntroduzidos pelo processamento dos pacotes por parte do telem vel Toda a simula o deste cen rio demorou cerca de 9 minutos a ser realizada revelando que manejar a interface ex gua do telem vel para controlar remotamente um computador exige alguma paci ncia por parte do utilizador T o 2 8 2 o a 1 10 19 28 37 46 55 64 73 82 91 100 109 118 127 N mero do pacote g 12000 7 60000 3 gt amp 10000 2 50000 o 2 8000 8 40000 ao 30000 g E 6000 kej 2 20000 4000 E kej g 10000 8 2000 e E e 0 04 1 10 19 28 37 46 55 64 73 82 91 100 109 118 127 1 10 19 28 37 46 55 64 73 82 91 100 109 118 127 N mero do pacote N mero do pacote Figura V 11 Gr ficos relativos utiliza o da aplica o num cen rio t pico V 5 4 Tempos de Ida e Volta N o sendo um factor crucial neste tipo de aplica o no entanto importante que uma ac o realizada sobre o computador remoto se repercuta neste o mais rapidamente poss vel Deste modo para se ter uma ideia dos valores envolvidos em termos dos tempos de ida e volta existentes nas redes m veis celulares foram realizados 5 Pings ao servidor utilizando ambos os m todos implementados sobre TCP e UDP Obtiveram se 25 valores para o tempo de ida e volta no caso da implementa o em TCP e mais 25 no caso da implementa o em UDP Posteriormente foi realizada uma m dia destas estimativas e foram retirados
110. o RFC 768 o protocolo UDP oferece ao contr rio do TCP uma liga o entre dois terminais n o orientada conex o n o oferecendo correc o de erros garantia de entrega nem garantia de entrega por ordem dos dados transmitidos Deste modo consegue ser mais r pido que o TCP pois s envia os dados n o se preocupando com mais nada O UDP tem um overhead m nimo sendo cada pacote composto por um cabe alho e por dados do utilizador A este pacote d se o nome de datagrama Por n o ser orientado conex o podem se enviar datagramas em qualquer instante no tempo sem ser necess rio avisar o destino negociar uma liga o ou preparar seja o que for previamente Ao contr rio do TCP os datagramas UDP tem as suas fronteiras bem definidas ou seja se um terminal enviar um datagrama com um determinado conte do ser recebido no destino apenas um datagrama contendo o mesmo conte do ou eventualmente o datagrama perde se e n o se recebe nada n o havendo ao n vel da camada de transporte segmenta o de mensagens na origem ou fus o de datagramas no destino Apesar do UDP ser um protocolo n o fi vel a taxa de falhas bastante reduzida na Internet sendo no entanto mais alta para redes sem fios onde mais facilmente ocorrem colis es e interfer ncias Todos os mecanismos de controlo de congest o confirma es de entregas transac es etc s o da responsabilidade do programador s necessitando de serem implementadas aquela
111. o pacote de som a reproduzir antes de o poderem tocar revelou se necess rio ter dois players dispon veis em simult neo no cliente O player um mecanismo inerente da MMAPI Mobile Media API 12 que permite reproduzir udio e v deo de forma n o bloqueante para a aplica o onde se insere Desde a sua cria o at ser terminado um player passa por 5 estados distintos Quando criado encontra se no estado UNREALIZED A invoca o do m todo realize faz com que este passe para o estado REALIZED e re na a informa o necess ria para poder adquirir o udio ou v deo a reproduzir Ao invocar o m todo prefetch o player passa para o estado PREFETCHED onde pode ter de adquirir recursos exclusivos passar para buffers internos o udio ou v deo a reproduzir e realizar outras tarefas de inicializa o que consomem tempo Assim que o player se encontre neste estado pode come ar a reproduzir A invoca o deste m todo reduz a lat ncia de inicializa o do player ao m nimo O in cio da reprodu o realizado atrav s da invoca o do m todo start que provoca a transi o para o estado STARTED Este m todo retorna assim que a reprodu o tiver in cio sendo esta realizada em paralelo com o processo que lhe deu origem A reprodu o terminar automaticamente quando o fim do udio ou do v deo for alcan ado e o player transitar para o estado CLOSED Neste ltimo estado o player j libertou a maioria dos recursos utilizados
112. o programa que observa e interage com o servidor O protocolo de VNC bastante simples e baseia se numa nica primitiva gr fica Colocar um rect ngulo de pixeis na posi o X Y especificada O servidor envia rect ngulos de dimens es reduzidas para o cliente correspondentes a por es do seu ambiente de trabalho Sendo que na sua forma mais simples o protocolo de VNC pode ocupar muita largura de banda v rios m todos foram criados para reduzir o overhead da comunica o Por exemplo existem v rios tipos de codifica es dos dados podendo a escolha do tipo a utilizar ser negociado entre o cliente e o servidor no in cio de uma sess o O tipo de codifica o mais simples e que suportado por todos os clientes e servidores a codifica o Raw Sec o A 5 5 1 onde todos os pixeis s o enviados sem serem codificados num varrimento em linha da esquerda para a direita Depois de todo o ambiente de trabalho original ser transferido apenas as por es deste que sofrerem altera es s o de novo enviadas para o cliente Esta codifica o funciona bem se apenas pequenas por es do ambiente de trabalho sofrerem altera es como sendo o ponteiro do rato a deslocar se ou algo a ser escrito no ecr no entanto a exig ncia de largura de banda torna se bastante elevada se um n mero consider vel de pixeis sofrerem altera es ao mesmo tempo como sendo quando se est a visualizar um v deo em modo ecr completo Por omi
113. o tempo que este leva a inicializar a reprodu o da amostra de udio apesar de indeterminada tamb m na ordem das poucas dezenas de milissegundos tornando se por vezes impercept vel Para reduzir a percep o do sil ncio entre amostras utilizam se pacotes de som de 4 segundos pois menos percept vel um sil ncio de poucos milissegundos de 4 em 4 segundos do que esse mesmo sil ncio de 2 em 2 segundos ou de 1 em 1 segundo Apesar de amostras de dimens o superior reduzirem ainda mais este efeito apresentam no entanto contrariedades Nomeadamente aumentam a diferen a entre o instante de tempo em que o som ocorre no servidor e o instante em que este reproduzido no cliente lag sendo a recep o descodifica o dos pacotes de som e a prepara o dos players tamb m mais demorada IV 3 2 2 1 Diferen as entre a solu o em TCP e a solu o em UDP Na solu o em TCP todo o c digo que implementa o som encontra se numa s thread sendo que esta fica inicialmente espera de receber 44 bytes de cabe alho WAVE do servidor para poder criar os buffer s necess rios ao seu correcto funcionamento Seguidamente a thread entra num ciclo 37 composto por 4 etapas que podem ser interpretados no diagrama de blocos apresentado na Figura IV 12 Recebe pacote de som e descomprime o se estiver comprimido Prepara player 1 e reproduz amostra de som se o player 2 j tiver terminado Recebe pacote de som e descomprime o s
114. oS denial of service Deste modo se a porta utilizada pelo VNC for a 5900 a 5901 estar reservada para estabelecer sess es de transfer ncia de som e a 5902 estar associada ao servidor de eco Utilizar um servidor de eco sobre TCP que ao contr rio dos de UDP recebem os segmentos em buffers fazem a sua reconstru o enviam uma confirma o origem e s depois fazem o eco da mensagem Existe assim um atraso de reconstru o aleat rio entre o instante em que a mensagem recebida no servidor de eco e o instante em que verdadeiramente realizado o seu eco Este facto poderia ser considerado como uma estimativa do tempo que o cliente e servidor demoram efectivamente a trocar segmentos considerando que toda a aplica o funciona sobre sockets TCP e por consequente sofre deste atraso No entanto esta alternativa n o se revelou simples de implementar pois quando se efectua uma liga o a um socket TCP num porto conhecido gerado um novo socket num porto aleat rio devolvido pela chamada de sistema accept e a comunica o efectua se atrav s deste Como a maioria dos PC s a que se pretende aceder encontram se por detr s de um comutador necess rio configurar neste os portos utilizados para comunica o e redireccion los para o PC NAT Como o pedido de liga o efectuado num porto conhecido mas a comunica o em si efectuada atrav s do socket criado especificamente pelo sistema operativo num porto aleat rio pa
115. ocolo de entrada iN Pul ccccccccecceceeeeeenneceeeeeeeeeecececeecaeaeeceeeeeeesencceeeeeeeeeeeeueceensnnseeeeeeess 67 A 3 Representa o de um pixel cecccccesssceeeeeecceeeeeeseeeeeeeaeceeeeeeeaeeeseaaaeeeeeaaaaeeeaaeeeessaaeaeseeeeeaeeneaas 67 A4 Exiens es ao protocolo suas sc amena cool E qu ENO QE Seatac te feio SS na RACE Leoa san 68 A 5 Mensagens de Protocolo rec reeataseanaaaneaaaaanaaa nana aaa aaa nannanaaaa 68 A 5 1 Mensagens de handshaking iniCial cccccccccssccssssssseeeeseeeesececensasaaesesessesssnnnessseseeseseeess 69 A 5 2 Tipos de seguran a e a aa a ae a a a a a a a ar a nana aaa na naa aaa a a 71 A 5 3 Mensagens do cliente para o SCLVICON 1 cccccccccscssssssssseeeeeeeesecsecnsaanaesssseseesanenesseeseseeeseees 72 A 5 4 Mensagens do servidor para o CHONtC cccccccceccesstssteeeceeeeeeececesaaaaesessssesssnnnessseseeseserees 75 Ad CodificacOe csuus asno aa kissin aaa a es ana DN GRU NDA aaa Ra RT Re dada ea assa 76 A 5 6 Pseudo Codifica ES isinai iina on iasdan don nad nied anda contas donde bicelles 78 Anexo B Manual de Utiliza o User Guide ss sesseerrieeeeenaaseereeneeasaanna 79 BI VIEW Sasetassiismalo tee erent a e qua ete oh deer latent a op ceed hl ede E a iss a 80 Bi2 SOVON eaaet a aaa iet dado papers tonita so alten a aea e a a aa Raia a Dono p te de exenete eta A 86 Anexo C Algoritmos de compress o e desc
116. ode call key enter cancel key backspace change mode The options accessible when the connection is established are the following Log Change Mode Mouse Special Keys Options Enter Text Refresh Stats The Change Mode option lets you select the desired mode and allows you to zoom in or zoom out the display You can also change modes using the key and zoom in and out using the 3 and 9 keys while in the navigation mode G Navigation zoom IN O O Type O Zoom OUT The Mouse option gives you a list of all the mouse events you can use Call mouse sends the pointer to the center of the screen A first selection of Click amp Hold L B presses the left mouse button and leave it that way and a second selection of the same event un presses the left button You can use this for instance to select a phrase in a text or to move a window across the desktop The other events available are self explanatory le Call Mouse Left Click o Right Click o Double Click o Click amp Hold L B O O 0 Scroll Up Scroll Down 82 The Special Keys option lets you see a list of keys that are not accessible from most of the mobile phones keyboards The list is not exhaustive but the main keys are present Combinations of keys can be made for instance you could press Ctrl which remains pressed then press Shift which also remains pressed and then pres
117. oder ser de 99 88 se o pacote for enviado por inteiro de 99 4 se for dividido em 8 segmentos ou inferior no caso de ser repartido em segmentos menores Estes valores foram obtidos atrav s da f rmula 1 adaptada para o m todo TCP onde por cada pacote de som transfere se tamb m um pacote de 4 bytes contendo a dimens o em bytes do udio transferido Voltando a analisar a Figura V 6 o d bito da rede UMTS durante a execu o deste teste parece variar consideravelmente entre cada pacote recebido Isto pode acontecer porque de facto a rede apresenta oscila es ou ent o porque como estamos a lidar com valores reduzidos de tempo de recep o do pacote a API utilizada juntamente com o processamento efectuado pelo telem vel das v rias threads existentes na aplica o n o permitem a obten o de uma quantidade exacta para este valor pois qualquer varia o deste influ ncia bastante o valor obtido para o d bito da rede No entanto o valor m dio obtido para o d bito neste caso de 100 kbps o que at se aproxima dos 120 kbps calculados sobre a mesma rede UMTS a partir do m todo em TCP A compress o dos pacotes revela se praticamente inexistente no caso de amostras de 500 bytes o que faz com que a t cnica utilizada n o surta o efeito desejado No entanto uma situa o n o representada nestes gr ficos a da transfer ncia de sil ncio onde se consegue comprimir este tipo de pacotes para valores abaixo dos 100 bytes pe
118. odifica o Raw sem codifica o O tipo de codifica o mais simples aquele em que se envia os pixeis sem serem codificados Neste caso a informa o contida nos pixeis consiste em largura x altura valores de pixeis onde a largura e a altura s o as dimens es do rect ngulo Os valores representam simplesmente cada pixel num varrimento em linha da esquerda para a direita Todos os clientes devem suportar este tipo de codifica o ou aus ncia dela e os servidores devem apenas produzir dados nesta codifica o a menos que o cliente pe a especificamente outro tipo de codifica o 76 Numero de bytes Tipo Valor Descri o largura x altura x bytesporpixel Vector de PIXEL pixeis A 5 5 2 Codificagao CopyRect A codifica o CopyRect copia rect ngulo simples e eficiente e pode ser usada quando o cliente j tem os mesmos dados de pixel noutra parte do seu framebuffer A codifica o que enviada consiste simplesmente nas coordenadas x y de onde o cliente pode copiar o rect ngulo de pixeis do seu framebuffer Isto pode ser usado nas mais variadas situa es sendo uma das mais bvias quando por exemplo o utilizador arrasta uma janela pelo ecr Uma raz o menos bvia por exemplo para optimizar o desenhar no ecr de texto ou de outros padr es repetitivos Numero de bytes Tipo Valor Descri o 2 U16 posi o x origem 2 U16 posi o y origem A 5 5 3 Codifica
119. oftware and a value of zero represents that no sound transfer session has been initiated and a value higher then zero indicates the volume at which the sound should be played in the mobile phone Active Refresh o Local Cursor Options The Enter Text option allows the user to send text to the server It also allows pasting to the form a previously copied text from the server available in its clipboard changing it and sending it back If the user uses the Copy option in this form all the user text will be available in the server clipboard Hello world 0k Copy Paste Exit Select Cancel 84 External to the main application there s an About MIDlet where you can define Macros using a special format For instance if you want to send Hello to the server the macro should be defined as H e 1 1 o0 and if you want to send ctrl alt delete it should be defined as lt c lt a d gt a gt c All the user defined macros will be accessible through the Special Keys form The letter combos available are the following x literal d Delete a Alt m Meta c Control s Shift e Escape n newline Edit Commands a BO Abe N9 F9 No F10 A F11 B F12 AV Ap l And the commands available are the following mXXXX XXXX Cc MXXXX XXXX
120. ompress o cceceeeeeeeeeeeeeeeeeeeeeseesseeeeeeeeeeeneeeeseeeeees 89 C 1 CompressS o css reta sedes scot E oco snso Toa acted E Casa A masa din eck AEE ET 89 C 2 Descompress o s is isco s aa ssaaa seues ligue cias saia li ala ais ra T a ev aea di iara e ada REN E aE Erao 90 Anexo D Repeti es de s mbolos num ficheiro de udio ssss seems 91 Lista de Figuras Figura 1 Arquitectura da VNC assa a sena Sra pass ectee cee ag Salt a zane este eet a ei eaid eta 5 Figura 1I1 1 Esquema do servi o RDM cccceceeeeeseeeeeeeeeeeeeeeeaeeeeeeeeeeeeeeeeaeeeeesaaaeeeeeeeeeeeeeeenaeeeeeaaes 12 Figura IV 1 In cio de uma sess o VNC na aplica o original esquerda e numa vers o modificada a direita sera pentes vo Seth Petey Bede Ha Bedi eo EE pu SG eg ee 16 Figura IV 2 Teclas especia S e r ra r r er r rae r aE aae aar e ee e aea na ea en aaan 17 Figura IV 3 Formul rio para defini o de macros cceeeeceeeeneeeeeeeeeeeeeeeaeeeeesaaeeeeeteeeeeeeeenaaeeeenaaes 18 Figura IV 4 Cen rio exemplificativo de uma caracter stica da aplica o original 19 Figura IV 5 Navega o pelo ambiente de trabalho em zoom normal na aplica o original 23 Figura IV 6 Representa o dos 3 zoom s dispon veis na aplica o 24 Figura IV 7 Cabe alho de uma trama TCP erre aaaana aerea 29 Figura IV 8 Cabe alho de uma
121. onstantes durante a navega o e altera es ao factor de escala o que se pode tornar incomodo para o utilizador devido lat ncia da rede 26 IV 3 Transfer ncia de Som Para permitir um controlo pleno sobre o computador alvo e para se ter a percep o de se estar efectivamente sentado frente do PC n o apenas necess rio visualizar o seu ambiente gr fico mas tamb m essencial ouvir tudo o que se passa neste Dependendo de como o utilizador configurar o computador a ser controlado este pode permitir que os clientes tenham acesso ao udio que vai para a placa de som sons do Windows m sica a tocar etc ou em alternativa transferir todo o udio exterior ao computador que seja capturado pelo microfone Em alguns casos pode se obter uma mistura de ambos os dispositivos de entrada sendo para isso necess rio uma placa de som que o possibilite Nas vers es actuais do VNC RealVNC TightVNC e UltraVNC o nico som que reproduzido no cliente um beep referente por exemplo a um erro que ocorra na linha de comandos Ou seja um evento no servidor despoleta o envio de uma mensagem para o cliente que por sua vez faz com que este provoque um som para informar o utilizador de que algo errado se passa Sendo que nenhuma das solu es existentes em VNC nem o pr prio protocolo RFB permite a transfer ncia de som entre o servidor e cliente apesar de ser um t pico interessante e pedido pelos utilizadores nos f runs dedic
122. orrespondente ao zoom de 100 zoom normal seria menor no caso de n o estar seleccionada a op o de smooth navigation pois este apenas concentra a sec o correspondente s dimens es do ecr do telem vel e n o de todo o ambiente de trabalho no entanto isto s verdade para actualiza es parciais efectuadas na navega o neste zoom Para actualiza es integrais devido implementa o utilizada despende se o mesmo tempo a desenhar em ambos os modos Pode se ainda verificar que para a imagem de fundo utilizada que ocupa 108278 bytes no servidor foram recebidos no telem vel 227309 bytes referentes actualiza o em cerca de 30 segundos Todo este overhead deve se s codifica es utilizadas e ao formato das mensagens utilizado pelo protocolo RFB para enviar os dados referentes s actualiza es Scaling no cliente 50000 45000 40000 35000 4 Sem smooth nav dura o ms 30000 Com smooth nav 25000 20000 TT TD TD TD TIA 1 2 3 4 5 6 7 8 9 10 numero da actualizagao Figura V 9 Dura o das actualiza es quando a altera o ao factor de escala realizada no telem vel No caso em que a altera o ao factor de escala efectuada no lado do servidor Figura V 10 apenas se testou o modo com a op o de smooth navigation seleccionada pois s assim se conseguem obter actualiza es integrais ao ambiente de trabalho mantendo a coer ncia com os te
123. ou a nova janela s o enviadas pelo servidor e n o todo o ambiente de trabalho Este resultado vis vel no teste efectuado na Sec o V 5 3 Figura IV 4 Cen rio exemplificativo de uma caracter stica da aplica o original 19 5 No MIDlet About na vers o disponibilizada apenas era permitido adicionar novas macros e actualizar as existentes n o sendo no entanto poss vel apag las Tendo isto em considera o foi implementada a funcionalidade que permite apagar as macros bastando para isso seleccionar a macro desejada e escolher a op o delete Foi tamb m introduzida uma limita o que n o permite que sejam criadas duas macros com o mesmo nome n o faz sentido estarem dispon veis para o utilizador duas macros sem que se possa distinguir o seu conte do 6 A funcionalidade do VNC que permite a realiza o de actualiza es incrementais n o era utilizada sendo que este deve ser um ponto a optimizar para reduzir a largura de banda utilizada Numa primeira abordagem ao t pico e tendo em considera o as altera es introduzidas pelos pontos 1 e 4 desta sec o todos os pedidos de actualiza o passaram a ser efectuados com o campo incremental diferente de zero Ou seja apenas as por es do ambiente de trabalho que foram alteradas desde a ltima actualiza o s o enviadas pelo servidor Existe a excep o da actualiza o inicial no in cio da sess o ou quando se usa explicitamente a op o de
124. putador alvo servi o local que serve para registar e autenticar o computador no segundo componente denominado RDM Online Service Este servi o local inicia uma comunica o com o servidor RDM fazendo um pedido HTTP RFC 1945 2616 para verificar se existem novas liga es pendentes Por ltimo o cliente m vel o ltimo componente instalado no telem vel Este mecanismo provid ncia um acesso seguro ao computador remoto n o sendo necess rio abrir buracos na firewall da empresa ou proceder a configura es especiais nos comutadores routers O RDM iniciado no telem vel e depois de se introduzir o nome de utilizador e palavra chave e de se seleccionar Connect a aplica o envia um pedido cifrado ao RDM Online Service Este por sua vez escuta o pedido de liga o e caso o computador alvo se encontre registado ent o estabelecida uma sess o entre o cliente e o PC RDM Online Service Communication servers a lt Encrypted stream Figura lll 1 Esquema do servi o RDM A segunda solu o TSMobiles essencialmente um cliente m vel baseado em RDP Windows Remote Desktop Protocol que permite ter acesso a qualquer Sistema Operativo Windows atrav s de 12 um telem vel bastando para tal que o computador alvo tenha o Terminal Service Windows NT 2000 2003 ou o Windows Remote Desktop Windows XP e Vista instalado A terceira solu o VNC um cliente m vel baseado em VNC
125. que permite ter acesso a plataformas Windows Macintosh ou Unix desde que contenham um servidor de VNC instalado gratuito e open source A Tabela Ill 1 4 apresenta um resumo das caracter sticas de cada uma destas ferramentas permitindo uma melhor compara o entre elas Tabela 111 1 Compara o entre as tr s solu es oferecidas pela SHAPE services 4 RDM VNC TSMobiles Microsoft Windows NT pict gle maona aS Microsoft Windows NT Microsoft Windows 2000 XP 2003 2000 XP 2003 XP Professional Linux Unix e MacOS RE ai gs ai V rios utilizadores podem V rios utilizadores V rios utilizadores aceder ao mesmo tempo ao Apenas um podem aceder ao podem aceder ao tad to e tera utilizador podera ambiente de trabalho ambiente de trabalho compuador Temalar lerdo aceder ao remoto no mesmo remoto no mesmo acesso a um ambiente de ambiente de P k E P f i trabalho virtual que n o instante e interagir com instante e interagir com estar disponivel para os trabalho em cada este este P P instante outros utilizadores necess rio um acesso directo atrav s da Internet ao porto 5900 no computador alvo A liga o a este porto deve ser concedido pela firewall proxy N o necess rio um acesso directo ao computador alvo sendo que este pode estar por detr s de uma firewall proxy necess rio um acesso directo atrav s da Internet ao porto 3389 no computador alvo A lig
126. r se menos Para tal foram armazenadas em ficheiros 40 v rias amostras de som relativamente a sil ncio captura de audio atrav s do microfone e diferentes m sicas a serem reproduzidas no computador tendo sido posteriormente criado um script para percorrer estes ficheiros e fazer a contagem individual das apar ncias de cada s mbolo Um exemplo dos ficheiros de resultados obtidos pode ser consultados no Anexo D A supress o de sil ncio um m todo que basicamente se aproveita do facto dos pacotes de udio sofrerem uma compress o maior quando se trata de momentos de sil ncio Deste modo pode se definir um limiar a partir do qual os pacotes depois de comprimidos s o interpretados como aus ncia de som ou n o Este limiar definido pelo utilizador para um maior ajuste m quina em quest o Por exemplo um pacote de 32000 bytes de udio representando sil ncio pode ser facilmente comprimido para menos de 10000 bytes com este processo Isto depende de ser udio interno que vai para a placa de som ou de ser udio capturado pelo microfone pois neste ltimo caso o ru do de fundo sempre existente n o deixa a compress o atingir os valores referidos Se tratar se de um pacote todo ele com m sica com bastante ritmo a compress o pode ser nula ou de apenas algumas centenas ou poucos milhares de bytes Deste modo se definirmos no servidor o limiar de sil ncio por exemplo nos 10000 bytes todas as amostras de udio qu
127. ra V 3 Troca de mensagens durante um inicio de sess o TCP falhado Os m todos implementados n o permitem no entanto calcular o n mero de pacotes perdidos porque n o poss vel alterar a dura o do temporizador associado aos sockets em J2ME Assim se um pacote perdido o J2ME s gera uma excep o ao fim de 150 segundos n o sendo agrad vel ao utilizador ter de esperar tanto tempo por cada pacote perdido Dado que o tempo de ida e volta varia durante a sess o n o se envia apenas um pacote mas sim 5 para se poder fazer uma m dia e apresentar ao utilizador um valor m nimo m dio e m ximo O m todo para c lculo do tempo de ida e volta sobre UDP foi utilizado para comparar com os tempos obtidos pelo m todo de TCP implementado Na Figura V 4 pode se observar um exemplo de um formul rio contendo um Ping Os resultados obtidos para o tempo de ida e volta tanto pelo m todo sobre UDP como pelo m todo sobre TCP servem tamb m para nos dar uma indica o de que a varia o de atraso na rede uma realidade No entanto pouca informa o poder ser retirada destes valores pois o n mero de amostras n o consider vel 49 1 RTT 609 2 RTT 515 3 RTT 625 4 RTT 671 5 RIT 657 RTT min avg max 515 615 671ims Ping UDP 1 RTT 360 2 RIT 516 3 RTT 547 4 RTT 328 5 RTT 437 RTT min avg max 328 437 547ms Options Figura V 4 Exemplo de um Ping efectuado durante
128. ra a sess o TCP em quest o n o possivel configurar o NAT do comutador e assim enviar dados do cliente telem vel numa rede externa para o servidor por detr s de um comutador numa rede local Deste modo optou se por n o se implementar esta solu o Outra solu o encontrada e implementada foi a de estimar o tempo de ida e volta atrav s dos cabe alhos TCP trocados durante o in cio de uma sess o Para tal o cliente envia um pacote TCP SYN para um porto predefinido no servidor que se espera n o estar a ser utilizado e o servidor responde com um pacote TCP RST o porto apenas predefinido para se poder 48 configurar a tabela NAT no comutador Utiliza se o facto de n o ser estabelecida nenhuma sess o TCP para evitar o efeito da janela de congest o que pode resultar num estado TCP TIME WAIT Dadas as limita es do J2ME associado ao MIDP1 0 CLDC1 0 utilizado n o se consegue detectar o erro no socket EONREFUSED que gerado pelo pacote TCP RST No entanto gerada uma excep o ao n o se conseguir estabelecer a liga o e quando tal acontece calcula se a diferen a entre o instante actual e o instante em que se enviou o pedido de liga o Pode se observar na Figura V 3 a troca de mensagens efectuada entre cliente e servidor durante uma tentativa de in cio de sess o falhada e como esta utilizada para o c lculo do tempo de ida e volta Cliente Servidor TCP SYN tempo de ida e volta RTT TEP RST Figu
129. ra armazenar os perfis de utilizador Esta informa o armazenada num ficheiro de texto num formato simples que se definiu Resolveu se n o a guardar no registo do Windows como acontece com as outras propriedades do VNC pois para al m desta informa o n o ter um tamanho fixo podem ser constantemente apagados e criados novos utilizadores o que tornaria a manipula o do registo e a gest o do seu conte do mais delicada e cuidada Quando se inicia a aplica o do servidor este verifica se o ficheiro 43 contendo esta informa o existe e se esta se encontra no formato adequado Caso isto n o se verifique criado um novo ficheiro contendo um utilizador base standard com algumas propriedades predefinidas que podem depois ser alteradas Caso o ficheiro exista e contenha o formato correcto as defini es dos utilizadores existentes no ficheiro s o carregadas para a mem ria na estrutura apresentada Altera es cria o de novos utilizadores ou elimina o de utilizadores existentes s o automaticamente gravadas para o ficheiro para manter uma coer ncia entre a informa o existente em mem ria e a informa o armazenada em disco para futuras utiliza es No lado do cliente foi criada uma caixa de texto que permite introduzir o nome de utilizador que se pretende utilizar No caso deste utilizador n o existir n o estar configurado no servidor este campo n o ser preenchido no telem vel ou de o servidor estar em mo
130. re o do vector que cont m os clientes com sess o estabelecida para transfer ncia de som O udio no caso do UDP enviado em pacotes de 62 5 ms 500 bytes ou menos se comprimido pois existe uma limita o dimens o m xima dos datagramas transferidos Esta limita o imposta pelos sistemas operativos Symbian existentes nos telem veis dispon veis para desenvolvimento que determinam a dimens o m xima destes a 512 bytes N o foi no entanto poss vel verificar se tal limita o existe em dispositivos suportados por outros sistemas operativos mas os testes efectuados em emuladores acedendo Internet atrav s das mesmas redes m veis n o revelaram tal limita o Nenhuma documenta o foi encontrada que suporte esta teoria mas de conhecimento geral que a implementa o da pilha de protocolo TCP IP RFC 1180 pode variar entre sistemas operativos A t tulo de exemplo a pilha de protocolo TCP IP da Microsoft descarta silenciosamente fragmentos em alguns casos Quando um datagrama UDP maior que o MTU do suporte f sico e quando n o existe nenhuma entrada ARP referente ao sistema anfitri o destino a implementa o do protocolo TCP IP da Microsoft mant m apenas o ltimo fragmento do datagrama transferido enquanto espera por uma resposta ARP O resto dos fragmentos s o descartados silenciosamente Este comportamento ocorre por predefini o e est em conformidade com o RFC referente aos requerimentos dos sistemas anfit
131. refresh para for ar uma actualiza o completa ao ecr Utilizando a op o de active refresh no telem vel que faz com que sejam efectuados pedidos de actualiza o ao servidor de 2 em 2 segundos o facto destes pedidos de actualiza o passarem a ser incrementais provocou um aumento de velocidade da aplica o Este facto era previs vel dado que a quantidade de informa o enviada pelo servidor numa actualiza o incremental bastante inferior comparativamente com uma actualiza o completa No entanto pode se sempre considerar situa es extremas como por exemplo a visualiza o de um filme em ecr completo em que as actualiza es incrementais podem ter dimens es consider veis 7 A gest o dos sistemas anfitri es hosts era pouco pr tica e n o permitia alterar as palavras chave sem ter de se eliminar o sistema anfitri o em quest o e cri lo de novo Alterou se o formul rio que permitia apenas visualizar e apagar os sistemas anfitri es existentes para poder agora tamb m alterar a palavra chave que lhes corresponde sem ter de os apagar e criar de novo Este formul rio passa ainda a permitir seleccionar o sistema anfitri o de entre os existentes e efectuar a liga o ao mesmo Antes esta lista era vis vel quando se carregava no bot o de menu do formul rio inicial misturada com os v rios comandos de log connect manage hosts exit o que a tornava inc moda quando existia mais do que um sistema anfi
132. ri es onde referido que o ARP deve guardar pelo menos um pacote 7 A raz o apontada para esta limita o far sentido se considerarmos que o MTU mais comum nas redes m veis celulares de 512 bytes e caso sejam enviados pacotes de dimens o superior estes ser o fragmentados e eventualmente descartados pelo sistema operativo do telem vel Esta limita o referente dimens o dos datagramas juntamente com o facto dos players nos telem vel utilizados Nokia 6600 e 6630 s reproduzirem pacotes de som com um m nimo de 500 ms 4000 bytes implica ao contr rio do TCP a necessidade de se efectuar buffering do som no cliente 35 IV 3 2 2 Altera es no lado do cliente No cliente do telem vel depois de estabelecida uma sess o de VNC o utilizador pode atrav s do menu de op es escolher o volume de som que deseja Um valor superior a 0 iniciar uma sess o de transfer ncia de som com o servidor caso esta ainda n o exista e o valor 0 colocar fim a esta Se o servidor n o tiver esta funcionalidade dispon vel mostrado um aviso quando se tenta estabelecer a sess o de transfer ncia de som e a aplica o prossegue sem a mesma Dado a limita o da maioria dos telem veis que apenas permitem utilizar protocolos de streaming nos seus players nativos p e Real Player desenvolvidos sobre o c digo nativo dos telem veis e dado que a API do Java utilizada requer que os player carreguem para memoria todo
133. rio para defini o de macros 3 Apenas o bot o esquerdo do rato e duplo clique eram disponibilizados ao utilizador Se este pretendesse por exemplo utilizar o bot o direito do rato para aceder s propriedades de um ficheiro ou de um documento isto n o lhe era permitido Mesmo o duplo clique nem sempre funcionava pois devido diferen a entre atrasos jitter provocado pela rede GPRS e a atrasos existentes na coloca o das mensagens RFB na rede chegava ao servidor n o um duplo clique mas dois cliques independentes Tamb m n o era permitido manter pressionado o bot o esquerdo do rato para se poder por exemplo arrastar janelas ou seleccionar texto de um documento A solu o para resolver o problema do duplo clique passou inicialmente por enviar n o dois cliques seguidos mas tr s Com este truque garantia se que em redes GPRS o efeito obtido era o do duplo clique No entanto em redes UMTS ou HSDPA era efectuado um triplo clique o que por exemplo num documento de texto serve para seleccionar um par grafo completo ao inv s de uma s palavra Posteriormente a solu o encontrada e implementada passou por substituir as sucessivas invoca es ao m todo que remete para o servidor o evento do rato existente na thread que implementa o protocolo de comunica o RFB para apenas uma invoca o de um novo m todo que garante que s o enviadas as mensagens necess rias ao servidor continuamente e sem interrup es da thread pe
134. rmitindo definir um limiar de sil ncio que possa ser utilizado A descompress o dos pacotes de udio mant m se nos 15 ms para pacotes que v m de facto comprimidos Os que s o transferidos com o tamanho original n o passam por este processo No lado do servidor a compress o dos pacotes de som praticamente instant neo Como os datagramas transferidos s o armazenados em mem ria at que sejam agrupados em n mero suficiente para criar pacotes de 4 segundos para serem reproduzidos o tempo de prepara o dos players como no caso do TCP na ordem dos 300 a 400 ms Apesar do buffering utilizado implicar que um player s comece a reproduzir udio quando j estiver dispon vel um outro pacote em mem ria para o pr ximo player come ar a prepar lo a pequena pausa existente entre as altern ncias de players mant m se n o se conseguindo tamb m neste caso obter um verdadeiro fluxo de som sem interrup es 53 w Q S 250 RSI qn 2 200 Q 150 2 Hadid 3 wl M 100 a CURE MI Mh u a peel 50 yy Ng ead N iach 1 54 107 160 213 266 319 372 425 478 531 584 637 690 743 796 849 Numero do Pacote Tamanho do pacote de som bytes 600 500 ee ee 400 300 200 100 4 0 1 57 113 169 225 281 337 393 449 505 561 617 673 729 785 841 Numero do Pacote Tempo de recep o do pacote de som ms 500 450 400 350 300 250 200 150 100 id
135. s Escape In alternative you can create a macro in the About Midlet that does the before mentioned action You can also use combinations like pressing Ctrl and then typing an a must be lower case in SMS mode to obtain the windows select all shortcut Escape BackSpace Delete Tab Windows Ctrl Olt C1 nft O 000000 An The Stats option lets you see some stats obtained during the connection like throughput bytes transferred memory used by the application This may not be of much interest to the regular user The Ping option lets you make a ping to the server in an attempt to estimate the round trip time It uses two methods and may also not be of much interest to the regular user Both the Ping and the Stats options may be removed in a future version The Refresh option sends an update request to the server for the whole desktop The Options option lets you configure a bunch of variables in the viewer The Scroll Amount and the Mouse Move amount are self explanatory The Active Refresh indicates whether or not you want the screen to be refreshed every couple of seconds The Local Cursor indicates whether or not every movement of the cursor in the viewer 83 should reflect an action by the server or if only the clicks should be sent to the server The Volume is a new feature only available if you re using the VNC server version distributed with this s
136. s caracter sticas que realmente s o necess rias Na Figura IV 8 pode se observar o formato do cabe alho de uma trama UDP 30 UDP Header 1 2 3 T2594 516 FS 1208 S 6 78 9g t2o 45 6 7 8 By 1 0 9 e Nibble Byte e aa Checksum Checksum of entire UDP segment and pseudo header parts of IP header Copyright 2004 Matt Baxter mjb fatpipe org Figura IV 8 Cabe alho de uma trama UDP IV 3 1 2 1 Vantagens do UDP O overhead do Sistema Operativo menor do que o do TCP assim como a lat ncia no arranque de uma comunica o pois n o existe estabelecimento de sess o nem o mecanismo de arranque lento slow start associado ao TCP O receptor de um pacote UDP recebe o exactamente como foi enviado com as suas fronteiras bem definidas O UDP permite transmiss es em broadcast e multicast Com o UDP pode se enviar receber dados num mesmo porto socket de v rias m quinas distintas pois o endere o de destino especificado por cada chamada ao sistema para enviar dados IV 3 1 2 2 Desvantagens do UDP N o existem garantias Um pacote pode n o ser entregue ser entregue repetidas vezes ou entregue fora de ordem O emissor n o recebe indica o nenhuma do que se passa no receptor a menos que este decida inform lo tenha sido programado para tal O UDP n o tem mecanismo de controlo de congest o A implementa o de tal mecanismo cabe ao programador caso assim o deseje Em alternativa pode
137. s alguns t picos que ficaram por abordar Poder se ia permitir ao utilizador associar as teclas do telem vel s do PC ou a combina es destas sem o utilizador ter de ficar limitado s teclas predefinidas no c digo da aplica o Por exemplo um utilizador que navegue exaustivamente por documentos de texto se calhar gostava de ter as teclas de PgUp PgDn associadas a teclas espec ficas do telem vel para evitar ter de ir constantemente ao formul rio Special Keys Este aspecto tamb m se revelaria interessante para dispositivos com teclados qwerty que normalmente disp em de teclas extras que o utilizador poderia associar s fun es que preferisse Permitir enviar e ou receber ficheiros para por exemplo permitir ao utilizador descarregar um documento importante que precisa na altura e que deixou no computador de casa ou simplesmente para transferir uma m sica que lhe apetece ouvir no momento como acontece na aplica o propriet ria RDM Actualmente as nicas coisas que s o armazenadas no telem vel s o o estado das op es dispon veis ao utilizador no formul rio inicial os endere os dos sistemas anfitri es e correspondentes palavras chave e as macros definidas no Midlet About Para isto utilizado o RMS Record Management System disponibilizado pelo J2ME que permite de formar simples armazenar dados no telem vel num ficheiro de formato especial sem o programador se ter de preocupar com o acesso mem ria ou com a
138. s cada vez mais rapidos o VNC assenta no pressuposto de ser um sistema portavel e compativel com o maior numero de maquinas possiveis e por isso a explora o deste caminho n o recomendada para servidores VNC de uso gen rico No entanto preciso ter em considera o o mbito deste trabalho e que a alternativa colocar estes aspectos negativos no lado do cliente que no nosso caso bastante mais limitado telem vel vs PC A extens o ao protocolo utilizada resume se a uma nova mensagem da parte do cliente para o servidor a pedir uma altera o ao factor de escala cujo formato se apresenta na Tabela IV 1 As mensagens utilizadas pelo protocolo RFB usam os tipos b sicos U8 U16 U32 S8 S16 S32 que representam respectivamente 8 16 e 32 bit unsigned integer e 8 16 e 32 bit signed integer Tabela IV 1 Formato da mensagem de pedido de mudan a de factor de escala Numero de bytes Tipo Valor Descri o 1 U8 F tipo da mensagem 1 U8 Factor de escala enchimento com zeros padding O servidor ao receber um pedido de altera o ao factor de escala responde com uma mensagem indicando as dimens es do ambiente de trabalho e as dimens es do novo buffer depois de efectuada a altera o como pode ser visto na Tabela IV 2 Posteriormente o servidor transfere para o cliente o desktop j afectado pelo novo factor de escala Tabela IV 2 Formato da mensagem indicando uma altera o ao factor de e
139. scala Numero de bytes Tipo Valor Descri o 1 U8 F tipo da mensagem 1 enchimento com zeros padding 2 U16 largura do desktop 2 U16 altura do desktop 2 U16 largura do buffer 2 U16 altura do buffer 2 enchimento com zeros padding Durante o desenvolvimento da aplica o e medida que se foram realizando testes mesma verificou se que os telem veis dispon veis n o suportavam aceder a ambientes de trabalho com dimens es consider veis pois a aplica o encerrava se autonomamente por falta de mem ria Visto que a quantidade de mem ria dispon vel na maioria dos telem veis bastante limitada e como a navega o mais fluida pelo ambiente de trabalho implica o armazenamento de todo o ambiente de trabalho na mem ria do dispositivo dependendo do modelo de telem vel utilizado e da resolu o do ambiente de trabalho era simples conceber uma combina o destes factores em que o telem vel acusasse falta de mem ria Dado que actualmente cada vez mais os computadores pessoais apresentam resolu es maiores para acompanhar o aumento do tamanho dos monitores tornou se indispens vel deixar de parte a ideia inicial de ter um s m todo de navega o melhorado mas que requer mais mem ria revelando se necess rio encontrar uma alternativa mais abrangente ao mesmo 25 ou permitir ao utilizador escolher o m todo a utilizar de acordo com as caracteristicas das maquinas em quest o
140. se optar pelo uso do DCCP Datagram Congestion Control Protocol definido no RFC 4340 O DCCP um protocolo da camada de transporte orientado mensagem como o UDP mas que providencia s aplica es mecanismos de controlo de congest o standards sem ser necess rio implementa los na camada da aplica o Os datagramas UDP s o os primeiros a serem descartados quando um comutador est com falta de mem ria 31 IV 3 1 3 Conclus es Gerais sobre TCP vs UDP Quando uma liga o de rede boa o overhead introduzido pelo TCP suficientemente diminuto para ser ignorado Quando esta liga o fraca o overhead introduzido pelo TCP significativo mas ao mesmo tempo a perda de pacotes do UDP tamb m se torna um problema s rio o que implica retransmiss es para garantir que as mensagens cheguem ao destino V rias estudos foram efectuados sobre a performance do TCP e UDP sobre as redes GPRS e UMTS sendo que alguns dos documentos resultantes destes estudos podem ser visualizados em 8 9 10 e 11 Na compara o de resultados entre o TCP e o UDP observa se que o tamanho dos pacotes influencia o desempenho do TCP sobre GPRS Para o tamanho padr o 536 bytes o TCP apresenta d bitos pr ximos dos alcan ados pelo UDP Para pacotes de 1500 bytes o d bito atingido revela se inferior ao d bito obtido pelo UDP 8 Estes resultados dependem do tipo de codifica o utilizada pela rede e pela vers o do TCP utilizada IV 3 2 Imple
141. som no servidor para n o incomodar eventuais indiv duos na proximidade do mesmo O volume de som do sistema operativo restabelecido ao valor original depois do ltimo cliente com uma liga o para transfer ncia de som terminar a sua sess o A captura de som no servidor tamb m s efectuada enquanto algum cliente se encontrar ligado com uma sess o para transfer ncia de som Como se pode perceber pela descri o anterior um cliente passa a ter uma ou duas liga es estabelecidas com o servidor sendo que uma a sess o estabelecida pelo VNC e a outra a sess o para transfer ncia de som podendo esta ltima nunca ser iniciada pelos clientes ou ent o ser iniciada e interrompida v rias vezes durante uma mesma sess o VNC IV 3 2 1 1 Diferen as entre a solu o em TCP e a solu o em UDP Na solu o em TCP quando um cliente se liga ao socket espec fico que est escuta de liga es a thread cria um novo socket num porto aleat rio com o qual estabelece a sess o de comunica o com o cliente Este novo socket guardado num vector do tipo SOCKET viewer MAX CLIENTS contendo a informa o de todos os socket s associados a clientes com sess o estabelecida Quando capturado som este depois de comprimido enviado para todos os clientes ligados utilizando se para tal a informa o contida no vector de socket s associados a clientes Juntamente com o pacote de udio s o enviados mais 4 bytes contendo a
142. ss o o VNC n o um protocolo seguro Apesar das palavras chave n o serem enviadas de forma leg vel para o utilizador comum tentativas de for a bruta para as descobrir podem ser bem sucedidas se tanto a cifra como a palavra chave cifrada forem apanhadas na rede Por esta raz o recomenda se que as palavras chave utilizadas sejam constitu das por pelo menos 8 caracteres No entanto o VNC pode funcionar sobre uma sess o SSH ou VPN o que adiciona uma camada de seguran a extra a toda a sess o Ambos os mecanismos referidos est o dispon veis para os principais sistemas operativos No VNC os servidores fornecem n o apenas dados e aplica es mas tamb m o ambiente de trabalho completo que pode ser acedido de qualquer m quina ligada Internet Para al m disso o VNC permite que um nico ambiente de trabalho seja acedido de v rios locais simultaneamente suportando a partilha de aplica es no mbito de trabalhos cooperativos Ou seja pode oferecer suporte computacional aos indiv duos que tentam resolver um problema em colabora o com outros sem que todos estejam no mesmo local ao mesmo tempo Os sistemas cooperativos permitem a comunica o de ideias a partilha de recursos e a coordena o dos esfor os de trabalho A sua meta permitir o trabalho em conjunto de forma simples e eficaz ajudando a comunicar coordenar e colaborar Um exemplo que pode ser referido o de desenvolvimento de aplica es em equipa Se os
143. ssuntos relacionados com a seguran a O mesmo n o acontece quando se pretende armazenar um ficheiro completamente independente algures na mem ria flash do telem vel porque o simples facto de se querer aceder criar e ou apagar ficheiros no terminal m vel traz problemas de seguran a especialmente quando se lida com fabricantes diferentes Muitos fabricantes produziram API s propriet rias para aceder aos ficheiros locais no telem vel no entanto em quase todos os casos de acesso a ficheiros a aplica o precisa de estar assinada signed para garantir que esta possa aceder aos mesmos Como qualquer aplica o Java um Midlet corre num caixa de areia segura e n o pode simplesmente aceder ao sistema de ficheiros ou a outra qualquer informa o privada Se o dispositivo suporta a API opcional FileConnection pode se aceder ao sistema de ficheiros no entanto esta est dispon vel por exemplo no Nokia 6630 mas n o no Nokia 6600 Por isso e como queremos uma aplica o compat vel com o maior n mero de plataformas m veis poss veis esta n o seria a solu o adequada e outra teria de ser equacionada Expandir as codifica es utilizadas pelo protocolo RFB e realizar um estudo das que melhor se adequam s plataformas m veis em termos de processamento necess rio e de tr fego gerado na rede 63 Ao nivel da implementa o do som seria bom construi la segundo os mesmos princ pios do VNC ou seja inicialmente assu
144. stemas anfitri es est tamb m protegido atrav s de uma palavra chave definida pelo utilizador Mantendo todas as caracter sticas que fazem desta aplica o compat vel com um maior n mero de plataformas m veis poss veis seria interessante introduzir a hip tese de utiliza o de mecanismos espec ficos para determinados telem veis por exemplo a utiliza o de streaming que melhorassem a performance da aplica o 64 Refer ncias 1 Tristan Richardson Virtual Network Computing IEEE Internet Computing Jan Feb 1998 2 Tristan Richardson The RFB Protocol version 3 8 PDF June 2007 3 How to realise the benefits of mobile broadband today Global System for Mobile Communications GSMA publication February 2007 4 Compara o das solu es da ShapeServices ltimo acesso em 10 08 2007 http www shapeservices com en products remote whitepaper php 5 Microsoft WAVE sound file format ltimo acesso em10 08 2007 http ccrma stanford edu C CRMA Courses 422 projects WaveFormat 6 Microsoft corporation Windows Server 2003 Remote Access Overview White Paper 1 2 March 2003 7 Microsoft INFO UDP Datagram Can Be Silently Discarded if Larger than MTU http support microsoft com kb 233401 Ultimo acesso em 10 08 2007 8 Oliveira J Kamienski C A Kelner J Sadok D An lise de Desempenho de TCP sobre GPRS em um Ambiente Fim a Fim Workshop de Comunica o Sem Fios
145. stes efectuados previamente Neste caso o nico buffer de mem ria utilizado para desenhar no ecr do telem vel o de zoom normal e por isso seria de esperar que a dura o das actualiza es fossem menores do que no caso anterior por n o se ter de reduzir no telem vel o ambiente de trabalho para os outros factores de escala No entanto isto n o se verifica e o tempo dispendido na actualiza o aproximadamente o mesmo que no caso anterior 30 segundos Conclui se assim que o processamento efectuado por parte do cliente pode ser negligenciado pelo menos no telem vel utilizado para testes Nokia 6630 com processador RISC de 32 bits a 220 MHz Um ponto a favor da altera o ao factor de escala ser efectuada no lado do servidor que as actualiza es 56 para zoom s inferiores a 100 tornam as actualiza es mais r pidas Reduzindo para metade o factor de escala obt m se uma redu o de 3 vezes para o tempo gasto na actualiza o Para uma redu o de 3 vezes do factor de escala obt m se uma redu o de 6 vezes no mesmo tempo Apesar disto implicar actualiza es para zoom s menores que 100 mais r pidas do que as obtidas quando as altera es ao factor de escala s o efectuados no telem vel neste ltimo caso uma mudan a de factor de escala n o implica um pedido de actualiza o e por consequente poupa se algum tempo neste aspecto Deste modo n o se pode eleger um modo como sendo melhor que o outro cabendo
146. t 3 E hotSymbol falso ENTAO codecRep mum0fRep Som il buf0ut currentPos numO0fRep Som i 0 s mbolo actual igual ao anterior e a 5 repeti o deste tou um lt que precisa de ser codificado SE Som i codecRep numOfRep E numOfRep 3 OU hotSymbol falso E codecRep 0 lt 7 ENTAO SE hotSymbol verdadeiro ENTAO codecRep 0 Som il currentPos numOfRep l numOfRep O SENAO numOfRep bufOut currentPos lt bufOut currentPos Som i 0 s mbolo actual igual ao anterior e o n mero de repeti es superior a 4 por isso vai contando o n mero de repeti es SE Som i codecRep 0 E num0fRep gt 3 OU hotSymbol verdadeiro ENTAO numbfRep 440 s mbolo actual diferente do anterior e houve 5 ou mais s mbolos repetidos SE Som i codecRep 0 E numO0fRep gt 3 OU hotSymbol verdadeiro ENTAO nunbfRep bufOut currentPos numOfRep copia dois bytes short currentPos 2 codecRep 0 Som i bufOut currentPos Som i numOfRep 0 hotSymbol falso f0 s mbolo actual diferente do anterior e n o houve 5 ou mais simbolos repetidos codecRep 0 Som iJl currentPos numOfRep l bufOut currentPos Som i numOfRep 0 Terminou o pacote de som a comprimir agora pode haver ou n o uma ultima compress o a fazer conforme os ltimos s mbolos tenham sido repetidos ou n o SE num0OfRep gt 3 ENTAO nu
147. t of this last text box is only taken into account if you re using the VNC server distributed with this version of the software which supports a new functionality user profiles On the lower bottom you can see some check boxes which are Shared Desktop If you want to share the server desktop with other possible viewers or not NCM Nokia Compatibility Mode If you re having problems with your old Nokia phone perhaps you should try to activate this mode SS Server Side Scaling This mode only works if you re using the VNC server distributed with this version of the software It does what the name suggests Smooth Navigation A new mode which allows for a smoother navigation through the desktops in exchange for more available memory on the mobile platforms In the right figure you can see the options accessible from the initial form The Log option lets you see the log saved during the last connection made The Connect option lets you connect to the selected host using the corresponding password It requires that the hostname text box is filled The Add Host option puts the value of the hostname text box in the address book The Address book option moves you to a form shown next where you can see the previously recorded hosts change the passwords associated with them delete them and 80 select the one you wish to connect to You can also set a master password to limit the access to this form to authori
148. to com zeros padding 16 PIXEL_FORMAT formato dos pixeis A 5 3 2 Definir as Codifica es Esta mensagem indica ao servidor os v rios tipos de codifica o no qual a informa o dos pixeis pode ser enviada A ordem dos tipos de codifica o na mensagem uma dica dada pelo cliente para a sua prefer ncia a primeira codifica o especificada a preferida No entanto o servidor pode ou n o escolher o tipo de codifica o usando esta dica Os dados dos pixeis podem ser sempre enviados no modo de codifica o Raw mesmo que este modo n o seja especificado nesta mensagem 72 Em adi o as codifica es genu nas o cliente pode sempre pedir pseudo codifica es para declarar ao servidor que suporta certos tipos de extens es ao protocolo Um servidor que n o suporte a extens o simplesmente ignora a Isto faz com que o cliente assuma que o servidor n o suporta a extens o at obter uma confirma o espec fica deste Numero de bytes Tipo Valor Descri o 1 U8 2 tipo da mensagem 1 enchimento com zeros padding 2 U16 n mero de codifica es Seguido de numero de codifica es repeti es do seguinte Numero de bytes Tipo Valor Descri o 4 32 tipo de codifica o A 5 3 3 Pedido de Actualiza o ao Framebuffer Esta mensagem notifica o servidor de que o cliente est interessado na rea do framebuffer especificada por posi o x posi o y largura e
149. trama UDP re eeaaaaaaan aerea 31 Figura IV 9 Incorpora o do mecanismo de transfer ncia de som 32 Figura IV 10 Formato de um ficheiro WAVE 5 arenas 33 Figura IV 11 Representa o temporal do funcionamento alternado dos dois players 37 Figura IV 12 Diagrama de blocos da solu o em TCP para a transfer ncia de audio 38 Figura IV 13 Diagrama de blocos da solu o em UDP para a transfer ncia de udio 39 Figura IV 14 Diagrama de mensagens da solu o em TCP lado esquerdo e da solu o em UDP AE o elo fc to EEEE EDER SERRO th a ec PR SRENEREER EI DORCR SER CEI PCR E saetencataad scpensenccasenashdeds 40 Figura IV 15 Exemplo de perfis de utilizador para acesso a aplica es distintas 42 Figura IV 16 Interface gr fico para configura o dos perfis de utilizador i 43 Figura IV 17 Estrutura de dados utilizada para armazenar os perfis de utilizador 43 Figura V 1 Exemplo de um registo capturado no in cio de uma sess o eneee 46 Figura V 2 Exemplo das estat sticas de uma sess o eee aaa eeaeeaerereeanea 47 Figura V 3 Troca de mensagens durante um in cio de sess o TCP falhado 49 Figura V 4 Exemplo de um Ping efectuado dur
150. tri o armazenado em mem ria 8 Se a aplica o ficasse bloqueada por algum erro interno que n o fosse tratado nada indicava ao utilizador que esta estava parada Para o utilizador n o ficar sem saber se o programa se encontra a funcionar ou bloqueado foi introduzida uma simples anima o de rota o no s mbolo de refresh 20 10 11 12 Simultaneamente a actualiza o da imagem vis vel no ecr do telem vel passa a ser realizada periodicamente ao longo da actualiza o ao inv s de ocorrer s no fim desta Seria interessante indicar directamente ao utilizador que ocorreu um erro e descrev lo tal como acontece na maioria dos casos mas trata se aqui de uma alternativa para lidar com erros de causa desconhecida No entanto este tipo de erros n o voltaram a ocorrer durante os testes efectuados vers o final Durante uma sess o de VNC estabelecida a op o exit fazia com que a aplica o terminasse completamente A ideia era substituir esta op o por um disconnect para n o se ter de sair da aplica o quando apenas se pode querer fechar a sess o em curso e estabelecer uma outra para outro servidor Actualmente ao se escolher a op o exit quando existe uma liga o estabelecida o programa em vez de terminar por completo volta ao formul rio inicial onde se pode efectuar uma nova liga o a outro sistema anfitri o Para terminar completamente a aplica o deve se seleccionar novamente a op o e
151. ts Oe Sie sect os ah dao aaa Eai do do Ro IN fo ats a RR ad a DGE a Me 7 11 2 GPRS atas eis ta aa A Doan at la ab da le to De CTA Si EC ts a do on SAR ad cat o Tole ala 8 11 3 UM ES EE a tts Sat ects ety EE E aN LI A CU Ma E ca C DE a RL a ast 9 1 4 HISDPA ss sis aos ato A MO GAL NOR E O La Ad ARO ROO TORO OBRA ERA SUNS ee O ARROIOS ANO NN O COLE ACRE 11 Cap tulo III An lise de Solu es Existentes ccccsssccccceeeeesesesseeeeeeeeeeeeeeeessssseneeeeeeeessenseaes 12 Cap tulo IV Novas Funcionalidades AeSCnvolVidas ccccssssccccecssssseeeeeeneanseeeeeenensaeseeseneneaseeees 16 IV 1 Melhoramentos aplica o existente cccceccccceceeeeeeecencnceeeeeeeeeeeeseeceeseeeeeeeeeeeeessessress 16 IV 2 Modos de navega o e altera es ao factor de escala see 22 IV 2 1 Altera es efectuadas cccececennnsneceeeceeeeeenecensanaeseeesesessenaaaesaaseecessssessnnnnisesseeeeeeesegs 23 IV 3 Transferencia d Somiiinvitss i ten ieee ties es ae in eee he ee a SE TOS 27 1V 3 1 TERMS VD iara isa bo CRIE DE RA a Se GR AUS CD DR AD A AT DD RONDA SSD GS EE eR 28 IV 3 2 Implementa o nessas insistir eae eee ie ee Ee nt 32 1V 3 3 Compress o de som e supress o de SIIENCIOS ccccccccecceecesensnseesssseeeeessnsnssssseeees 40 IV 4 Pertiside Utilizado 22 2 dios out tt dda Doo aa aa a S O qua te Si a E ads eee eae ae 41 Cap tulo V Ferramentas e testes de desempenho cccccccecceseeseee
152. tware dedicado a facilitar a comunica o entre os clientes de acesso remoto e os recursos na rede em que est inserido as segundas foram concebidas para controlar remotamente o computador alvo partilhando o ecr teclado e rato atrav s de uma liga o dist ncia sendo as aplica es concretizadas no servidor Deste modo a ideia consiste em desenvolver uma ferramenta para controlo remoto de PC s permitindo a um telem vel cliente aceder facilmente a um computador pessoal que se encontre ligado Internet servidor com o intuito de o controlar visualizar todo o ambiente de trabalho e escutar o udio que estiver a ser reproduzido no mesmo Para este efeito resolveu se utilizar uma arquitectura cliente servidor pela sua simplicidade e utilidade pr tica e por n o requerer a utiliza o de mais componentes alheios ao utilizador Optou se por utilizar no servidor computador a ser controlado uma aplica o de distribui o gratuita open source e multi plataforma de modo a limitar o m nimo poss vel em termos de plataformas alvo o uso da aplica o a ser desenvolvida Para este efeito foi escolhido o software VNC Virtual Network Computing 1 que um sistema de cliente ultra leve largamente difundido baseado num protocolo simples e independente da plataforma que permite atrav s da interface remota visualizar e controlar o ambiente de trabalho do computador onde instalado O seu desenho assume o m nimo
153. unk descriptor 4 The Format of concern here is big 4 WAVE which requires two A 12 sub chunks fmt and data big 4 16 little 4 2 20 little AudioFormat 2 o 22 The fmt sub chunk little 2 little Ee SampleRate 4 describes the format of y 28 the sound information in lela 3 ByteRate Si the data sub chunk little BlockAlign 2 p 34 little Bits Per Sample 2 36 big 4 5 40 The data sub chunk little Subchunkz2 Size 4 oe 2 Indicates the size ofthe little a sound information and 2 contains the raw sound data 2 a Figura IV 10 Formato de um ficheiro WAVE 5 Depois do cliente estar preparado para receber os pacotes de audio o servidor transfere todo o udio recebido da placa de som em PCM 8000 bytes por segundo mono para consumir o m nimo de largura de banda poss vel Existe ainda a possibilidade de compress o dos pacotes enviados utilizando um algoritmo de supress o de s mbolos repetidos que permite tamb m a realiza o de uma supress o de sil ncio bastante simples O contributo oferecido por estes m todos para a redu o da largura de banda utilizada pode ser observado na Sec o V 5 1 encontrando se os mesmos descritos na Sec o IV 3 3 Este tipo de compress o e supress o de sil ncio foram escolhidos para diminuir a largura de banda ocupada pela transfer ncia de som tendo em considera o que a maioria dos algoritmos existentes para este efeito s o propriet rios e 33 cons
154. w CopyRect RRE CoRRE Hextile e ZRLE Entre estes os mais usados s o o ZRLE Hextile e CopyRect pois providenciam a melhor compress o para os ambientes de trabalho t picos A 4 Extens es ao protocolo Existem v rias formas por onde se podem fazer extens es ao protocolo Novas codifica es podem ser facilmente adicionadas ao protocolo mantendo a compatibilidade com os clientes e servidores existentes pois os servidores ir o simplesmente ignorar pedidos de codifica es que n o suportem e os clientes nunca pedir o essas novas codifica es Pseudo codifica es podem ser pedidas pelos clientes para declarar ao servidor que suportam uma certa extens o ao protocolo Um servidor que n o suporte a extens o ir simplesmente ignor la o que significa que o cliente deve assumir que o servidor n o suporta a extens o em causa at receber uma confirma o espec fica deste Novos tipos de seguran a podem ser adicionados dando assim uma grande flexibilidade ao comportamento do protocolo sem sacrificar a compatibilidade existente Um cliente e servidor que acordem um novo tipo de seguran a podem efectivamente comunicar usando qualquer protocolo depois disso n o tendo de ser necessariamente o protocolo RFB Apenas as vers es de protocolo s o r gidas e n o podem ser usados n meros de vers es diferentes dos que est o definidos pela RealVNC Ltd Se o programador utilizar um n mero de vers o diferente ent o nem
155. xit no formul rio inicial A aplica o reconhecia quando no servidor era copiado algum texto para o clipboard mas essa informa o era simplesmente descartada Passou se a armazenar no cliente o texto copiado permitindo ao utilizador aceder a este e modific lo no formul rio especifico para edi o de texto e envio para o servidor Qualquer texto escrito neste formul rio pode agora tamb m ser copiado para o clipboard e esta informa o ser passada ao servidor Para obter este efeito foi necess rio implementar as mensagens do protocolo RFB correspondentes ver Anexo A sec o A 5 3 6 e A 5 4 4 Nas v rias aplica es VNC testadas descritas no Cap tulo Ill quando em modo de utiliza o do cursor se o utilizador ultrapassasse as fronteiras do ecr a imagem acess vel do ambiente de trabalho deslocava se automaticamente para ser vis vel a nova posi o do rato Isto permitia utilizar o cursor e navegar pelo ambiente de trabalho sem ter de se alternar entre o modo de utiliza o do cursor e o modo de navega o No entanto esta caracter stica n o se encontrava dispon vel na aplica o escolhida Foram efectuadas as altera es necess rias para se conseguir obter este efeito no cliente do telem vel tendo em considera o os diferentes modos de navega o e a utiliza o dos diferentes factores de escala zoom existentes Para telem veis com teclados qwerty as teclas que permitem alternar entre os modos d
156. y Words PC remote control Mobile phones Mobile cellular networks I O interface Communication protocol Java Indice Agradecimentos wiscisisccccscssccssccvecacsncieciscssesivescsccscsedsevenserscsnccceciecsescsvescsutecseriuaensersdevecteccecsescsvesesccnsseiteeds i RESUMO AP A A AE A A ii Palavras Chave A A EE A E PE ENE A EA N AAE A ii ADSUaC TET AT E E E E E A A EAE nndneda nata caanenibeniidaini aa canas iii Key Words witsccssscccciscivcscecsecctcecvesscanecszcsecinseiseivccescseccescezedacevsscduceacscsececsecctecsensezenreduczecssscseccesccredtarvesiseenss iii Lista de Figuras sisciicissicccsceeccecsssceccasesssiecniscivevecssescesceacceaiwesiseceececedeetecceseaanseaeeccitesvecteesescecccretezenevineeees vi Lista d TabelasS EE EE A EE A E N E E vii Lista de SiQlaS wscscsccsciccscctestcccceciccacccascssiecccivevevesvsscssaceactcatecatsctecteacsscstevescaasseaeteccevieestscssstecccacssersenvaees viii Capitulo I Introdu o csvcvciccccccsctinciercieciveccscsstecseeseivcscessctceccesecevsceccecsedenssvivivedsersecdeessascesdeeevsstecetees 1 1 1 IntrOdU O as aaa sor 0 2 te Sete less Sr os sete net ee Dea cele O Ss ana o DO Be toe thei Sebos 1 1 2 Enquadramento seas sss canis ossreaas atine riin a asas dan fivadesdeveuseoctscs Uta aaeei iiet 2 1 3 Estrutura do document a a a ee da a E n 6 Cap tulo II Redes M veis Celulares sacas starsssscsntasitasteieandodeninctucdsnioncanacisipuatarda desire gavinsicadandandas 7 1 1 GSM Sn a des Scen
157. za uma gest o de mem ria din mica aumentando ou diminuindo a mem ria dispon vel para a aplica o consoante as necessidades desta Verificou se no entanto que este dispositivo utilizando a mem ria inerente ao mesmo sem a utiliza o de cart es de mem ria n o suporta aceder a servidores com resolu es acima dos 1024x768 com o modo de smooth 60 navigation seleccionado O mesmo ja nao se verifica com o dispositivo HTC TyTn onde foram efectuadas liga es a servidores com resolu es at 2048x1536 utilizando todos os modos dispon veis No caso deste terminal m vel a gest o de mem ria j n o din mica e foi poss vel obter valores para a mem ria utilizada pela aplica o nos diversos modos e sobre v rias resolu es Verificou se como era esperado que a mem ria utilizada pelos buffers referentes ao zoom fifty 50 e ao zoom normal 100 com smooth navigation est directamente relacionada com a resolu o utilizada e que a mem ria ocupada pelo segundo cerca de 4 vezes superior ao primeiro Os buffers de zoom out e de zoom normal sem smooth navigation utilizam sempre a mesma quantidade de mem ria pois n o dependem da resolu o do servidor Apesar da informa o obtida atrav s dos testes efectuados resolveu se n o apresentar aqui valores espec ficos pois estes n o se revelaram representativos Para al m disso os valores adquiridos foram bastante d spares em termos de ordem de grandeza dos obtidos no
158. zed users Hosts O 1 Jplavserver Za O 1 Jplavserver Za O 2 123 123 123 1 Connect to host Change Password Update Password Delete host Set Master Pass Sair Select Cancel After choosing the Connect option you will be transported to the following form where you can see a progress bar indicating how the connection is occurring In this form you can t do much except waiting for the connection to be established choose to Exit the application or choose to see the Log option After this screen the session to the VNC server is established and the user can now view and control the remote desktop The input system remains similar to the original with a few keys added Nav mode 1 call mouse 3 zoom in 9 zoom out Direction buttons and 2 4 6 8 move the screen change mode Mouse mode T call mouse 3 scroll up 5 click 9 scroll down T press and hold left button release left button 0 right click double click call key enter cancel key backspace Direction buttons and 2 4 6 8 move the mouse change mode E By moving the mouse outside the screen you can now also navigate through the desktop using this mode 81 SMS mode call key enter cancel key backspace change mode To change between lower and upper case a new option Case appears in the main menu Type m

Thesis - Técnico Lisboa

Contents

Download Pdf Manuals

Related Search

Related Contents

Thesis - T&eacute;cnico Lisboa

Contents

Download Pdf Manuals

Related Search

Related Contents

Thesis - Técnico Lisboa