Für eine Verbindung ohne Passwort-Authentifikation sieht das wie folgt aus und kann recht simpel "hart" kodiert werden:
# Client baut TCP Verbindung zum Server aus, Server nimmt diese an.
# Server sendet "RFB 003.008\n" - das ist die derzeit typische Protokollversion.
# Client antwortet ebenfalls mit "RFB 003.008\n" - und bestätigt damit, das er diese Protkollversion akzeptiert.
# 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.
# Client antwortet mit 0x01 - Er sagt damit, dass er den Security Handshake "None" akzeptiert.
# Server sendet 0x00 0x00 0x00 0x00 - Er sagt damit, dass der Security Handshake erfolgreich war und er die Verbindung akzeptiert.
# 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.
# 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.
=== Fernsteuerung ===
Am Ende davon geht das Protokoll in den Fernsteuerungsmodus über - hier ist die Situation anders: