VNC Server Protokoll verstehen

Hintergrund

Das VNC Protokoll eignet sich gut, um es auch bei Microcontrollern mit Netzwerkzugang wie z.B. den ESP32 / ESP8266 zu nutzen. Damit lassen sich Bildschirminhalte von Displays in Echtzeit übertragen, was bei der Entwicklung von Nutzen sein kann. Sogar "Headless" Anwendungen sind denkbar, also grafische Anwendungen auf dem ESP laufen lassen, der selbst kein Display hat, wo die Steuerung dann ausschließlich über VNC erfolgt.

Protokoll

Das Protokoll ist in der RFC6143 beschrieben. Die Komplexität würde ich als mittelschwer beschreiben: Also nicht ganz so einfach wie ein HTTP-Request, aber auch super komplex. Ich habe erfolgreich einen VNC Server auf TCP-Basis programmiert, mit dem der Inhalt eines kleinen Displays übertragen und manipulitert werden kann.

Während in der RFC die Details des Protokolls gut beschrieben sind, gibt es einige Dinge, die noch etwas anders beschrieben werden können.

Zwei Haupzustände der VNC Verbindung

Eine VNC Verbindung kann im wesentlichen in zwei Hauptzustände unterteilt werden:

1. Verbindungsaufbau
2. Fernsteuerung

Verbindungsaufbau

Während des Verbindungsaufbaus funktioniert das Prokoll im strengen Halbduplex (Handshake): Es folgt einer strikten Struktur und es gibt immer genau eine Anfrage und genau eine Antwort darauf. Die Nachrichten sind hier genau vorgegeben und haben daher typischerweise kein separates Header-Byte, was die Art der Nachricht vorgibt.

Für eine Verbindung ohne Passwort-Authentifikation sieht das wie folgt aus und kann recht simpel "hart" kodiert werden:

1. Client baut TCP Verbindung zum Server aus, Server nimmt diese an.
2. Server sendet "RFB 003.008\n" - das ist die derzeit typische Protokollversion.
3. Client antwortet ebenfalls mit "RFB 003.008\n" - und bestätigt damit, das er diese Protkollversion akzeptiert.
4. Server sendet 0x01 0x01 - Er sagt damit, dass er nur den Security Handshake "None" unterstützt, also gar keine Authentifikation. Natürlich könnte man hier auch komplexere Handshakes erlauben, der Einfachheit halber soll das aber hier genügen.
5. Client antwortet mit 0x01 - Er sagt damit, dass er den Security Handshake "None" akzeptiert.
6. Server sendet 0x00 0x00 0x00 0x00 - Er sagt damit, dass der Security Handshake erfolgreich war und er die Verbindung akzeptiert.
7. Client sendet nun genau ein Byte, entweder 0x00 oder 0x01. Bei einer 0x00 wünscht er eine exlusive Verbindung zum Server - der Server sollte also bestehende Verbindungen trennen. Bei einer 0x01 braucht es nicht exlusiv zu sein. Ob 0x00 oder 0x01 ist für einfache Anwendungen unwichtig, ggf lässt der Simple-Server ja eh nur eine Verbindung zu.
8. Server sendet nun die sog. ServerInit Message: Diese enthält die Auflösung und das Farbformat des Framebuffers sowie den Namen der Verbindung. Dieses PIXEL_FORMAT ist allerdings nur eine Art maximale Empfehlung für den Client, denn dieser kann das PIXEL_FORMAT jederzeit ändern, was zumindest bei RealVNC auch häufig passiert. Statt das z.B. die Farbpixel mit 24Bit übertragen werden (typischerweise dann als 32 Bit Werte), kann der Client z.B. ein 8 Bit Farbformat anfragen, um schneller ein erstes Bild zu erhalten. Wichtig ist hier daher, dass auch bei einfachsten Implementierungen des Servers trotzdem verschiedene PIXEL_FORMAT Nachrichten richtig ausgewertet werden müssen.
9. Übergang in den Fernsteuerungsmodus: siehe nächstes Kapitel. Typischerweise kommen hier gleich mehrere Pakete hintereinander vom Client, ohne dass der Server irgendwas sendet. Bei RealVNC wurden die folgenden 3 Pakete beobachtet:
   1. SetEncodings
   2. SetPixelFormat
   3. FramebufferUpdateRequest

Fernsteuerung

Am Ende davon geht das Protokoll in den Fernsteuerungsmodus über - hier ist die Situation anders: Es gibt nun kein festes Handshake mehr, stattdessen werden verschiedene Nachrichtentypen unabhängig voneinander übertragen. So kann z.B. der Client in freier Folge Nachrichten senden, wenn er Bildschirmupdates haben möchte oder wenn er Tastatur- oder Mausereignisse hat. Der Server sendet im wesentlichen Nachrichten vom Typ FramebufferUpdate und updatet damit die Bildschirmdarstellung auf dem Client.

Im Fernsteuerungsmodus sind die Nachrichten über das erste Byte, das Type-Byte kodiert. Es gibt allerdings keine direkte Info, wie lang ein Paket ist. Damit der Server die Nachrichten auseinander nehmen kann, muss er auch für die einfachste Implementierung zumindest die folgenden Nachrichtentypen soweit parsen können, dass er die Längen richtig einliest:

Client-Server Nachrichten

Nummer	Name	Länge
0	SetPixelFormat	19 Byte
2	SetEncodings	variable Länge
3	FramebufferUpdateRequest	10 Byte
4	KeyEvent	8 Byte
5	PointerEvent	6 Byte
6	ClientCutEvent	variable Länge

Server-Client Nachrichten

Für den Server ist die Sache einfacher, es gibt zwar 4 verschiedene Nachrichten (FramebufferUpdate, SetColorMapEntries (nur bei Paletten Farbformat), Bell und ServerCutText), aber eigentlich macht FramebufferUpdate die ganze Arbeit.

Die FramebufferUpdate-Nachricht kann verschiedene rechteckige Bereiche mit neuen Bilddaten auffrischen und dazu verschiene Codierungen nutzen. Die Kodierungen werden über SetEncodings abgeglichen, aber für die Einfachstimplementierung geht immer die RAW-Kodierung, die einfach die Rohdaten ohne Kompression allerdings im jeweils aktuellen PIXEL_FORMAT überträgt.