An RFB proxy, written in go that can save and replay FBS files
Go to file
2017-08-04 23:13:28 -04:00
.idea added cmdline binaries for proxy and player 2017-07-28 17:48:22 +03:00
.vscode moved and parametrized the recorder 2017-08-03 14:30:39 +03:00
architecture some more house cleaning, updated license & docs 2017-07-15 07:52:23 +03:00
client some refactoring + better recorder 2017-08-03 01:33:09 +03:00
common some refactoring + better recorder 2017-08-03 01:33:09 +03:00
encodings some fixes 2017-07-21 16:09:27 +03:00
logger some refactoring + better recorder 2017-08-03 01:33:09 +03:00
player moved and parametrized the recorder 2017-08-03 14:30:39 +03:00
proxy moved and parametrized the recorder 2017-08-03 14:30:39 +03:00
recorder added check for recorder cmdline flags 2017-08-05 02:18:29 +03:00
server fixed passing server init resolution in proxy code 2017-07-20 16:37:19 +03:00
.gitignore added *.test to gitignore 2017-07-09 09:55:45 +03:00
build.sh added a build script 2017-08-05 03:29:19 +03:00
LICENSE some more house cleaning, updated license & docs 2017-07-15 07:52:23 +03:00
README.md Update README.md 2017-08-04 23:13:28 -04:00
todo.md some refactoring + better recorder 2017-08-03 01:33:09 +03:00
vncproxy.iml Added server for web sockets, plus some refactoring 2017-07-01 23:01:58 +03:00

VncProxy

An RFB proxy, written in go that can save and replay FBS files

  • supports all modern encodings & most useful pseudo-encodings
  • supports multiple VNC client connections & multi servers (chosen by sessionId)
  • supports being a "websockify" proxy (for web clients like NoVnc)
  • produces FBS files compatible with tightvnc player (while using tight's default 3Byte color format)
  • can also be used as:
    • a screen recorder vnc-client
    • a replay server to show fbs recordings to connecting clients

This is still a work in progress, and requires some error handling and general tidying up, but the code is already working (see main, proxy_test & player_test)

  • tested on tight encoding with:
    • Tightvnc (client + java client + server)
    • FBS player (tightVnc Java player)
    • NoVnc(web client)
    • ChickenOfTheVnc(client)
    • VineVnc(server)
    • TigerVnc(client)

Usage

download cmdline executables from the release section

Code samples can be found by looking at:

  • player/main.go (fbs recording vnc client)    * Connects as client, records to FBS file
  • proxy/proxy_test.go (vnc proxy with recording)
    • Listens to both Tcp and WS ports
    • Proxies connections to a hard-coded localhost vnc server
    • Records session to an FBS file
  • player/player_test.go (vnc replay server)
    • Listens to Tcp & WS ports
    • Replays a hard-coded FBS file in normal speed to all connecting vnc clients

Architecture

Image of Arch

Communication to vnc-server & vnc-client are done in the RFB binary protocol in the standard ways. Internal communication inside the proxy is done by listeners (a pub-sub system) that provide a stream of bytes, parsed by delimiters which provide information about RFB message start & type / rectangle start / communication closed, etc. This method allows for minimal delays in transfer, while retaining the ability to buffer and manipulate any part of the protocol.

For the client messages which are smaller, we send fully parsed messages going trough the same listener system. Currently client messages are used to determine the correct pixel format, since the client can change it by sending a SetPixelFormatMessage.

Tracking the bytes that are read from the actual vnc-server is made simple by using the RfbReadHelper (implements io.Reader) which sends the bytes to the listeners, this negates the need for manually keeping track of each byte read in order to write it into the recorder.

RFB Encoding-reader implementations do not decode pixel information, since this is not required for the proxy implementation.

This listener system was chosen over direct use of channels, since it allows the listening side to decide whether or not it wants to run in parallel, in contrast having channels inside the server/client objects which require you to create go routines (this creates problems when using go's native websocket implementation)

The Recorder uses channels and runs in parallel to avoid hampering the communication through the proxy.

Image of Arch

The code is based on several implementations of go-vnc including the original one by Mitchell Hashimoto, and the recentely active fork which belongs to Vasiliy Tolstov.