Protocolo Framebuffer Remoto

O Remote Framebuffer Protocol ( RFB ) é um protocolo de rede para acessar as interfaces gráficas do usuário (GUI) de outros computadores . É usado pelo VNC para transmitir o conteúdo da tela e a entrada do usuário .

Principio básico

Um servidor RFB oferece uma chamada "tela". Normalmente, um “ desktop ” ou um único programa de um ambiente gráfico de trabalho que é executado em um computador remoto ou os aplicativos associados são exibidos nele . O cliente RFB geralmente exibe este desktop na estação de trabalho do usuário, recebe as entradas do usuário ( entradas de teclado , movimentos e cliques do mouse , etc.) e as encaminha para o servidor RFB, que controla o ambiente de trabalho lá.

Visto que funciona no nível da memória gráfica orientada a bitmap ( framebuffer em inglês ), pode ser usado em qualquer sistema de janela, como Windows , Mac OS ou X11 . Os conteúdos da tela são transmitidos como bitmaps, onde normalmente apenas as respectivas alterações - em codificação adequada, veja abaixo - são transmitidas ao cliente. Existem profundidades de cor de 8, 16 e 32 bits por suporte de pixel, o cliente RFB solicita a profundidade de cor desejada e a codificação do servidor e o servidor deve ser guiado pelos desejos do cliente, se ele suportar a codificação desejada. Esse design torna possível manter os requisitos do cliente simples e, portanto, oferecer suporte ao uso de thin clients .

As conexões RFB não têm estado , de modo que interrupções de conexão ou alteração do cliente RFB são possíveis sem problemas, sem que a sessão associada seja perdida. O objetivo final do RFB e VNC é oferecer suporte ao trabalho remoto em computadores em um ambiente de trabalho uniforme.

Números de porta e desktop

Na versão Unix original do VNC, cada servidor VNC é seu próprio servidor X e representa exatamente um desktop X ( Xvnc ). O primeiro número de servidor X livre é usado por VNC por padrão. Se um servidor X local já estiver em execução na máquina, o que :0ocupa a área de trabalho X , o VNC obtém a área de trabalho :1. O número da porta TCP ocupado pelo VNC geralmente é 5901 no Unix. Alguns servidores VNC fornecem a porta 5800 ou um miniaplicativo Java com o qual a área de trabalho pode ser exibida e controlada com um navegador da web . 5900 + desktopnummer5800 + desktopnummer

Normalmente não há servidor X local em execução no Windows e Mac OS X , então o VNC ocupa a área de trabalho e, portanto, o número de porta TCP 5900. Essa porta também é usada pelo programa x11vnc do Unix , que oferece o servidor X local existente como um desktop VNC. :0:0

Detalhes do protocolo

IDs de handshake e versão

Assim que a conexão TCP é estabelecida, o servidor envia ao cliente o número da versão RFB que ele suporta, ao qual o cliente responde com o número da versão do protocolo. A versão do protocolo possui a estrutura versão principal .versão secundária . Presume-se que as versões do protocolo com a mesma versão principal sejam compatíveis entre si. O maior número de versão suportado por ambos os parceiros é considerado acordado para a conexão subsequente. No entanto, cada parceiro de comunicação é livre para encerrar a conexão após a troca da versão do protocolo, caso a versão do protocolo negociado não possa ou não deva ser usada para comunicação.

A identificação da versão é sempre uma string ASCII de 12 bytes , que termina com um caractere LineFeed . As versões mais comuns são 3.3, 3.7 e 3.8:

Alguns clientes relatam incorretamente um protocolo versão 3.5. Isso deve ser tratado como a versão 3.3 no lado do servidor.

Autenticação de cliente

Se o cliente e o servidor negociaram uma versão de RFB compatível, o servidor envia o tipo de autenticação que exige do cliente. Na especificação RFB original, dois tipos são definidos: "autenticação VNC" ou "sem autenticação". No entanto, outros tipos de autenticação foram definidos por fabricantes terceiros. O cliente decide qual dos tipos de autenticação oferecidos pelo servidor ele deseja autenticar no servidor.

inicialização

Após a autenticação bem-sucedida, o cliente envia uma mensagem “ClientInit” de 1 byte. Contém apenas um sinalizador que indica se o cliente aceita uma conexão "compartilhada", i. Isso significa que as possíveis conexões do servidor para outros clientes são permitidas ou (se o sinalizador for definido como 0) devem ser encerradas.

O servidor então envia uma mensagem "ServerInit". Ele contém o nome da área de trabalho (que geralmente é derivado do nome do computador do servidor), o tamanho da área de trabalho (em pixels) e a profundidade de cor nativa e a disposição dos pixels no lado do servidor. Os dados da imagem são transmitidos ao cliente neste formato por padrão, a menos que o cliente solicite os dados em um formato diferente que seja mais fácil para o cliente processar por meio de uma mensagem “SetPixelFormat”.

Transferência de dados

O cliente controla se e quando os dados devem ser transferidos. Ele envia a entrada local do teclado e do mouse para o servidor. Além disso, ele envia regularmente mensagens “FramebufferUpdateRequest” para o servidor, que então envia as alterações no conteúdo da tela (desde o último FramebufferUpdateRequest) para o cliente.

Na versão RFB original, os movimentos do ponteiro do mouse também eram enviados ao cliente por meio de atualizações normais do buffer de quadros. A quantidade de dados a serem transferidos é bastante elevada e, acima de tudo, as latências associadas dificultam a operação. Com o RFB versão 3.8 foi introduzida uma extensão que permite que o ponteiro do mouse seja desenhado localmente pelo cliente e apenas a aparência da seta do mouse e suas alterações (por exemplo, quando a seta do mouse se move sobre um campo de entrada e então para o Cursor I será transferido para o cliente.

Desde a versão 3.8. uma mudança no tamanho da área de trabalho será transmitida ao cliente. Em versões anteriores, o servidor tinha que encerrar a conexão com o cliente, pois o tamanho da área de trabalho só podia ser transferido para o cliente na fase de inicialização de uma conexão.

Links da web

• RFC 6143 - O protocolo Framebuffer remoto