OS PROTOCOLOS DO X:
- uso de cache baseado em hash para diminuir a quantidade de pacotes
- partes constantes desse hash especificam qual o opcode do pacote sendo
enviado
- Cada tipo de dado quase sempre tera um nivel de compactacao exclusiva
- O NX tenta diminuir ao maximo o numero de bits* de cada pacote baseando-se
no fato de que o X usa as mesmas windows IDs para varios pacotes
*IntCaches sao usados  para ateh 32bits, CharCaches para ateh 8 bits.
Normalmente essa otimizacao guarda dados de 16~32bits em ateh 1~8bits
propiciando compressao de 2:1 ateh 32:1.
- o cache eh o maior responsavel pela otimizacao dos protocolos do X

COMPRESSAO DE IMAGENS:
- Eh a que mais consome recursos de processamento
- Varios tipos de compressao sao usadas (jpeg, png, rdp, tight, zlib como
 explicado abaixo etc). Segundo a nomachine, as estatisticas mostram que 
com o uso de compressoes de imagens sem perda de qualidade chegam ateh 
20:1 para um jpeg tipico e ateh 100:1 com o uso de cache, proporcionando
um nivel relativo de ateh 2000:1
- O cache eh o maior responsavel pela otimizacao de envio de imagens
- Nem sempre o NX usara a maxima compactacao possivel. Ele analisara a banda
que foi disponibilizada e trabalhara em cima dela
- Compactacoes de protocolos RDP e RFB sao esperados de 2:1 ateh 10:1, porem
eh necessario usar os clientes nx da nomachines, de codigo fechado.

STREAMING DE IMAGEM:
- Compactacao esperada de ateh 20:1 atraves de jpeg
- Nao oferece bom fluxo de interacao abaixo de 1mBps
- Com uma conexao de 56kBps, por exemplo, sao esperados 4 segundos
para a atualizacao de uma imagem que tenha 256kB; Diminuir a
banda na configuracao do proxy nao necessariamente eh a melhor opcao para o
proxy, pois embora compactacao e cache tentem agilizar o processo, streaming
de imagem possui a menor prioridade do NX e podera trazer consumo de memoria
e CPU que podem acabar tornando o refresh na tela do cliente mais lento
- Como essa compressao usa muitos recursos de processamento e quebra das
imagens em pequenos pacotes para envio, ele nao tem prioridade sobre os dados
enviados pelo X (janelas e outros), causando ainda mais lentidao nessestreaming
- Importante: Alem das imagens nao terem prioridade na otimizacao dos dados,
foram definidas penalizacoes aos clientes X que usarem grande quantidade de
requests para imagens
- O padrao de otimizacao de imagens nas sessoes do NX eh o JPEG, porem PNG 
e ZLIB para bitmaps sao alternativas. Para as janelas do X baseadas em
bitmaps, o NX tenta armazenar as informacoes originais do X para trabalhar com
textos e imagens menores do que um grande bitmap final, pois o protocolo do X
tem boa otimizacao (cache+compressao)
 
DADOS NAO ESPECIFICADOS:
- Eh o que mais consome memória RAM/swap
- Uso da ZLIB* quando uma compressao nao foi especificada para determinado
tipo de dado (esperado ateh 4:1)
*grande quantidade de cpu serah usado; TODOS os dados compactados pela
ZLIB serao armazenados em cache** para otimizacao do fluxo da rede
**Sao armazenados compactados para evitar consumo de recursos da memoria,
porem consumira recursos da CPU da mesma maneira na medida em que esse cache
for requisitado (descompressao on-the-fly)
- Importante: O uso da ZLIB nao garante bom desempenho para o NX e eh usado 
raramente, principalmente quando nao ha outro metodo para o dado esperado. Eh
discutivel se o uso da ZLIB eh bom ou nao para o NX. A nomachine fala ateh de
30% de economia de dados sem consumo exagerado de CPU (uma vez que ela eh pouco
usada), mas considera essa estatistica tanto para links partindo de 56kbps para
ateh 100mbps (sendo que o nivel de compactacao da ZLIB diminui com uma banda
maior) e nao explica se esses 30% eh um resultado retirado do trafego total
gerado ou apenas daquilo que passa pela ZLIB. 
- Esse cache sera tambem armazenado no MessageStore

CONTROLE DE BANDA:
- Um grande problema no uso de banda sao terminais que nao estao trabalhando
porem estao com suas telas ativas consumindo banda da rede. O problema pode se
agravar quando algo estiver rodando na tela, como um screensaver
- Ha um controle especifico do NX que tenta identificar maquinas sem uso.
De acordo com a nomachine, quando essa maquina for identificada, o proxy
tentara reduzir o consumo de banda desse cliente X a um consumo constante,
porem nao minimo, apenas suficiente para nao gerar trafego que possa
atrapalhar outros terminais. Foi escolhido esse metodo porque a reducao muito
grande da banda pode deixar o terminal lento de mais para responder a um
comando do usuario. Isso garante uma resposta em ateh de um segundo por parte
do terminal casso ele passe de inativo para ativo (por exemplo, usuario volta
a usa-la). Esse terminal perdera prioridade de banda na rede enquanto for
identificado como inativo

MESSAGESTORE:
- Local que armazena o cache baseado em hash para protocolos do X, dados
compactados pela ZLIB entre outros
- Quando uma sessao NX eh terminada, os dados do MessageStore sao gravados em
disco**. Quando a mesma sessao for aberta, ele tentara restaurar o MessageStore.
Isso eh bom porque ele tentara otimizar o trafego especifico de determinado
usario, mas inutil, obviamente, se o cache nao puder ser restaurado
**explicado mais abaixo na secao de uso do disco
- A nomachine determina que, no fim da sessao, servidor e cliente fazem
um checksum desse cache e quando a sessao for reaberta ele novamente passa
pela verificacao de servidor e cliente

USO DO DISCO:
- Especialmente preparado para cache de imagens do MessageStore
- Eh necessario ativar o disk cache na sessao
- O disco sera usado apenas no login/logout para salvar/restaurar o cache
da(s) sessao(oes) anterior(es). Funciona como um histórico de cache e pode
otimizar o fluxo da rede de acordo com o uso de cada usuario.

Fontes:
http://www.nomachine.com/documents/getting-started.php
http://www.nomachine.com/documents/NX-XProtocolCompression.php
http://www.sisyphus.ru/br/srpm/Sisyphus/ltsp-client-nxsession/sources/0