Acesso Remoto computadores

Andr B. Oliveira, Csar H. Kallas, Marcelo G. Hyppolito, Rafael B. Curi CEATEC Pontifcia Universidade Catlica (PUC) Campinas RS Brazil Centro de Ci ncias E!atas" Am#ientais e Tecnol$icas
cesar%alals at $m!&net rafa#c'ri()a*oo&com&#r m$*)ppolito($mail&com

Resumo. O objetivo das tecnologias de acesso remoto a computadores prover um ambiente de trabalho remoto aos usurios. Envolve um servidor de terminais e vrios terminais que o acessam e realizam operaes atravs das entradas padro, que so encaminhadas do terminal para o servidor pelo sistema. Os resultados das aes e ibidos na inter!ace de sa"da do servidor # da mesma !orma # encaminhada ao terminal de acesso para visualizao do usurio. O presente trabalho um estudo sobre as principais tecnologias de acesso remoto a computadores. $ seguir, os principais aplicativos que implementam um protocolo de controle remoto so descritos. %o e ibidos e e plicados as arquiteturas dos sistemas, de seus usos, alm dos seus protocolos de comunicao.

. !!H " !ecure !#ell . $ome SS+ , Sec're S*ell .% &escri'(o - SS+ . 'm pro$rama e 'm protocolo de rede /'e permite administrar m0/'inas remotamente" e!ec'tando incl'sive apliativos $r0ficos" permite transferir ar/'ivos de v0rias formas diferentes e permite tam#.m encaps'lar o'tros protocolos" possi#ilitando" por e!emplo" acessar 'ma se12o 34Catrav.s de 'm t'nel se$'ro& .) Autor*+mpresa - SS+ foi desenvolvido pela empresa SS+ Comm'nications Sec'rit)" criada em 5667 para desenvolver sol'18es se$'ras de com'nica12o& ., !ite - site do SS+" onde . possvel copiar o pacote" . *ttp9::;;;&ss*&fi&

.- .un'(o Resumida - SS+ possi#ilita o acesso remoto via lin*a de comando por 's'0rios /'e ten*am o lo$in e sen*a de 'ma das contas do sistema& Este . 'm acesso completo via terminal (rede o' internet)" limitado aos privil.$ios do lo$in do 's'0rio& S'a principal vanta$em so#re o'tros protocolos" como por e!emplo o telnet . a se$'ran1a" o SS+ 'tiliza cripto$rafia e protocolo de a'tentica12o mais se$'ros& ./ .uncionamento ./. Ar0uitetura - pacote SS+ consistem de v0rios pro$ramas /'e a'!iliam na se$'ran1a do protocolo9 5&SS+< Servidor de cone!8es do protocolo SS+" deve ser e!ec'tado como root e normalmente . instalado nos ar/'ivos de inicializa12o das esta18es (rc files) mas . possvel tam#.m inici0,lo via o inetd& Como o servidor precisa calc'lar 'm par de c*ave p'#lica:c*ave pivada de 5=>? #its a cada inicializa12o" o m.todo do inetd n2o . recomendado para m0/'inas de #ai!o desempen*o& - servidor esc'ta a porta >>& >&SS+ S'#stit'to do RS+ com al$'mas mel*orias& Por e!emplo" se n2o *o'ver 'ma entrada nos ar/'ivos &r*osts" o' &s*osts" para a m0/'ina cliente" o servidor tenta a'tenticar pelo servidor de c*avers RSA o' pela sen*a& E!iste 'ma pe/'ena m'dan1a de sina!e pra os comandos remotos trocando o nome do 's'0rio& @&SA-BC4 Semel*ante ao rlo$in e assim como o rs* recai no rlo$in /'ando nen*'m comando . dado" o ss* tam#.m recai n'm s*ell cripto$rafado /'ando e!ec'tado sem 'm comando e!plcito para a m0/'ina remota& ?&SCP Semel*ante aos rpc" com a vanta$em de n2o derr'#ar a cone!2o se a eta12o remota n2o poss'ir 'ma refer ncia D m0/'ina local nos se's ar/'ivos *osts&e/'iv e &r*osts& Caso n2o o#ten*a a'toriza12o pelo &r*osts" a transfer ncia pode ser a'torizada por RSA pessoal o' pass;ord transmitido codificado&

7&SS+,EEFBE4 Berador de c*aves RSA& Cada 's'0rio pode ter as s'as prprias c*aves RSA" /'e s2o $eradas e colcadas no diretrio &ss*& Estas c*aves s2o 'tilizadas para a a'tentica12o das cone!8es por c*aves RSA& As c*aves s2o $eradas #aseadas n'ma frase sen*a" o /'e a'menta a s'a se$'ran1a em rela12o ao sistema de sen*a das esta18es 'e em m'itos casos . limitada a po'cos caracteres& ar/'ivo de sen*a $erado" ss*:identit)" deve terpermiss2o de leit'ra:escrita apena para o 's'0rio& G&SS+,ABE4T Esp.cie de servidor de c*aves RSA para 'ma se12o" normalmente deve ser e!ec'tado a partir do ar/'ivo &lo$in nas m0/'inas com lo$in te!t'al e &!session nas m0/'inas com lo$in controlado por !dm e se's e/'ivalentes& G&SHTP Cliente HTP com s'porte a com'nica12o se$'ra& G&SHTP,SER3ER Servidor HTP com s'porte a com'nica12o se$'ra& G&SS+,A<< Adiciona c*aves de a'tentifica12o <SA o' RSA ao pro$rama de a'tentifica12o& G&SS+,C-PF,C< Usado para instala12o do ar/'ivo identit)&p'# em 'ma m0/'ina remota& .1 2rotocolo SS+ . 'm protocolo para lo$in remoto se$'ro e o'tros servi1os conte!t'alizados em redes a#ertas& Esse protocolo . dividido em tr s componentes #0sicos9 I Camada de Transporte9 Prov si$ilo" inte$ridade e a'tentica12o do servidor& -pcionalmente" pode ser oferecido 'm servi1o de compress2o de dados& Essa camada $eralmente . rodada em cima de 'ma cone!2o TCP:CP" mas . possivel /'e ela seJa 'sada em cima de /'al/'er o'tro tipo de protocolo

confi0vel e orientado a cone!2o& I Protocolo de A'tentica12o9 A'tentica o 's'0rio perante o servidor& Esse protocolo necessita da camada de transporte para o se' f'ncionamento& I Protocolo de Cone!2o9 Permite a m'ltiple!a12o da cone!2o entre v0rios canais l$icos& Esse protocolo depende do protocolo de a'tentica12o& 4essa camada encontramos rec'rsos como s*ell interativo" t'nelamento de portas TCP:CP e cone!8es K55& - SS+ . #astante fle!vel no sentido de /'e os al$oritmos 'sados em 'ma cone!2o s2o ne$ociados entre o cliente e o servidor& Csso permite /'e al$oritmos fracos seJam removidos o' novos al$oritmos seJam testados sem /'e *aJa 'ma m'dan1a no protocolo& .3 Camada de 4ransporte A camada de tranporte do SS+ . 'm protocolo se$'ro de #ai!o nivel /'e fornece encripta12o" inte$ridade e a'tentica12o do servidor& -#serve /'e a/'i somente . feita a a'tentica12o do servidor" sendo /'e a a'tentica12o do 's'ario . responsa#ilidade do protocolo de a'tentica12o& -s pacotes /'e s2o rece#idos e enviados por essa camada poss'em o se$'inte formato9 Taman*o (? #)tes) Taman*o do preenc*imento (5 #)te) ConteLdo (n5 #)tes) Preenc*imento (n> #)tes) MAC (m #)tes) Taman*o9 Cndica o comprimento do pacote sem incl'ir o MAC e o prprio campo Taman*o& Taman*o N 5 O n5 O n>& Taman*o do preenc*imento N Pn>Q9 4Lmero de #)tes /'e ser2o colocados no pacote para /'e o taman*o total (sem o MAC) seJa mLltiplo de R (o' do taman*o do #loco 'sado na encriptacao)& n> n2o pode ser menor /'e ?& ConteLdo9 ConteLdo Ltil do pacote& Se al$'m al$oritmo de compress2o estiver sendo 'sado" esse campo . compactado& Preenc*imento9 Pn>Q #)tes aleatrios& MAC9 Cdi$o de a'tentica12o de mensa$em& - nLmero PmQ de #)tes varia de acordo com o al$oritmo /'e est0 sendo 'tilizado& - c0lc'lo do MAC .9 mac N MAC(%e)" noSdoSpacote TT pacoteSn2oSencriptado)" onde noSdoSpacote . 'm contador de pacotes enviados (o' rece#idos)&

.5 2rotocolo de 4roca de C#aves , Troca de strin$s de vers2o9 Aps a cone!2o ser esta#elecida" cliente e servidor trocam strin$s no formato9 USS+,protoversion,soft;are version coment0riosVrVnU& Essa strin$ . c*amada 3SS para a strin$ enviada pelo servidor e 3SC para a do cliente& A partir de ent2o" todos os dados s2o transmitidos no formato do pacote citado no item anterior& 5, 4e$ocia12o dos al$oritmos 'sados9 Am#os os lados enviam o pacote SS+SMSBSEEKC4CT a se$'ir9
#)te #)teW5GX strin$ Y strin$ Y strin$ Y strin$ Y strin$ Y strin$ Y strin$ Y strin$ Y strin$ strin$ #oolean 'int@> SS+SMSBSEEKC4CT coo%ie (#)tes aleatrios) Al$oritmos de troca de c*aves Al$oritmos de c*ave pL#lica Al$oritmos de encripta12o cliente,servidor Al$oritmos de encripta12o servidor,cliente Al$oritmos MAC cliente,servidor Al$oritmos MAC servidor,cliente Al$oritmos compress2o cliente,servidor Al$oritmos compress2o servidor,cliente Ain$'a$ens cliente,servidor Ain$'a$ens servidor,cliente firstS%e!Spac%etSfollo;s = (reservado)

-s campos em desta/'e (Y) s2o as strin$s com os nomes dos al$oritmos em ordem de prefer ncia& Aps os dois lados enviarem esse pacote" a camada de transporte decide /'al o al$oritmo /'e ser0 'sado no protocolo em cada 'm dos campos& - al$oritmo 'sado . o primeiro /'e o cliente poss'ir /'e o servidor s'porte& >& Protocolo de troca de c*aves& A sada dessa etapa . 'm se$redo compartil*ado E e o res'ltado + de 'm *as*& Esse *as* . 'sado como identificador de secao e como parte dos dados assinados pelo servidor para ele se a'tenticar perante o cliente& - protocolo de troca de c*aves padr2o do SS+ . o diffie,*ellman, $ro'p5,s*a5 e!plicado a se$'ir9 >&5 Cliente9 >&5&5 $era K randZmico >&5&> envia #)te mpint SS+SMSBSEEK<+SC4CT e N ($[! mod p)

-nde $N> e p o se$'inte primo(5>= #its)9 HHHHHHHHHHHHHHHHC6=H<AA>>5GRC>@?C?CGG>RBR=<C5C<5 >6=>?E=RRAG\CC\?=>=BBEAG@B5@6B>>75?A=R\6RE@?=?<<

EH6756B@C<@A?@5B@=>B=AG<H>7H5?@\?HE5@7G<G<75C>?7 E?R7B7\GG>7E\ECGH??C?>E6AG@\E<GB=BHH7CBGH?=GB\E< EE@RGBHB7AR66HA7AE6H>?55\C?B5HEG?6>RGG75ECEG7@R5 >&>& Servidor9 >&>&5 $era F randZmico >&>&> calc'la9 I f N $ ) mod p I E N e ) mod p I + N S+A,5(3SC TT 3SS TT CSC TT CSS TT ESS TT e TT f TT E) -nde 3SC" 3SS s2o as strin$s de vers2o] CSC e CSS os conteLdos dos pacotes SS+SMSBSEEKC4CT] e ESS a c*ave pL#lica do servidor& >&>&@ $era S N assinat'ra so#re + 'sando a c*ave privada >&>&? envia9 #)te SS+SMSBSEEK<+SREPAF strin$ ESS (c*ave p'#lica) mpint f strin$ S Assinat'ra so#re + >&@ Cliente9 >&@&5 3erifica se ESS . realmente a c*ave pL#lica do servidor" podendo ser feito 'ma #'sca em 'm *istrico de cone!8es& Caso esse passo n2o seJa e!ec'tado corretamente" o protocolo est0 s'Jeito ao ata/'e man,in, t*e,middle& >&@&> Calc'la9 I E N f % mod p I + N S+A,5(3SC TT 3SS TT CSC TT CSS TT ESS TT e TT f TT E) >&@&> 3erifica S com ESS @& Efetiva12o do 'so de novas c*aves com os al$oritmos ne$ociados& Cada lado da cone!2o envia a se$'inte mensa$em )te # S SS+SMSBS4E^EEF

A partir de ent2o" todos os pacotes enviados s2o encriptados de acordo com o al$oritmo ne$ociado& . 6 Ree7ecu'(o da 4roca de C#aves _ recomend0vel /'e as c*aves de sess2o seJam trocadas a cada 5B# de dados transmitidos o' de *ora em *ora& Para efet'ar essa troca #asta /'e 'm dos lados mande 'm pacote do tipo SS+SMSBSEEKC4CT& Csso for1a a e!ec'12o dos passos 5 ao @ da troca de c*aves& - Cdentificador da sess2o . o P+Q da primeira troca de c*ave" e ele mant m o se' valor at. o t.rmino da cone!2o&

8etores de 9niciali:a'(o e C#aves de !e'(o

-s vetores de inicializacao e c*aves de sessao para os al$oritmos de encripta12o e MACs s2o criados da se$'inte forma9 cliente , servidor 3C C*ave do MAC +AS+(E TT + TT UAU TT C<) +AS+(E TT + TT UEU TT C<) C*ave de Encripta12o +AS+(E TT + TT UCU TT C<) servidor , cliente +AS+(E TT + TT UBU TT C<) +AS+(E TT + TT U<U TT C<) +AS+(E TT + TT UHU TT C<)

P+AS+Q a/'i . o al$oritmo 'tilizado na troca de c*aves ne$ociada& 4o caso do diffie,*ellman,$ro'p5,s*a5 por e!emplo" +AS+ . o S+A5& . % Re0uisi'(o de !ervi'os Aps o protocolo terminar a troca de c*aves e rece#er o pacote SS+SMSBS4E^EEFS" o sistema pode tomar v0rios r'mos" onde o caso mais com'm . a a'tentica12o do 's'0rio& Para isso" deve,se re/'isitar 'm servi1o atrav.s do se$'inte pacote9 #)te strin$ pacote9 #)te strin$ SS+SMSBSSER3CCESACCEPT 4ome do servi1o SS+SMSBSSER3CCESRE`UE ST 4ome do servi1o

Se o servidor recon*ecer esse servi1o" ele deve retornar o pr!imo

Se o servidor rec'sar o pedido" o cliente deve rece#er SS+SMSBS<CSC-44ECT e em se$'ida ser desconectado& -#s&9 Para o caso da a'tentica12o" nome do servi1o . Pss*,'sera't*Q& . , Al;oritmos A se$'ir temos a ta#ela com os al$oritmos padronizados /'e foram definidos no protocolo de transporte do SS+& Como citado anteriormente" o'tros al$oritmos podem ser acrescentados nessa lista& Basta 'tilizar nomes diferente dos citados a se$'ir" pois estes s2o reservados para o protocolo& Compress2o Encripta12o none" zli# @des,c#c"#lo;fis*,c#c" t;ofis*>7G,c#c"t;ofis*," t;ofis*56>,c#c" t;ofis*5>R,c#c" aes>7G,c#c"

MAC Troca de C*aves Al$oritmos de c*ave pL#lica

aes56>,c#c" aes5>R,c#c" serpent>7G,c#c" serpent56>,c#c" serpent5>R,c#c" arcfo'r" idea,c#c" cast5>R,c#c" none *mac,s*a5" *mac,s*a5,6G" *mac,md7" *mac,md7, 6G" none diffie,*ellman,$ro'p5,s*a5 ss*,dss" ss*,rsa" !7=6v@,si$n,rsa" !7=6v@,si$n,dss" sp%i,si$n,rsa" sp%i,si$n,dss" p$p,si$n,rsa" p$p,si$n, dss

. - 2rotocolo de Autentica'(o A/'i s2o e!ec'tados os procedimentos relativos a a'tentica12o do 's'0rio& _ ass'mido /'e a camada de transporte J0 est0 provendo inte$ridade e si$ilo na com'nica12o& Para ocorrer a a'tentica12o" o cliente deve enviar a se$'inte mensa$em9 #)te strin$ strin$ strin$ a e!tra a SS+SMSBSUSERAUT+SRE `UEST 'ser name 4ome do servi1o 4ome do m.todo

- nome do servi1o especifica /'al o servi1o /'e ser0 iniciado aps a a'tentica1ao& Se o servi1o n2o estiver disponvel" o servidor ir0 desconectar o cliente& - m.todo . o nome do procedimento 'sado para a a'tentica12o& - servidor pode responder de d'as formas9 A'tentica12o confirmada9 #)te SS+SMSBSUSERAUT+SSUC CESS A'tentica12o fal*o'9 #)te SS+SMSBSUSERAUT+SHACA URE strin$ M.todos disponveis #oolean S'cesso parcial -nde s'cesso parcial indica /'e o m.todo de a'tentica12o aceito' o 's'0rio" mas o servidor n2o aceito' essa a'tentica12o& Um e!emplo de m.todo de a'tentica12o . o /'e 'tiliza sen*a& pacote SS+SMSBSUSERAUT+SRE`UEST relative a ele . o se$'inte9 #)te SS+SMSBSUSERAUT+SRE` UEST

strin$ strin$ strin$ #oolean strin$

'ser name 4ome do servi1o Ppass;ordQ HAASE sen*a

Em#ora a sen*a . informada PDs clarasQ" o pacote todo . cripto$rafado (ao contr0rio do telnet" por e!emplo)" impedindo assim o vazamento da sen*a se al$'.m estiver o'vindo o tr0fe$o& servidor tam#.m pode responder com SS+SMSBSUSERAUT+SPASS^<SC+A4BERE`" informando /'e a sen*a do 's'0rio e!piro' e /'e ela deve ser trocada& Para isso" o cliente deve enviadar o se$'inte pacote9 #)te strin$ strin$ strin$ #oolean strin$ strin$ SS+SMSBSUSERAUT+SRE` UEST 'ser name 4ome do servi1o Ppass;ordQ TRUE Sen*a anti$a Sen*a nova

. / 2rotocolo de Comunica'(o Esta . aparte /'e prov e!ec'12o de commandos remotos" a#ert'ra de s*ells" t'nelamento de cone!8es TCP:CP e de cone!8es K55& Todos esses canais s2o m'ltiple!ados em 'm Lnico t'nel encriptado& - protocolo de com'nica12o tem o se' f'ncionamento #aseado em canais& Cada canal . identificado por 'm nLmero em cada 'ma das pontas& Esse nLmero pode ser diferente em cada 'm dos lados& Canais poss'em fl'!o controlado& -s dados s2o transmitidos atrav.s deles at. /'ando o espa1o disponvel em s'as Janelas se es$otar& `'ando isso ocorrer" o taman*o das Janelas deve ser incrementado com o envio de 'ma mensa$em ade/'ada& Para a#rir 'm canal na cone!2o" a pr!ima mensa$em deve ser transmitida por 'm dos lados&

#)te strin$ 'int@> 'int@> 'int@> a e!tra

SS+SMSBSC+A44EAS-PE4 Tipo do canal no do canal remetente Taman*o inicial da Janela Taman*o m0!imo dos pacotes

a - o'tro lado deve responder o pedido com 'm dos dois pacotes a se$'ir9 #)te 'int@> 'int@> 'int@> 'int@> a e!tra a #)te 'int@> 'int@> strin$ strin$ SS+SMSBSC+A44EAS-PE4SC-4HC RMATC-4 no do canal destinat0rio no do canal remetente Taman*o inicial da Janela Taman*o m0!imo dos pacotes

SS+SMSBSC+A44EAS-PE4SHACAUR E no do canal destinat0rio cdi$o do motivo Cnforma1ao adicional Ta$ de lin$'$a$em

-#serve /'e o no do canal destinat0rio dessas d'as 'ltimas mensa$ens . o nLmero do canal remetente de /'em re/'isito' a a#ert'ra do canal (SS+SMSBSC+A44EAS-PE4)& Para transferir dados pelo canal" 'tiliza,se a se$'inte mensa$em9 #)te 'int@> strin$ o' #)te 'int@> 'int@> strin$ SS+SMSBSC+A44EASEKTE4<E<S<AT A no do canal destinat0rio Tipo dos dados <ados SS+SMSBSC+A44EAS<ATA no do canal destinat0rio <ados

- taman*o disponvel da Janela de /'em rece#er os dados deve ser decrementada pelo nLmero de #)tes do campo dados" e ao se es$otar a Janela a mensa$em a se$'ir deve ser enviada pelo destinat0rio9 #)te 'int@> 'int@> SS+SMSBSC+A44EAS^C4<-^SA<bU ST no do canal destinat0rio no de #)tes incremental

Com isso a Janela disponi#iliza o nLmero de #)tes solicitado&

. 1 9mplementa'(o do Cliente A se$'ir" foi implementado 'm prottipo de 'm cliente /'e se com'nica com 'm servidor SS+& Este cliente poss'i os se$'intes rec'rsos9 I Al$oritmo de encripta12o9 @des,c#c" none I Al$oritmos MAC9 *mac,md7" *mac,s*a5 I Al$oritmo de troca de c*aves9 diffie,*ellman,$ro'p5,s*a5 I Al$oritmo de c*ave pL#lica9 ss*,dss I Protocolo de a'tentica12o9 pass;ord I Tipo de servi1o s'portado9 s*ell remoto I 3is'aliza12o de pacotes I Bot2o de ree!ec'tar troca de c*aves

Cnterface Principal - 5c #ot2o conecta o' disconecta em 'm servidor& - >c #ot2o (ree!ec'tar troca de c*aves) f'nciona da se$'inte forma9 Ao clic0,lo" novas c*aves s2o esta#elecidas& Como 'ma f'ncionalidade did0tica" os al$oritmos de encripta12o (@des,c#c e none) s2o alternados em cada nova troca" assim como os al$oritmos de MAC (*mac,md7" *mac,s*a5)& Se o servidor n2o s'portar o *mac,md7 o' o none" o cliente n2o f'ncionar0& Ao$o" n2o 'se o #ot2o de ree!ec'tar troca de c*aves se nao se con*ecer os al$oritmos s'portados pelo servidor& A lista$em /'e aparece no lado direito s2o os pacotes /'e entram e saem do aplicativo& Ao dar 'm d'plo cli/'e . possvel vis'alizar o conteLdo de cada pacote& Al$'ns e!emplos de pacotes (decriptados)9

pacote SS+SMSBSUSERAUT+SRE`UEST para a'tentica12o

pacote SS+SMSBSC+A44EAS<ATA enviando o commando PdateQ para o s*ell

res'ltado de PdateQ enviado para o s*ell9QT'e <ec 5G >@97>9>G BRST >==@Q 4a #arra de stat's s2o mostrados os al$oritmos 'tilizados para encriptar e para $erar os MACds& 4essa #arra e!iste 'm #ot2o (PEEK Stat'sQ) /'e mostra 'm Janela com os dados da sess2o (+" E" P'#&Ee) do Server)& M<7 fin$erprint da c*ave pL#lica . mostrada diretamente na #arra de stat's&

#arra de stat's com os dados da cone!2o

Janela informando E" + e a C*ave PL#lica do servidor 1.18 Recursos - SS+ necessita G MB de RAM mais o %ernel do lin'!& Este limite deve ser redimensionado para servidores de acesso dedicao" G?MB de RAM deve ser s'ficiente para al$'mas centenas de cone!8es sim'lteneas& - protocolo . a#erto" o /'e d0 a li#erdade de implementa18es especficas dele de proverem novos rec'rsos" atrav.s da 'tiliza12o de o'tros protocolos paralelamente& 1.19 Prs e Contras
2r<s Protocolo a#erto E!celente velocidade do console Contras 42o recomendao para PCs lentos 4ecessidade de se di$itar a sen*a toda vez /'e 'ma cone!2o com 'm servidor remoto for solicitada

M'lti,Plataforma Cone!2o de dados cripto$rafada entre cliente:servidor

Cpia de ar/'ivos 'sando cone!2o cripto$rafada S'porte HTP cripto$rafado& S'porte a compacta12o de dados entre cliente:servidor Controle de acesso das interfaces servidas pelo servidor SS+ S'porte a controle de acesso TCP ;rappers A'tentica12o 'sando 'm par de c*aves pL#lica:privada RSA o' <SA Al$oritmo de cripto$rafia livre de patentes S'porte a PAM S'porte as caracteres A4SC

%. $= %. $ome 4K %.% &escri'(o Servidor de Acesso D <es%tops Remotos 'sando novas sess8es do K& %.) Autor*+mpresa - 4K . desenvolvido pela empresa italiana 4oMac*ine" sendo ori$inalmente 'm prod'to pa$o (o servidor era licenciado e o cliente ficava disponvel para do;nload $rat'ito) tornando,se posteriormente completamente $rat'ito (tanto servidor como cliente $rat'tos)& %., !ite *ttp9::;;;&nomac*ine&com %.- .un'(o Resumida - 4K . 'm soft;are para acesso D <es%top Remotos& Basicamente ele permite /'e servidores Ain'! e Solaris possam ser acessados remotamente e de modo eficiente por clientes /'e podem ser PCs" T*in Clients" Poc%et PCs" entre o'tros& Cada 'm desses dispositivos cliente podem estar rodando Sess8es do ^indo;s" Ain'! e Solaris& - soft;are prov.m o acesso remoto D servidores atrav.s de da inicializa12o de sess8es do K remotas" onde s2o transmitidas as instr'18es e os pi!maps 'sados para montar a tela /'e ser0 e!i#ida no cliente& Esses dados s2o compactados 'sando 'm eficiente al$oritmo prprio e encriptados 'sando o SS+" provendo performance e se$'ran1a tanto em lin%s lentos (so#ret'do cone!8es via A<SA o' modem)

/'anto em redes locais" onde #anda n2o . pro#lema& %./ .uncionamento %./. Ar0uitetura A ar/'itet'ra do 4K . distri#'da" sendo composta de 'm s'ite de tecnolo$ias -pen So'rce" desenvolvidas para se o#ter Comp'ta12o em Rede de 'ma forma t2o a#ran$ente como" por e!emplo" os bro&sers 'eb conse$'em ter *oJe& Consiste de 'ma camada de soft;are servidor" /'e *a#ilita /'al/'er comp'tador Uni! a tra#al*ar como 'm servidor de terminais& b0 os soft;are cliente s2o disponveis para 'm por12o $rande de plataformas e Sistemas -peracionais (^indo;s" Uni!" S'n)& %./.% = >indo? !ystem@ A 4oMac*ine escol*e' constr'ir o alicerce da Ar/'itet'ra distri#'da no se' soft;are no #em con*ecido e lar$amente 'sado K ^indo; S)stem (o' simplesmente K)" o sistema $erenciamento de Janelas /'e est0 por tr0s do con*ecido PBrap*ical User CnterfacesQ do Ain'! e Uni!& Conse/'entemente" temos /'e o 'so dos protocolos de com'nica12o do K est2o presentes em s'a ar/'itet'ra& %./.) = 2rotocol Compression A empresa fa#ricante do 4K desenvolve' 'm e!cl'sivo protocolo de compress2o" #aseado no J0 con*ecido protocolo de compress2o fli#" e 'm conJ'nto de a$entes inte$rados /'e possi#ilitam rodar sess8es completas de des%top remoto" at. mesmo em formato de tela c*eia" 'sando limitadssimas lar$'ras de #anda" como ocorrem em cone!8es 'sando modem" por e!emplo& - Mecanismo de compress2o do 4K opera em tr s nveis do protocolo K9 a) Comprime o tr0fe$o da rede em v0rios sentidos" como por e!emplo" atrav.s do 'so de avan1ados m.todos de cac*in$" red'12o de perda e compress2o de ima$ens& #) Red'z o c*amado net;or% ro'nd,trip a praticamente zero" ma!imizando o t*ro'$*p't& c) Adapta12o da lar$'ra de #anda em tempo real" de acordo com as condi18es da rede& - 4K prov.m 'm protocolo de compress2o com ta!as de compress2o do protocolo K variando entre 5=95 at. 5==95& %./., R&2 e R.B 2rotocols

A acessi#ilidade do 4K n2o . restrita somente D <es%tops e Servidores Ain'!& - 4K encaps'la e trad'z no protocolo K o R<P (Remote <es%top Protocol) 'sado pela ar/'itet'ra do ^indo;s 4T:>=== Terminal Server Edition e tam#.m trad'z o RHB (Remote Hrame B'ffer)" o protocolo 'sado pelo 34C& Entretanto o mecanismo de compress2o do 4K oferece mel*ores performances /'ando roda aplica18es K nativas& R<P e RHB sess8es podem ser comprimidos n'm fator de compress2o /'e varia de >95 at. 5=95& #) Protocolos9 Como dissemos" - 4K Server 'sa protocolos em v0rios aspectos9 4a cria12o da Sess2o Remota" . iniciada remotamente 'ma nova sess2o do K ('sando" portanto" o protocolo do K)& Al.m disso . possvel $arantir 'm #om nvel de se$'ran1a na transmiss2o dos dados e isso . o#tido confi$'rando,se a ferramenta para /'e ela cripto$rafe os dados antes de serem enviados" com isso sendo feito 'sando o protocolo SS+& -'tro e!emplo de 'so de protocolos se d0 tam#.m com as sess8es de ^indo;s e de 34C& As sess8es ^indo;s e 34C s2o feitas Pt'nelando,seQ os protocolos R<P (Remote <es%top Protocol) e RHB (Remote HrameB'ffer) nativos destas ar/'itet'ras via o 4K" a'mentando,se m'ito s'a efici ncia& Al.m disso o soft;are cont.m 'ma tecnolo$ia prpria de compacta12o de dados #aseada na tecnolo$ia fli#" provendo $rande na compacta12o dos dados o /'e permite 'ma mel*or performance da aplica12o (menor cons'mo de #anda para envio dos dados)& ). Recursos - 4K prov m rec'rsos /'e at. ent2o o'tros pro$ramas de acesso D <es%tops Remotos (como o 34C" por e!emplo) n2o prov.m" como a transmiss2o de som e de ar/'ivos" #em como o 'so de aplicativos m'ltimdia" Jo$os e interatividade (c*ats" #ate,papos)& Al.m disso prov.m o acesso D #ro;sers (Cnternet)" #em a a#ert'ra de sess8es remotas dentro de sess8es remotas& ,. 2r<s e Contras (r)s* As sol'18es at'ais de comp'ta12o #aseada em servidor e rede s2o essencialmente adapta18es para sistemas /'e n2o foram proJetados para tra#al*ar em rede& Um comparativo com sol'18es #aseadas em tecnolo$ias como 34C e Rdes%top (Citri!) revela /'e estes protocolos foram implementados como contornos a 'ma defici ncia nativa no sistema operacional em se tra#al*ar com efici ncia em am#ientes de rede& 4o caso do 4K" toda ar/'itet'ra foi desen*ada tomando por #ase a comp'ta12o em Rede e aproveitando a eficiente ar/'itet'ra do sistema Uni!" recon*ecidamente mais est0veis e com mel*or perfomance& Com 4K" os #enefcios da comp'ta12o #aseada em rede (Cripto$rafia" Mo#ilidade" Compress2o de at. 5===95" MLltiplas Plataformas de Acesso) est2o ao alcance de /'al/'er 'm& Essa eficiente performance . o#servada se analisarmos" por e!emplo" /'est8es relacionadas ao se' modo de compress2o de dados&

<evido ao alto $ra' de compress2o dos mesmos /'e se o#t.m 'sando o 4K" o#servamos /'e at. mesmo novas sess8es /'e s2o a#ertas 'sando cone!8es com limita18es de #anda (discadas" por e!emplo) se comportam com e!celente performance de acesso" se comparado com o'tras tecnolo$ias concorrentes como o 34C" por e!emplo& Ao contr0rio de tecnolo$ias como o 34C" o 4K n2o fica tirando screens*ots da tela e enviando pela rede& Como o 4K a#re sess8es remotas do K e mapeia todos os pi!els da tela para ent2o comprimir esses dados" temos /'e *0 'ma red'12o no tr0fe$o $erado no envio dos dados /'e ser2o 'sados para se constr'ir a ima$em do <es%top remoto no cliente& T'do Csso permite /'e esta18es de tra#al*o consideradas o#soletas o' 'ltrapassadas possam acessar novos sistemas" empre$ando a tecnolo$ia de servidor de terminais& -'tro fator o#servado . /'e $rande parte das empresas enfrenta dific'ldades altos c'stos associados D man'ten12o e s'porte de s'as esta18es de tra#al*o" isso sem contar o alto c'sto de licenciamento& Csso faz com /'e o 4K se apresente como 'ma sol'12o #arata (pois . $rat'ita) e /'e apresenta res'ltados m'ito satisfatrios& Contras9 Por ser 'm soft;are /'e ori$inalmente era pa$o" e!iste m'ito po'ca doc'menta12o D respeito dific'ltando o entendimento de se' f'ncionamento" #em como a compreens2o de s'a ar/'itet'ra e se's componentes&

). = >indo? !ystem ). &escri'(o - K . 'm sistema de Janelas e 'm protocolo /'e prov interfaces $r0ficas" s'portado pelo Uni! e Ain'!& ).% Autor*+mpresa - K s'r$i' em 56R? no MCT" 'ma das implementa18es dele (K&or$) /'e at'almente est0 na vers2o \&5 . mantida pela f'n12o K&or$" e est0 disponvel como soft;are livre& ).) !ite ;;;&!&or$ )., .un'(o Resumida - K poss'i 'm frame;or% para am#iente $r0fico" para desen*ar e mover Janelas na tela" intera$indo com o mo'se" teclados e o'tros perif.ricos de entrada& - 's'0rio n2o tem contato direto com o K" esse contato . feito acesso a

atrav.s de pro$ramas clientes /'e dependem dele" como o E<E e Bnome& - K permite /'e Janelas (pro$ramas) /'e rodem nele possam ser e!ec'tados remotamente pela rede" por diferentes 's'0rios e telas& Essa caracterstica de cliente e servidor $arante 'm le/'e de possi#ilidades de acesso remoto& ).- Ar0uitetura - K 'sa o modelo cliente e servidor (Cl'stra12o 5)" aonde 'm servidor com'nica com v0rios pro$ramas clientes& - servidor aceita pedidos para desen*ar Janelas $r0ficas e de entrada via teclado" mo'se o' at. mesmo to'c*screen& - K pode e!i#ir Janelas do sistema local o' de sistemas de K remotos" permitindo pro$ramas clientes remotos com'ni/'em com o servidor de Janelas K local& A com'nica12o entre eles . feita atrav.s da troca de pacotes via soc%et na rede (Cl'stra12o >)& A cone!2o . esta#elecida pelo cliente" /'e envia os primeiros pacotes& - servidor responde aos pedidos do cliente com pacotes" aceitando o' n2o a cone!2o do cliente" o' at. mesmo pedindo confirma12o de acesso (controle de acesso)" assim" esta#elecida a cone!2o" ? tipos de pacotes s2o trocados via rede9

Ilustrao 1: Arquitetura do X

5& Re/'est (re/'isi12o)9 - cliente re/'isita informa18es do servidor >& Repl) (resposta)9 - servidor responde D re/'isi12o" mas nem todas re/'isi18es precisam ser respondidas&

@& Event (evento)9 - servidor envia 'm evento para o cliente" como a entrada de 'm teclado o' mo'se" movimento de 'ma Janela" etc& ?& Error (erro)9 - servidor envia 'm pacote de erro se a re/'isi12o for inv0lida& Como as re/'isi18es podem ser empil*adas" os erros podem ser $erados por re/'isi18es feitas anteriormentes& -s pacotes de re/'isi18es e respostas podem ter 'm taman*o variado" mas os pacotes de evento e error tem taman*o fi!o de @> #)tes& - servidor K prov 'm le/'e de servi1os #0sicos" para /'e o cliente possa realizar esses servi1os e o'tros mais comple!os" intera$indo com o servidor&

Ilustrao 2: Troca de mensagens

).-. Aanelas S2o interfaces $r0ficas /'e poss'i elementos como #ot8es" men's" cones" etc" componentes ade/'ados a Janelas& Um Janela s pode ser criada a partir de 'ma Janela J0 e!istente (Cl'stra12o @)" o /'e torna as Janelas fil*as de o'tras Janelas" como 'm *ierar/'ia& A Janela principal . c*amada de PJanela rootQ" /'e . a'tomaticamente criada pelo servidor" /'e nada mais . /'e a Janela em tela c*eia" atr0s de todas as Janelas&

Ilustrao 3: Arquitetura de janelas

).-.% 9dentificadores Todos dados das Janelas" incl'indo fontes 'sadas s2o armazenados no servidor& Esses o#Jetos s2o acessados pelo cliente atrav.s de 'm identificador reservado a cada o#Jetivo" no /'al o cliente J0 con*ece& Caso o cliente deseJa /'e 'ma Janela seJa criada" ele faz 'ma re/'isi12o para o servidor para criar a Janela passando 'm identificador& servidor cria a Janela e associa com esse identificador& - identificador pode ser mais 'sado mais tarde pelo cliente" para por e!emplo" escrever 'ma frase nessa Janela& Cdentificadores devem ser Lnicos no servidor" independente do cliente" . 'm identificador Lnico /'e n2o pode ser criado novamente por o'tro cliente&

).-.) AtriButos e propriedades Cada Janela tem predefinido al$'ns atri#'tos e propriedades" todos tam#.m armazenados pelo servidor e acessveis pelo cliente atrav.s de re/'isi18es& Atri#'tos s2o datas so#re as Janelas" como taman*o" posi12o" cor de f'ndo e o'tros& Propriedades s2o valores dos dados ane!ados as Janelas" contr0rio aos atri#'tos" propriedades n2o s2o pr.,identificadas pelo protocolo do servidor& Podendo ent2o" o cliente armazenar dados relevantes a ele nas propriedades das Janelas& Propriedades s2o caracterizadas por 'm nome" tipo e valor" s2o similares a vari0veis" no /'al 'ma aplica12o cliente pode criar 'ma nova e armazenar valores& Propriedades s2o associados D Janelas" d'as propriedades com o mesmo nome podem e!istir em d'as Janelas diferentes" com o mesmo nome" valor e tipo& Propriedades s2o #astante 'sadas pelos clientes e podem ser vis'alizadas com o comando !prop&

).-., +ventos Eventos s2o pacotes enviados pelo servidor para o cliente para com'nicar /'e al$'ma coisa ocorre'& - cliente pode pedir para o servidor enviar os eventos para o'tro cliente" isso facilita com'nica12o entre clientes& Por e!emplo9 /'ando 'm cliente faz 'ma re/'isi12o para sa#er o te!to /'e est0 selecionado no momento" 'm evento . enviado para o cliente /'e est0 manip'lando a Janela no momento& Al$'ns tipos de eventos s2o sempre enviados para o cliente" mas a maioria dos tipos de eventos s2o enviados somente se o cliente dei!ar claro /'e necessita deles (e!emplo9 cliente /'er ter informa18es do teclado" mas n2o do mo'se)& ).-.- =liB A maioria dos pro$ramas clientes com'nicam com o servidor atrav.s da #i#lioteca Kli#" mas e!istem m'itas o'tras #i#liotecas /'e fazem isso (Motif" Bt%" `t)" al$'mas at. 'sam a Kli# em conJ'nto para a com'nica12o&

).-./ Gerenciadores de Canelas Um $erenciador de Janelas . 'm pro$rama /'e controla a apar ncia das Janelas : elementos $r0ficos& - papel principal de 'm $erenciador de Janelas . prover 'ma interface ami$0vel e padronizada com estilos para o 's'0rio" contando tam#.m com aplica18es Lteis (e!emplo9 EUm $erenciador de Janelas . 'm pro$rama /'e controla a apar ncia das Janelas : elementos $r0ficos& - papel principal de 'm $erenciador de Janelas . prover 'ma interface ami$0vel e padronizada com estilos para o 's'0rio" contando tam#.m com aplica18es Lteis (e!emplo9 E<E" Bnome" ^indo;Ma%er)& )./ Recursos A com'nica12o do cliente com o servidor f'nciona de maneira transparente na rede" o cliente e o servidor podem f'ncionar na mesma m0/'ina o' em m0/'inas diferentes" possi#ilitando 'ma intera12o de diferentes ar/'itet'ras e sistemas operacionais" mas eles devem operar o mesmo sistema K& A com'nica12o entre eles pode f'ncionar tam#.m de maneira se$'ra" #astando cripto$rafar a cone!2o atrav.s de 'm tLnel cripto$rafado (via -penSS+)& Para iniciar 'm pro$rama remoto e esse ser e!i#ido (visto) localmente" #asta o 's'0rio m'dar o se' Pdispla)Q" apontando para 'm displa) remoto (servidor K)& E!emplo9 e!port <CSPAAFN*ost9porta

Heito isso" #asta o 's'0rio invocar o pro$rama" o cliente vai se conectar no servidor local da m0/'ina e e!i#ir a Janela $r0fica (Cl'stra12o ?)" aceitando tam#.m entrada de mo'se:teclado& - K permite /'e v0rias instancias f'ncionem com o servidor" permitindo /'e o 's'0rio inicie sess8es paralelas de am#ientes $r0ficos& _ possvel 'sar soft;ares de acesso remoto em conJ'nto com o prprio K" como por e!emplo9 34C e 4K&

Ilustrao 4: Exemplo de interao cliente e servidor

).1 2r<s e contras 2r<s

Ar/'itet'ra escal0vel Com'nica12o via rede S'porte a e!tens8es e md'los <rivers nativos >> anos de desenvolvimento S'porte a 34C" 4K

Contras
Bai!o desempen*o para intera18es r0pidas (Jo$os)

,. 8$C 34C , Comp'ta12o em rede virt'al (+irtual ,et&or- .omputing)& ,. &escri'(o

- desenvolvimento das redes de comp'tadores se de' com o s'ceesso da id.ia de disponi#ilizar acesso D rec'rsos centralizados em 'm comp'tador com alto poder de processamento" a partir de terminais simples de

#ai!o c'sto& A id.ia dos criadores do 34C era levar este conceito al.m" e disponi#ilizar ao 's'0rio n2o comente dados e aplicativos" mas 'm am#iente des%top completo /'e poderias ser acessado de /'al/'er comp'tador conectado D Cnternet& Em contraste D onda de aplica18es ;e#" ondee o foco . acesso a rec'rsos localizados em /'al/'er l'$ar do m'ndno atrav.s de 'm comp'tador pessoal" o 34C permite /'e se acesse o comp'tador pessoal de /'al/'er l'$ar do m'ndo&
,.% Autor*+mpresa

- 34C foi desenvolvido por mem#ros do -livetti g -racle Researc* Aa#s (-RA) como 'ma feramenta interna para acesso aos comp'tadores pessoais de /'al/'er infraestr't'ra comp'tacional , desde o comp'tador do escritrio at. terminais de acesso ;e#" disponveis em locais pL#licos&
,.) !ite - site do Real34C" prod'to at'almente mantido pelos a'tores do 34C ori$inal" . *ttp9::;;;&realvnc&com& ,., .un'(o Resumida - 34C . considerado 'm meio de comp'ta12o mvel" onde n2o . necess0rio carre$ar nen*'m dispositivo& Csto se d0 devido a simplicidade do protocolo" /'e torna o lado cliente do sistema 'm thin client" aplica12o pe/'ena e simples /'e consome po'cos rec'rsos de processamento e memria& Csto a#re possi#ilidades para implementa12o em plataformas des-top" dispositivos mveis e applets bava" disponi#ilizando acesso praticamente em /'al/'er l'$ar& ,.- Ar0uitetura Cl'stra12o de 'm cliente 34C rodando em 'm am#iente mvel sim'lado9

A#ai!o" 'ma il'stra12o da ar/'itet'ra do sistema 34Ch" 'ma das implementa18es do protocolo RHB& Este sistema foi escol*ido para ser e!i#ido pois s implementa as f'ncionalidades #0sicas oferecidas pelo protocolo& 3ale lem#rar /'e este dia$rama . especfico da implementa12o" e pode variar de acordo com o proJeto do so!t&are&

. .rameBuffer - !ramebu!!er . 'm dos md'los do sistema de vdeo dos comp'tadores& Como o prprio nome diz" trata,se da memria onde s2o armazenados os /'adros $erados pelo sistema de vdeo" antes de serem e!i#idos pelo

monitor de vdeo& 4os sistemas modernos" providos de f'ncionalidades $r0ficas @<" os $r0ficos s2o ori$inalmente $erados pelos so!t&ares na forma de vetores& Estes sistemas poss'em 'm hard&are o' so!t&are /'e faz a convers2o dos $r0ficos vetoriais para a forma matricial" $erando os /'adros&

2. R.B Server
- RHB %erver . o md'lo /'e implementa o protocolo RHB e . respons0vel pela troca de mensa$ens do servidor com o cliente& _ 'ma aplica12o /'e roda so#re 'm protocolo de transmiss2o confi0vel (tipo TCP)& ). Rectan;le+ncoder Este md'lo faz a leit'ra dos dados do !ramebu!!er e faz a codifica12o de acordo com 'm m.todo especificado& Este m.todo . ne$ociado entre o cliente e o servidor no momento da cone!2o" e a escol*a . #aseada em vari0veis como capacidade de processamento dos ns" varia12o do !rame e atraso da rede& ,. &esDtopControl - md'lo <es%topControl . o md'lo /'e rece#e as mensa$ens do cliente referente D entrada de 's'0rio (eventos do mo'se e teclado) e as repassa ao sistema operacional do servidor& -. R.B Client - RHB Client implementa o lado cliente do protocolo RHB" e . respons0vel por fazer a com'nica12o com md'lo RHB Server& - lado cliente tam#.m . respons0vel por analisar o estado do meio de transmiss2o e aJ'star as ta!as de at'aliza12o e m.todo de codifica12o conforme necess0rio& /. Rectan;le&ecoder H'nciona do modo oposto ao md'lo Rectan$leEncoder" 'tilizando o m.todo de codifica12o selecionado para decodificar os /'adros rece#idos do servidor e repass0,los D interface com o 's'0rio& 1. Remote&esDtop _ a interface com o 's'0rio propriamente dita& Este md'lo e!i#e os /'adros rece#idos do servidor" e repassao ao RHB Client as entradas do 's'0rio" /'e ser2o transmitidas ao servidor& ,./ 2rotocolo A tecnolo$ia do sistema 34C . 'm protocolo simples" de acesso remoto D interfaces $r0ficas& - protocolo opera no nvel do frame#'ffer" o /'e o torna independente de sistema operacional" plataformas $r0ficas e aplicativos"

proporcionando 'ma alta porta#ilidade& - protocolo opera so#re /'al/'er protocolo de transporte confi0vel" como o TCP:CP& - sistema opera so#re 'ma ar/'itet'ra cliente,servidor" onde o lado servidor (3C4 Server) fica respons0vel por enviar as m'dan1as no frame#'ffer da m0/'ina onde est0 instalado ao lado cliente (34C 3ie;er o' 34C Client)&

- 34C . 'm sistema thin client" onde a 'ni2o da simplicidade do cliente e do protocolo a#erto torna possvel implement0,lo sem dific'ldades em /'al/'er plataforma& Primitiva $r0fica Lnica - lado cliente do protocolo . #aseado em 'ma Lnica primitiva $r0fica9

<esen*e 'm reten$'lo de pi!els em 'ma dada posi12o !")& A e!trema simplicidade pode dar a impress2o de /'e o desen*o da interface . ineficiente& Mas este m.todo permite a 'tiliza12o de v0rios meios de codifica12o dos dados transmitidos" oferecendo 'ma $rande fle!i#ilidade em rela12o D vari0veis do tipo9 lar$'ra de #anda da rede" capacidade de desen*o da interface no cliente o' poder de processamento do servidor& - m.todo mais simples de codifica12o . denominado ra& encoding" onde os dados s2o simplesmente enviados da forma como s2o $erados& Esta . a codifica12o mnima re/'erida pelo protocolo" /'e deve ser implementada pelos clientes e servidores" em#ora o'tras formas de codifica12o possam ser ne$ociadas entre clientes e servidores no ato da cone!2o& <'rante a etapa inicial da cone!2o (P*ands*a%in$Q)" os dois lados da aplica12o se com'nicam para definir a codifica12o de acordo com a capacidade das m0/'inas onde est2o rodando e da lar$'ra de #anda da cone!2o entre eles& - pro#lema . /'e estas n2o s2o as Lnicas vari0veis /'e devem ser levadas em conta& A mais importante . a finalidade do 's'0rio ao 'tilizar o

sistema& Por e!emplo" a codifica12o cop/0rectangle permite /'e 'ma vez /'e 'm reten$'lo da tela ten*a sido e!i#ido e ainda resida no frame#'ffer do cliente" ele pode ser e!i#ido novamente sem /'e precise ser novamente transmitido pelo servidor (Ltil nos casos onde 'm Lnico o#Jeto se movimenta pela tela)& Para a e!i#i12o de fotos" o' o'tras ima$ens de alta defini12o" a codifica12o dos frames em bPEB seria ideal& -' para transmiss2o de vdeo o' o'tras sit'a18es /'e envolvam pi!els em movimento" poderia,se 'tilizar codifica12o MPEB& Para e!i#i12o de te!to" o cliente poderia salvar os caracteres e!i#idos para /'e possam ser ree!i#idos sem /'e s'a ima$em deva trafe$ar novamente pela rede& At'aliza18es adaptativas - mais pr!imo /'e se c*e$o' de 'ma sol'12o para o caso apresentado anteriormente (onde n2o . possvel prever /'al a codifica12o ideal /'ando n2o se sa#e /'al ser0 a 'tiliza12o) foram as at'aliza18es adaptativas& Como o prprio nome diz" o sistema pode implementar 'm al$oritmo /'e detecta padr8es na movimenta12o dos pi!els na tela" e se adapta alterando a codifica12o 'tilizada conforme o res'ltado da an0lise& - sistema pode tra#al*ar com mLltiplas codifica18es sim'ltaneamente" onde cada reten$'lo da tela pode ser transmitido codificado de forma diferente& - sistema de at'aliza18es adaptativas tam#.m rea$e a altera18es na velocidade de transmiss2o" e red'z a fre/iencia no envio de frames& Esta t.cnica implica em rece#er entradas do 's'0rio" mas envi0,las somente /'ando re/'isitado pelo cliente& Assim" se o cliente detectar o #ai!o desempen*o da cone!2o" e dimin'ir o nLmero de re/'isi18es de at'aliza12o" todas as entradas de 's'0rio /'e forem enviadas entre 'ma re/'isi12o de at'aliza12o e o'tra ser2o e!ec'tadas" mas somente o res'ltado delas ser0 e!i#ido no cliente" sem /'e seJam mostrados os frames intermedi0rios& ,.1 Recursos - protocolo RHB permite somente a transmiss2o de /'adros" sem possi#ilidades de transmiss2o de som o' ar/'ivos" o' mesmo de 'ma forma se$'ra de transmiss2o& Mas o protocolo a#erto d0 a li#erdade de implementa18es especficas dele de proverem tais rec'rsos" atrav.s da 'tiliza12o de o'tros protocolos paralelamente& Um e!emplo . o TC$*t34C" /'e permite a transmiss2o de som e ar/'ivos& At'almente" o Real34C" implementado e mantido pelos pes/'isadores da -RA (criadora do protocolo) implementa a transmiss2o de ar/'ivos& ,.3 2r<s e contras 2r<s Protocolo A#erto Cliente pe/'eno /'e pode ser e!ec'tado em Contras Uso ineficiente de rec'rsos de rede Protocolo limitado" /'e n2o permite e!tens2o de

/'al/'er tipo de dispositivo comp'tacional Cmplementa18es para todos os sistemas operacionais&

f'ncionalidades (/'al/'er e!tens2o necessita 'tiliza12o de o'tros protocolos)&

-. ReferEncias BiBlio;rFficas RCC+AR<S-4" T et al& 3irt'al 4et;or% Comp'tin$& CEEE Cnternet Comp'tin$" Cam#rid$e" n& @" p& G,5>" Jan& 566R& AUPTAE" M& Ma%in$ 34C more sec're 'sin$ SS+& 3irt'al 4et;or% Comp'tin$" 566R& <isponvel em9 *ttp9::;;;&cl&cam&ac&'%:Researc*:<TB:attarc*ive:vnc:ss*vnc&*tml& Acessado em9 =G o't& >==G& RCC+AR<S-4" T T*e RHB Protocol& @& ed& Cam#rid$e" >==7" ?@p& SS+ +ome Pa$e& <isponvel em9 *ttp9::;;;&ss*&fi:& Acessado em9 5= o't& >==G& Criando t'neis cripto$rafados com SS+& <isponvel em9 *ttp9::;;;&dicas, l&com&#r:dicas,l:>==G5=5\&p*p& Acessado em9 5= o't& >==G& Bettin$ started ;it* SS+& <isponvel em9 *ttp9::%immo&s'ominen&com:docs:ss*:& Acessado em9 57 o't& >==G& ^i%ip.dia& <isponvel em9 *ttp9::pt&;i%ipedia&or$:;i%i:SS+& Acessado em9 57 o't& >==G& - /'e . SS+& <isponvel em9 *ttp9::;;;&rnp&#r:ne;s$en:6\=R:n@,@&*tml& Acessado em9 >> o't& >==G& Flonen" T&" USS+ Protocol Arc*itect'reU" <isponvel em9 *ttp9::draft,ietf, arc*itect're,57&t!t" Acessado em9 @= o't& >==G& Flonen" T&" USS+ Connection ProtocolU" <isponvel em9 *ttp9::draft,ietf,connect, 5R&t!t" Acessado em9 @= o't& >==G& Flonen" T&" USS+ Transport Aa)er ProtocolU" <isponvel em9 *ttp9::draft,ietf, transport,5\&t!t" Acessado em9 @= o't& >==G&