Substituindo o TightVNC por um cliente alternativo (parâmetro CONNECT)

Question

Eu estou no processo de engenharia reversa de um sistema existente em uma tentativa de substituir seu applet TightVNC existente por outra coisa (espero que NoVNC se for possível).

Até agora, aqui está o que eu sei ...

• servidor Debian
• VMs de Linux do OpenVZ dentro dele que executam aplicativos sob demanda para usuários
• Os usuários se conectam às VMs do OpenVZ por meio de parâmetros gerados (o TightVNC os usa)

Eu consegui me conectar usando o jar TightVNC Java usando parâmetros de conexão como este:

java -jar VncViewer-20070502-01.jar
    HOST myhost.com
    PORT 443
    ENCPASSWORD 234f92c02c3b128e
    CONNECT vncsession:0c5a727371e5d10e3147566e389b28c3
    DisableSSL No

Acredito que isso se conecta ao servidor usando um proxy HTTPS e, em seguida, redireciona para uma sessão específica do OpenVZ, mas não posso ter 100% de certeza sobre o processo. Eu não consigo pingar vncsession do servidor Debian ou das instâncias do OpenVZ, então não sei exatamente o que é.

Alguns desses parâmetros são abordados no TightVNC README - mas nem todos eles.

Agora mesmo estou enfrentando dois problemas ...

1. ENCPASSWORD é um parâmetro não padrão, tanto quanto eu posso dizer. Através da descompilação do jar TightVNC eu posso dizer que isso é simplesmente descriptografado de volta em texto simples, então eu não tenho idéia de qual é o propósito disso ... As senhas são geradas aleatoriamente em primeiro lugar.
2. Eu não tenho ideia de como CONNECT funciona ou como usá-lo em qualquer cliente VNC além do TightVNC. Acredito que tenha algo a ver com o roteamento de proxy.

Alguém pode me ajudar a entender esses parâmetros, especialmente o parâmetro CONNECT ? Qualquer ajuda adicional com o uso de outro cliente VNC no lugar do TightVNC seria apreciada também. Obrigada!