Interactive Desktop Environments can be remotely accessed by using many technologies. Virtual Network Computing (VNC) is one of these. It allows to send mouse and keyboard events to a remote computer over a network, displaying graphic updates on a local display. VNC is composed of a client program, running on the local computer, and a server program, that provide desktop access on the remote computer. Client and server programs communicate by using the Remote Frame Buffer protocol (RFB). VNC is an independent platform, there are clients and servers for many graphic operating system in use today. You can use the same client to connect to different desktop environments. This makes VNC suitable to remote technical support.
The WebSocket solution for the remote office
Let’s suppose that you have a bunch of computers deployed in a remote office, connected to the Internet with a broadband router. Internally, on the LAN, they use private internet network addresses. They can connect to the outside, but from there they appear as one single computer using that (usually) sole address, that one assigned to the router. Every packet leaving/entering the LAN is tracked by the router, that swap the private network addresses with the public one. This renders the computers on the LAN, without appropriate measures, unreachable from the outside. What can be done to access the VNC server programs you installed on the office computers? One solution is to instruct the router to forward a connection request on a specific port through a computer on the LAN. This solution is quite rigid, you must use static computer addresses on the LAN, and reconfigure the router every time you add a computer in the office. Moreover not all routers allow that type of mapping. Another solution is to setup a VPN between the remote office and you, but this also add network administration complexity.
What about on-demand tunnels? Here is where the WebSocket standard can be an answer. WebSocket standard is HTTP-based, and can use all of HTTP features for eg. authentication, proxy support, SSL. A client program issue an HTTP request to a corresponding HTTP server, requesting an upgrade to WebSocket. If the server is WebSocket compliant and the request is valid it accepts the upgrade. From this point on, the communication can be an independent bidirectional flow of packets, escaping the HTTP request-response paradigm.
To setup this solution to tunnel RFB protocol data into WebSocket you need a couple of additional programs, a tunnel client program deployed in the office LAN and a tunnel server program with a public accessible Internet address. The tunnel client creates an HTTP connection to the server counterpart, upgrades to WebSocket and prepares to connect to the target VNC server when requested. The details on how to control this program operations are not discussed here. When the tunnel server accepts the connection it opens a local port to listen for incoming RFB requests, as depicted in Figure 1.
When the VNC client connects to the local tunnel server, it instruct the tunnel client to open the connection to the VNC server. At this point data can flow in each direction, as shown in Figure 2.
To evaluate if the WebSocket is a viable solution, we used VNCPlay[a], a set of tools to measure interactive performance. VNCPlay includes a VNC client that allows to record an interactive session and replay it under different system configurations. During the replay, the session output is saved into a log file. Two or more session logs can be fed to an analysis tool, included in VNCPlay, that produce response time statistics, which can be further elaborated. Response times to user activities are considered a good measure of interactive performance.
We built a test environment, composed of 3 LANs, that represent our “internet LAN”, the local network and the remote office network, and corresponds to the central, left and right parts in the figures above, respectively. The local and office LANs access to the internet LAN through two ZeroShell[b] router devices, each one configured to NAT the internal addresses to the router’s internet LAN address and to serve as default gateway for the internal LAN. The local LAN hosts the VNC client and the tunnel server with a port forwarding rule on the router to allow to connect to the tunnel server from the internet LAN. Similarly the office LAN hosts the tunnel client program and the machine running VNC server.
We used VNCPlay to record a test session, over a direct connection to the target machine with a Linux Mint OS.
The test session lasted about 8 minutes and consisted of a user creating a presentation with LibreOffice Impress on the Linux machine. Using bandwidth limitation features of ZeroShell we replayed the test session simulating 2 types of connectivity services: T1 and ADSL. T1 provide a symmetrical 1.54 Mbit/s connection, whether ADSL provide 8 Mbit/s downstream and 384Kbit/s upstream. For access with VNC from outside the upstream is the limiting factor, given that screen updates flows from the remote office to the local VNC client. To analyze replayed sessions we plot the cumulative distribution function of response times, that represent the percentage of session response times below a given value. For instance, a point with a 1 second on x-axis and a 50% value on the y-axis, means that half of the response times are below 1 second.
The same configuration, using the results as a base for performance comparisons. To analyze replayed sessions we plot the cumulative distribution function of response times, that represent the percentage of session response times below a given value. For instance, a point with a 1 second on x-axis and a 50% value on the y-axis, means that half of the response times are below 1 second.
After configuring the remote ZeroShell to limit bandwidth to T1 levels, we compared then a direct VNC connection with the WebSocket tunneled one. The CDF of response times are plotted in Figure 3. Here we can see that the latency the tunnel introduces is quite low, curves have a similar path. At the 50 percentile the response time of the tunnel setup is only 40% greater than the direct connection one.
Next we stressed the remote office limiting their upstream capabilities to only 384Kbit/s, the speed of a standard ADSL 1 connection. The CDF of response times are plotted in Figure 4. Here again the curves are quite similar, with the tunnel line laying below the other most of the time. System’s response time with ADSL increased a lot, with response times greater than 300 milliseconds the 64% of the time.
By observing the trends of the curves above, it seems that the effect of WebSocket tunnel are limited, especially if compared to the delays of limited bandwidth. We need to take into account that different sessions could produce different results. VNCPlay use some approximations to compare screen updates in the analysis phase, so other interface elements or other software could produce more or less accurate statistics. According to the results found, the WebSocket tunnel solution seems to be appropriate for remote technical support, if the remote site has a good connection to the Internet. What you miss are a couple of programs and a tool to establish the tunnel from the remote site.