Remote Framebuffer Protocol

In der Original-Unix-Version von VNC ist jeder VNC-Server ein eigener X-Server und stellt genau einen X-Desktop dar (Xvnc). Es wird dabei standardmäßig die erste freie X-Servernummer von VNC belegt. Falls bereits ein lokaler X-Server auf der Maschine läuft, der somit den X-Desktop :0 belegt, bekommt VNC den Desktop :1. Die von VNC belegte TCP-Portnummer ist 5900 + desktopnummer, unter Unix somit meist 5901. Einige VNC-Server stellen an Port 5800 bzw. 5800 + desktopnummer ein Java-Applet zur Verfügung, mit dem der Desktop mit einem Webbrowser betrachtet und gesteuert werden kann.

Unter Windows und Mac OS X läuft in der Regel kein lokaler X-Server, so dass VNC den Desktop :0 und somit die TCP-Portnummer 5900 belegt. Dieser Port wird ebenfalls vom Unix-Programm x11vnc benutzt, welches den bestehenden lokalen X-Server :0 als VNC-Desktop anbietet.

Sobald die TCP-Verbindung aufgebaut ist, sendet der Server die von ihm unterstützte RFB-Versionsnummer zum Client, worauf dieser mit seiner Protokollversionsnummer antwortet. Die Protokollversion hat den Aufbau hauptversion.nebenversion. Es wird davon ausgegangen, dass die Protokollversionen mit gleicher Hauptversion untereinander kompatibel sind. Die größte von beiden Partnern unterstützte Versionsnummer gilt für die nachfolgende Verbindung als vereinbart. Es steht aber jedem Kommunikationspartner frei, nach dem Austausch der Protokollversionen die Verbindung zu beenden, wenn mit der ausgehandelten Protokollversion nicht kommuniziert werden kann oder soll.

Die Versionskennung ist stets ein 12 Byte langer ASCII-String, welcher mit einem LineFeed-Zeichen abgeschlossen wird. Die gebräuchlichsten Versionen sind 3.3, 3.7 und 3.8:

Einige Clients melden fehlerhafterweise eine Protokollversion 3.5. Diese sollte serverseitig wie Version 3.3 behandelt werden.

Sofern Client und Server eine kompatible RFB-Version ausgehandelt haben, sendet der Server, welche Art von Authentifizierung er vom Client verlangt. In der originalen RFB-Spezifikation sind zwei Arten definiert: „VNC Authentifizierung“ oder „keine Authentifizierung“. Es sind aber weitere Authentifizierungsarten von Drittherstellern definiert worden. Der Client entscheidet, über welche der vom Server angebotenen Authentifizierungsarten er sich am Server authentifizieren will.

Nach erfolgreicher Authentifizierung sendet der Client eine 1 Byte große „ClientInit“-Nachricht. Diese enthält lediglich ein Flag, ob der Client eine „shared“ Verbindung akzeptiert, d. h., dass eventuelle Verbindungen des Servers zu anderen Clients erlaubt sind oder (falls das Flag auf 0 ist) beendet werden sollen.

Anschließend sendet der Server eine „ServerInit“-Nachricht. Diese enthält den Namen des Desktops (der oft aus dem Rechnernamen des Servers abgeleitet wird), die Größe des Desktops (in Pixeln) und die native Farbtiefe und Anordnung der Pixel auf Serverseite. Die Bilddaten werden standardmäßig in diesem Format zum Client übertragen, außer der Client fordert über eine „SetPixelFormat“-Nachricht die Daten in einem anderen, für den Client einfacher zu verarbeitenden Format an.

Der Client steuert, ob und wann Daten übertragen werden sollen. Er sendet die lokalen Tastatur- und Mauseingaben an den Server. Außerdem sendet er regelmäßig „FramebufferUpdateRequest“-Nachrichten an den Server, der daraufhin die Änderungen des Bildschirminhaltes (seit dem letzten FramebufferUpdateRequest) an den Client sendet.

In der ursprünglichen RFB-Version wurden auch die Bewegungen des Mauszeigers über normale FramebufferUpdates an den Client geschickt. Dabei ist die zu übertragene Datenmenge recht hoch und vor allem die damit verbundenen Latenzen erschweren die Bedienung. Mit RFB-Version 3.8 wurde eine Erweiterung eingeführt, die es erlaubt, dass der Mauszeiger vom Client lokal gezeichnet wird und vom Server lediglich das Aussehen des Mauspfeils und dessen Änderungen (z. B. wenn sich der Mauspfeil über ein Eingabefeld bewegt und dann zum I-Cursor wird) an den Client übertragen werden.

Ebenso kann seit Version 3.8. eine Änderung an der Größe des Desktops an den Client übertragen werden. Bei früheren Versionen musste der Server die Verbindung zum Client beenden, da nur in der Initialisierungsphase einer Verbindung die Größe des Desktops an den Client übertragen werden konnte.