Skip to content

Commit ed13f29

Browse files
committed
README: list some 'slow link' strategies
re #373
1 parent cb93655 commit ed13f29

1 file changed

Lines changed: 39 additions & 0 deletions

File tree

README.md

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -213,6 +213,45 @@ The server program will tell you a URL to point your web browser to. There,
213213
you can click on the noVNC-encrypted-connection-button to connect using the
214214
bundled noVNC viewer using an encrypted Websockets connection.
215215

216+
217+
Achieving good performance on 'slow' links
218+
------------------------------------------
219+
220+
If your client-server connection is sluggish because the link is 'slow', there
221+
are a few things to consider.
222+
223+
First off, you have to investigate whether your link has low throughput or
224+
high latency or both.
225+
226+
### Tackling High Latency
227+
228+
On a high-latency link, try asking for framebuffer updates continously, as
229+
RFB is server-push per default, not client-pull. One example implementation
230+
can be found [here](https://github.com/bk138/multivnc/blob/master/src/VNCConn.cpp#L1112)
231+
and it definitely improves responsiveness.
232+
233+
There also is the [ContinuousUpdates RFB extension](https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#continuousupdates-pseudo-encoding),
234+
but that one is not supported by LibVNC (yet).
235+
236+
### Tackling Low Throughput
237+
238+
If your link is low-throughput, you basically have to reduce the number of
239+
bytes that get sent per framebuffer update:
240+
241+
* First off, you should have your client request a lossy encoding such as Tight.
242+
This already yields some huge savings.
243+
* Use a pixel format that represents a pixel with a smaller amount of bytes.
244+
For instance, you can switch from 24-bit true colour to 16-bit high colour or
245+
even a palleted colour mode. You can request a pixel format via the client or
246+
set a default (native) one in the server. With the latter approach, however,
247+
you very probably also have to change the way your framebuffer data gets written,
248+
so the first client-side one should be preferred.
249+
* Send a scaled-down version of your framebuffer. You can do the scaling in your
250+
application feeding data into LibVNCServer's framebuffer (production-ready)
251+
or let LibVNCServer do the work for you if your client requests a scaled screen
252+
(not tested for a long time).
253+
254+
216255
Commercial Use
217256
==============
218257

0 commit comments

Comments
 (0)