vnc is a crate implementing the VNC protocol and the client state machine. There are also two crates using it:
- A fully functional VNC client based on SDL2, vnc-client;
- A buffering VNC proxy, vnc-proxy.
The VNC client has special hacks to work around the bugs in the VNC server used in QEMU (and Xen HVM).
Entirely by mistake. It worked out in the end.
I've encountered a very strange failure, wherein a Xen domU with a VNC console attached to it would not send any framebuffer updates. By the time I've finally realized that my VNC clients were fine and something was wrong with Xen, it was too late: rust-vnc was practically complete. Then I spent twice as much time perfecting the handling of keyboard layouts for some reason.
After some careful consideration of QEMU's source code (from afar), I decided to work around its bugs on the client side. That worked!
To launch the VNC client, run
cargo install vnc-client and then
To launch the VNC proxy, run
cargo install vnc-proxy and then
To use the VNC library in your project, add the following to
[dependencies] vnc = "0.4"
The vnc crate implements serialization and deserialization for all of the core VNC protocol, and a largely complete client state machine.
The rvncclient tool is a quite usable VNC client, as it implements
several extensions that cut down unnecessary data transfers; as a bonus
it can be used for education and troubleshooting, as it will output
a human-readable dump of the VNC messages if ran with
variable set to
debug. The option
the QEMU-related workarounds.
The rvncproxy tool is a proxy that sits in the middle of a VNC connection
and buffers all server-to-client packets so that the server would (almost)
never block, even the last mile to the client is very slow and/or
has high latency. The proxy also supports
Note that the proxy will strip (and warn about) authentication methods and
encodings it does not understand, since it is not possible to decode
VNC framing otherwise.
I didn't really intend to write this library at all, and as such it has some drawbacks:
- No server state machine.
- No encryption or authentication.
- No inline documentation (but the signatures and the client could be helpful already).
That said, the library was written with the full VNC protocol in mind, and it should be straightforward to extend the library to support any of the above, should a need arise.
The rvncproxy tool was written with a specific server implementation misbehavior in mind, but then it turned out that server misbehaved in a completely different way, so it's not really useful for anything.
rust-vnc is distributed under the terms of both the MIT license and the Apache License (Version 2.0).