Protocole Framebuffer distant

Le protocole RFB ( Remote Framebuffer Protocol ) est un protocole réseau permettant d'accéder aux interfaces utilisateur graphiques (GUI) d'autres ordinateurs . Il est utilisé par VNC pour transmettre le contenu de l'écran et les entrées utilisateur .

Principe de base

Un serveur RFB propose un soi-disant «écran». Habituellement, un « bureau » ou un programme unique d'un environnement de travail graphique qui s'exécute sur un ordinateur distant ou les applications associées sont affichés dessus . Le client RFB affiche généralement ce bureau sur le poste de travail de l'utilisateur, reçoit les entrées de l'utilisateur ( entrées du clavier , mouvements et clics de souris , etc.) et les transmet au serveur RFB, qui y contrôle l'environnement de travail.

Comme il fonctionne au niveau de la mémoire graphique orientée bitmap ( framebuffer en anglais ), il peut être utilisé sur n'importe quel système de fenêtre tel que Windows , Mac OS ou X11 . Le contenu de l'écran est transmis sous forme de bitmaps, de sorte que, généralement, seules les modifications respectives - dans un codage approprié, voir ci-dessous - sont transmises au client. Il existe des profondeurs de couleur de 8, 16 et 32 ​​bits par pixel. Le client RFB demande la profondeur de couleur et le codage souhaités au serveur et le serveur doit être guidé par les souhaits du client, s'il prend en charge le codage souhaité. Cette conception permet de garder les exigences pour le client simples et ainsi de prendre en charge l'utilisation de clients légers .

Les connexions RFB sont sans état , de sorte que les interruptions de connexion ou le changement du client RFB sont possibles sans aucun problème sans que la session associée ne soit perdue. Le but ultime de RFB et VNC est de prendre en charge le travail à distance sur des ordinateurs dans un environnement de travail uniforme.

Numéros de port et de bureau

Dans la version Unix originale de VNC, chaque serveur VNC est son propre serveur X et représente exactement un bureau X ( Xvnc ). Le premier numéro de serveur X gratuit est utilisé par défaut par VNC. Si un serveur X local est déjà en cours d'exécution sur la machine, qui :0occupe ainsi le bureau X , VNC obtient le bureau :1. Le numéro de port TCP occupé par VNC est généralement 5901 sous Unix. Certains serveurs VNC fournissent le port 5800 ou une applet Java avec laquelle le bureau peut être visualisé et contrôlé avec un navigateur Web . 5900 + desktopnummer5800 + desktopnummer

Il n'y a généralement pas de serveur X local fonctionnant sous Windows et Mac OS X , donc VNC occupe le bureau et donc le numéro de port TCP 5900. Ce port est également utilisé par le programme Unix x11vnc , qui propose le serveur X local existant comme bureau VNC. :0:0

Détails du protocole

Poignée de main et ID de version

Dès que la connexion TCP est établie, le serveur envoie au client le numéro de version RFB qu'il prend en charge, auquel le client répond avec son numéro de version de protocole. La version du protocole a la structure version majeure .version mineure . On suppose que les versions de protocole avec la même version majeure sont compatibles les unes avec les autres. Le numéro de version le plus grand pris en charge par les deux partenaires est considéré comme convenu pour la connexion ultérieure. Cependant, chaque partenaire de communication est libre de mettre fin à la connexion après l'échange de la version de protocole si la version de protocole négociée ne peut ou ne doit pas être utilisée pour la communication.

L'identificateur de version est toujours une chaîne ASCII de 12 octets , qui se termine par un caractère LineFeed . Les versions les plus courantes sont les 3.3, 3.7 et 3.8:

Certains clients signalent à tort une version de protocole 3.5. Cela devrait être traité comme la version 3.3 côté serveur.

Authentification du client

Si le client et le serveur ont négocié une version RFB compatible, le serveur envoie le type d'authentification qu'il requiert du client. Dans la spécification RFB originale, deux types sont définis: "authentification VNC" ou "pas d'authentification". Cependant, d'autres types d'authentification ont été définis par des fabricants tiers. Le client décide lequel des types d'authentification proposés par le serveur il souhaite s'authentifier sur le serveur.

initialisation

Une fois l'authentification réussie, le client envoie un message «ClientInit» de 1 octet. Celui-ci ne contient qu'un indicateur indiquant si le client accepte une connexion «partagée», i. Cela signifie que les connexions possibles du serveur à d'autres clients sont autorisées ou (si l'indicateur est défini sur 0) doivent être interrompues.

Le serveur envoie alors un message «ServerInit». Cela contient le nom du bureau (qui est souvent dérivé du nom de l'ordinateur du serveur), la taille du bureau (en pixels) et la profondeur de couleur native et la disposition des pixels côté serveur. Les données d'image sont transmises au client dans ce format par défaut, sauf si le client demande les données dans un format différent qui est plus facile à traiter pour le client via un message «SetPixelFormat».

Transfert de données

Le client contrôle si et quand les données doivent être transférées. Il envoie les entrées clavier et souris locales au serveur. De plus, il envoie régulièrement des messages «FramebufferUpdateRequest» au serveur, qui transmet ensuite les modifications du contenu de l'écran (depuis le dernier FramebufferUpdateRequest) au client.

Dans la version RFB originale, les mouvements du pointeur de la souris étaient également envoyés au client via des mises à jour normales du frame buffer. La quantité de données à transférer est assez élevée et, surtout, les latences associées rendent l'opération difficile. Avec la version 3.8 de RFB, une extension a été introduite qui permet au pointeur de la souris d'être dessiné localement par le client et uniquement l'apparence de la flèche de la souris et ses modifications (par exemple, lorsque la flèche de la souris se déplace sur un champ de saisie puis sur le I Le curseur sera transféré au client.

Depuis la version 3.8. une modification de la taille du bureau sera transmise au client. Dans les versions antérieures, le serveur devait mettre fin à la connexion au client, car la taille du bureau ne pouvait être transférée au client que lors de la phase d'initialisation d'une connexion.

liens web

• RFC 6143 - Le protocole Remote Framebuffer