1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
<html>
<head>
<title>VNC - How it works</title>
<link REL="stylesheet" HREF="styles.css" TYPE="text/css">
<meta name="GENERATOR" content="Microsoft FrontPage 3.0">
<meta name="keywords" content="VNC, ORL, Virtual Network Computing, thin-client">
<meta name="Microsoft Theme" content="none, default"><meta name="Microsoft Border" content="none, default"></head>
<body bgcolor="#FFFFFF" vlink="#000080">
<!--webbot bot="Include" U-Include="_private/header.html" TAG="BODY" startspan -->
<table border="0" width="100%" cellpadding="2">
<tr>
<td width="130"><p align="center"><img src="images/vnc.gif" alt="VNC logo" align="center" WIDTH="120" HEIGHT="105"></td>
<td width="20" valign="bottom"></td>
<td width="100%"><h1 align="center"><em>Virtual Network Computing</em><br>
<small><em>from ORL</em></small></h1>
</td>
<td width="75"><a href="http://www.orl.co.uk/"><img src="images/newlogosmall2.gif" alt="ORL" align="right" border="0" WIDTH="70" HEIGHT="47"></a></td>
</tr>
</table>
<hr color="#000080">
<!--webbot bot="Include" endspan i-checksum="5938" -->
<div align="left">
<table border="0" width="100%">
<tr>
<td width="130" valign="top" align="center" bgcolor="#DCD9BE" background="images/sidebarbg.gif"><!--webbot bot="Include" U-Include="_private/sidebar.html" TAG="BODY" startspan -->
<p align="center"><a href="index.html"><img src="images/homebutton.gif" alt="[Home]" border="0" WIDTH="120" HEIGHT="33"></a><br>
<a href="screenshots.html"><img src="images/screenbutton.gif" alt="[screenshots]" border="0" WIDTH="120" HEIGHT="33"></a><br>
<a href="free.html"><img src="images/freebutton.gif" alt="[free?]" border="0" WIDTH="120" HEIGHT="33"></a><br>
<a href="start.html"><img src="images/startbutton.gif" alt="[getting started]" border="0" WIDTH="120" HEIGHT="33"></a><br>
<a href="docs.html"><img src="images/docbutton.gif" alt="[documentation]" border="0" WIDTH="120" HEIGHT="33"></a><br>
<a href="download.htm"><img src="images/downloadbutton.gif" alt="[download]" border="0" WIDTH="120" HEIGHT="33"></a><br>
<a href="intouch.html"><img src="images/intouchbutton.gif" alt="[keep in touch]" border="0" WIDTH="120" HEIGHT="33"></a><br>
<a href="http://www.orl.co.uk/"><img src="images/orlbutton.gif" alt="[ORL]" border="0" WIDTH="120" HEIGHT="33"></a></p>
<!--webbot bot="Include" endspan i-checksum="44984" -->
</td>
<td width="8%" valign="top"><p align="center"><a href="docs.html"><img src="images/backbutton.gif" alt="back to docs" hspace="2" border="0" WIDTH="20" HEIGHT="20"></a></td>
<td width="100%" valign="top"><h2>VNC - How it works</h2>
<h3>The VNC Protocol</h3>
<p>The VNC protocol is a simple protocol for remote access to graphical user interfaces.
It is based on the concept of a <em>remote framebuffer</em> or<em> RFB</em>. In the
past we have tended to refer to the VNC protocol as the RFB protocol, so you may have seen
this term in other publications. The protocol simply allows a server to update the
framebuffer displayed on a viewer. Because it works at the framebuffer level it is
potentially applicable to all operating systems, windowing systems and applications. This
includes X/Unix, Windows 3.1/95/NT and Macintosh, but might also include PDAs, and indeed
any device with some form of communications link. The protocol will operate over any
reliable transport such as TCP/IP. </p>
<p align="center"><a name="38"> </a><a name="figrfbarch"> </a><img align="bottom" alt src="images/clientserver.gif" WIDTH="264" HEIGHT="118"> <br>
</p>
<p>This is truly a "thin-client" protocol: it has been designed to make very few
requirements of the viewer. In this way, clients can run on the widest range of hardware,
and the task of implementing a client is made as simple as possible. </p>
<h3>Rectangular updates</h3>
<p>The display side of the protocol is based around a single graphics primitive: <em>"put
a rectangle of pixel data at a given x,y position"</em>. This might seem an
inefficient way of drawing arbitrary user interface components. But because we have a
variety of different <em>encoding schemes</em> for the pixel data, we can select the
appropriate scheme for each rectangle we send, and make the most of network bandwidth,
client drawing speed and server processing speed. </p>
<p>The lowest common denominator is the so-called <em>raw</em> encoding, where the
rectangle is simply pixel data sent in left-to-right scanline order. All clients and
servers must support this encoding. However, the encodings actually used on any given VNC
connection can be negotiated according to the abilities of the server, the client, and the
connection between the two. </p>
<p>The <em>copy rectangle</em> encoding, for example, is very simple and efficient and can
be used when the client already has the same pixel data elsewhere in its framebuffer. The
server simply sends an X,Y coordinate giving the position from which the client can
copy the rectangle of pixel data. This means that operations such as dragging or scrolling
a window, which involve substantial changes to the screen, may only require a few bytes.
Most clients will support this encoding, since it is generally simple to implement and
saves bandwidth. </p>
<p>A typical workstation desktop has large areas of solid colour and of text. Some of our
most effective encodings take advantage of this by efficiently describing rectangles
consisting of one majority (background) colour and 'sub-rectangles' of different colours.
There are numerous other possible schemes. We might use a JPEG encoding for still
images or MPEG for efficient transmission of moving images. An encoding which uses some
kind of caching of pixel data would be good for rendering text, where the same character
is drawn in the same font multiple times. Subsequent occurrences of the same character
would be encoded simply by reference to the first occurrence. </p>
<h3>Adaptive update protocol</h3>
<p>A sequence of these rectangles makes a <em>framebuffer update</em> (or simply <em>update</em>).
An update represents a change from one valid framebuffer state to another, so in some ways
is similar to a frame of video, but it is usually only a small area of the framebuffer
that will be affected by a given update. Each rectangle may be encoded using a different
scheme. The server can therefore choose the best encoding for the particular screen
content being transmitted and the network bandwidth available.</p>
<p>The update protocol is demand-driven by the client. That is, an update is only sent by
the server in response to an explicit request from the client. This gives the protocol an
adaptive quality. The slower the client and the network are, the lower the rate of updates
becomes. Each update incorporates all the changes to the 'screen' since the last client
request. With a slow client and/or network, transient states of the framebuffer are
ignored, resulting in reduced network traffic and less drawing for the client. This
also improves the apparent response speed.</p>
<h3>Input protocol</h3>
<p>The input side of the protocol is based on a standard workstation model of a keyboard
and multi-button pointing device. Input events are sent to the server by the client
whenever the user presses a key or pointer button, or whenever the pointing device is
moved. These input events can also be synthesised from other non-standard I/O devices. On
our <a href="http://www.orl.co.uk/tile.html">Videotile</a>, for example, a pen-based
handwriting recognition engine generates keyboard events. </p>
<h3>Connection Setup and Shutdown</h3>
<p>When the connection between a client and a server is first established, the server
begins by requesting authentication from the client using a challenge-response scheme,
which typically results in the user being prompted for a password at the client end.
The server and client then exchange messages to negotiate desktop size, pixel
format, and the encoding schemes to be used. The client then requests an update for the
entire screen, and the session begins. Because of the stateless nature of the
client, either side can close the connection at any time without adverse consequences.</p>
<h3>VNC Clients</h3>
<p>Writing an VNC viewer is a simple task, as it should be for any thin-client system. It
requires only a reliable transport (usually TCP/IP), and a way of displaying pixels
(either directly writing to the framebuffer, or going through a windowing system). </p>
<p>We have clients for all the networked display devices we have available at ORL. This
includes the <a href="http://www.orl.co.uk/tile.html">Videotile</a> (the original RFB
client), an X-based client (which runs on Solaris, Linux and Digital Unix workstations), a
Win32 client which runs on Windows NT and 95, and a Java client which runs on any
Java-capable browser (including Sun's JavaStation). Members of our lab use these clients
on a daily basis to access their personal computing environments.</p>
<h3 align="left">VNC Servers</h3>
<p>Writing an VNC server is slightly harder than writing a client for a number of reasons.
The protocol is designed to make the client as simple as possible, so it is usually up to
the server to perform any necessary translations. For example, the server must provide
pixel data in the format the client wants. We have servers for our two main platforms, X
(i.e. Unix) and Windows NT/95. </p>
<p>A Unix machine can run a number of Xvnc servers for different users, each of which
represents a distinct VNC desktop. Each VNC desktop is like a virtual X display, with a
root window on which several X applications can be displayed. </p>
<p>The Windows server (WinVNC) is a little more difficult to create, because there are
fewer places to insert hooks into the system to monitor display updates, and a less
clearly-defined model of multiuser operation. Our current server simply mirrors the real
display to a remote client, which means that the server is not 'multiuser'. It does,
however, provide the primary user of a PC with remote access to their desktop. </p>
<p><img align="right" alt="VNC CD-player" hspace="4" src="images/cdplay.gif" WIDTH="288" HEIGHT="79">We have also
created simple servers which produce displays other than desktops, using a simple toolkit.
A "VNC CD player", for example, generates a CD player user interface using the
protocol directly without any reference to a windows system or framebuffer. Such
servers can run on very simple hardware, and can be accessed from any of the standard
viewers. </p>
<p> </p>
<p align="right"><a href="docs.html"><img src="images/backbutton.gif" alt="back to docs" hspace="5" border="0" WIDTH="20" HEIGHT="20"></a><em>go back to <a href="docs.html">documentation</a></em></td>
<td width="5%"></td>
</tr>
<tr>
<td width="128%" valign="top" align="center" colspan="4"><!--webbot bot="Include" U-Include="_private/footer.html" TAG="BODY" startspan -->
<hr color="#000080">
<p align="center"><em><small>Copyright 1998 - The Olivetti & Oracle Research Lab</small></em></p>
<!--webbot bot="Include" endspan i-checksum="3896" -->
</td>
</tr>
</table>
</div>
</body>
</html>
|
