Question about vncviewer frame buffer update requests

Sood, Sanjeev sanjeev.sood "at" intel.com
Sat Apr 2 08:03:01 2005


James,



Thanks for you response. I have looked at the RFB protocol couple of
times and my questions arrived from studying that spec. I understand
from your reply that server will only send a reply if a client asks for
one. But I am still not clear on my others questions. Since you have
much better understanding of the protocol, would you please take some
time answer my following questions?



1.      Since RFB protocol is purely event driven, does client send its
request right after it receives the frame buffer update from the server?
That way protocol is self clocking, the sooner replies come, sooner
client can process that & request next one.

2.      You are saying that all screen buffers changes will be sent even
to a client over a slow link and nothing is lost. My confusion is that
slow client's frame buffer update request may not arrive before the
screen data scrolls over? (e.g. large output can be generated by running
"ls -lR /" command)? How does RFB server send such buffer data for which
client's request has not yet arrived?

3.      What if there are two viewers connected to same session, would
screen buffer change caused by one viewer be sent to both viewers or
only when the other viewer asks for it?



Thank you very much,

-Sanjeev







-----Original Message-----
From: James Weatherall [mailto:jnw "at" realvnc.com]
Sent: Friday, April 01, 2005 9:58 PM
To: Sood, Sanjeev; vnc-list "at" realvnc.com
Subject: RE: Question about vncviewer frame buffer update requests



Sanjeev,



Please see the RFB protocol document

(http://www.realvnc.com/docs/rfbproto.pdf) for complete details of the
RFB

protocol.  All standard versions of VNC as provided by RealVNC Ltd.

(http://www.realvnc.com/download.html) implement RFB.



In short - RFB is adaptive to network bandwidth and no, updates won't go

missing if a particular viewer is running over a slow link.  RFB servers

will never send multiple updates for a single update request.



Wez @ RealVNC Ltd.





-----Original Message-----

From: vnc-list-admin "at" realvnc.com [mailto:vnc-list-admin "at" realvnc.com] On

Behalf Of Sood, Sanjeev

Sent: 31 March 2005 20:04

To: vnc-list "at" realvnc.com

Subject: Question about vncviewer frame buffer update requests





I am new to RFB protocol and trying to understand the protocol. I have

questions regarding the frame buffer update requests in your
implementation.







1.         My understanding is that RFB Frame Buffer Requests are purely

driven by the clients. Is that the case with the RealVnc viewer & server

implementation?

2.         When does the viewer request the update and how often does it
do

it? Does it poll at some rate, is it tunable, or is it adaptive to the

network bandwidth?

3.         If Xvncserver does not send any updates without clients
asking

for it, could client possibly loose some screen full of data if its
request

does not arrive in time before the screen changes? E.g. if client types
in

ls -lR command to recursively traverse the root directory, there can be
lot

of scrolling and client may miss data until his next request arrives.

4.         What if there are two viewers connected to same session,
would

screen buffer change caused by one viewer be sent to both viewers or
only

when the other viewer asks for it?

5.         How would the realVNC viewer react if a RFB server sends it

multiple updates responses for one request (e.g. to deal with the
scrolling

case above or when 2nd client to a session causes some change in the

buffer)? Is it a stateless client or does it track request & responses?







I will really appreciate any help and guidance. Thank you very much,



-Sanjeev Sood

_______________________________________________

VNC-List mailing list

VNC-List "at" realvnc.com

To remove yourself from the list visit:

http://www.realvnc.com/mailman/listinfo/vnc-list