GPRS latency

[cano]

ping over GPRS connection is about 600ms, so I need to wait 4 seconds until I get response when I click somewhere. Not because bandwidth, but latency. So try to minimize number of data exchanges between client and server, until real response data is sent. Because every exchange adds 600ms.

[rmoller]

Sorry for a long reply:

It has long since been inherent in the RFB protocol that framebuffer updates are only sent upon receiving a update request; it is part of the "automatic" adaptation to the transfer speed. And it works just fine for slow bandwidth with low latency.

I have experienced myself with GPRS and been frustrated that I could easily listen to net music utilizing a full 43 Kbit/s with runaway UDP, but VNC only managed to use much less than 10Kbit/s because of high latency and poor TCP adaptation.

Actually IBM and others have tweaked TCP implementations to use GPRS better, because standard TCP impl. assumes that even a small % of corrupted packets means congestion and therefore throttles data throughput lower and lower, when it sees corruption. But some corruption happens "naturally" now and then even with good GPRS connections - an argument in favor of a reliable UDP implementation instead of TCP, or for a TCP control channel and UDP RFB payload.

But the high latency of GPRS still requires some kind of quicker pacing of updates then the RFB req/ack to perform well. Here are some suggestions:

Maintain a local queue of yet unsent (for TCP) or yet unacknowledged by viewer (for UDP) RFB updates on the server. Whenever that queue is less than xxxxx bytes (configurable), server generates a RFB update request for itself. Thus the server will pace the RFB updates to keep high latency channels better utilized than with the traditional RFB req/ack. This could for testing be implemented inside nvs/nvc instead of winvnc/vncviewer to avoid cluttering the path to V1.0.

More tricky: Maintain a circular queue of unsent RFB updates. Sort them LIFO or by current distance to mouse pointer or to active cursor. This way you send the most relevant screen changes first. Of course it means that you need a way to deal with queue overflow; to discard/undo RFB updates that are not sent before their place in the queue is needed for newer entries. This is especially relevant for interactive VNC use over GPRS with its combination of low bandwidth and high latency. If this is used with UDP, you need a acknowledge/resend scheme for RFB updates; once an update is sent, you need to wait and evt. resend it until reception is confirmed.

Thank you for reading this far.

Rasmus Møller