libvnc/libvncserver

1. What this repository is

LibVNCServer is a C library project that produces two main runtime artifacts: libvncserver for implementing VNC servers and libvncclient for implementing VNC clients. The repo is organized around the RFB/VNC protocol, not around an application UI or daemon by itself.

2. Public boundary

The primary API surface is under include/rfb/. Those headers define the types and protocol-facing contracts that downstream applications use to embed VNC server/client behavior. The rest of the tree is the implementation behind that API.

3. Shared infrastructure

src/common/ contains code reused by both libraries: base64, socket helpers, authentication primitives, crypto backends, compression helpers, and utility code such as TurboJPEG and ZRLE-related helpers. This is the shared “platform layer” beneath both the server and client stacks.

4. Server-side architecture

src/libvncserver/ is the server pipeline. It owns framebuffer export, input/cut-and-paste handling, statistics, scaling, cursor handling, and the RFB handshake/session logic. Applications using the server library typically feed framebuffer updates into this layer and receive client input events back out.

5. Client-side architecture

src/libvncclient/ is the client pipeline. It owns connection setup, listening/reverse-connection support, decoding framebuffer updates, and client-side authentication/transport negotiation. A consuming app uses this library to connect to a remote RFB server and render or process updates.

6. Protocol implementation split

Both libraries implement the same VNC/RFB wire protocol, but with different responsibilities. The repo supports multiple encodings such as Raw, CopyRect, Hextile, Zlib, Tight, Ultra, ZRLE, and ZYWRLE; the server side encodes framebuffer data for transport, while the client side decodes it. The shared protocol definitions live in the public headers and are reflected in the separate encoder/decoder source files in each library.

7. Transport and security boundaries

Transport is layered underneath RFB. The project supports plain TCP RFB plus WebSockets on the server side, and encrypted RFB/WebSocket paths depending on build options. Security backends are pluggable at compile time: OpenSSL, GnuTLS, or libgcrypt/built-in crypto for different authentication and TLS capabilities. The architecture therefore has a clear “protocol above, transport/security below” split.

8. Web delivery path

The server library includes websockets.c and related decoding support to expose VNC sessions through a browser-friendly WebSocket endpoint. The webclients/ directory and bundled noVNC submodule provide the browser-side viewer assets that connect to that server endpoint. This is an integration path, not core protocol logic.

9. Optional server features

The server side also includes optional subsystems such as HTTP serving for the web client bootstrap, TightVNC file transfer support, and various framebuffer transformation helpers. These are additional capabilities layered onto the core RFB session engine rather than separate services.

10. Examples as integration references

The examples/server/ and examples/client/ trees are not part of the core library boundary; they are concrete consumer programs demonstrating how to wire framebuffer sources, input callbacks, tunneling, and viewer behavior. Architecturally, they show the intended embedding model for each library.

11. Testing and verification

test/ contains unit, integration, fuzz, and WebSocket-related tests. The presence of fuzz targets and WebSocket test data indicates that protocol parsing, encoding/decoding, and transport handling are treated as the most security-sensitive boundaries. CI, CodeQL, and fuzz workflows reinforce that this is a library with a large attack surface rather than a simple local app.

12. Build and packaging

The project is built with CMake and exports both libraries via installable package metadata (pkg-config and CMake config files). The repo also includes cross-compilation support, especially for Windows/MinGW, which matters because the architecture is intended to be embedded into many host applications across platforms.

13. How to draw the diagram

The clearest diagram is a layered one: consumer applications/examples at the top, then libvncclient and libvncserver as the two major API/runtime blocks, then a shared src/common foundation, and below that TCP/WebSocket + TLS/crypto backends feeding the RFB wire protocol. Around the core, show examples, webclients/noVNC, and tests/CI as supporting integration and validation subsystems.