[vbox-dev] [Experiment]VRDE library for VNC

[Vitali Pelenjow]

Good questions.

1. You are right, the HVRDESERVER is a pointer. It is supposed to be an 
address of some internal data or object, which is used by the VRDE 
server. For VBox it is an opaque pointer value.

2. VRDE_SP_NETWORK_BIND_PORT is needed to tell VBox, which port is 
actually used by the server. BTW, this is a 32 value, so you need to 
replace sizeof(int) with sizeof (uint32_t).
Here is how it is expected to work:
* VRDECreateServer must start the server and create the listening 
socket. If this fails, call VRDE_SP_NETWORK_BIND_PORT with port value == 
0. Note that at this point the listening socket exists but the server 
must refuse all connection attempts.
* If the server created successfully, then VBox will call 
VRDEEnableConnections. The server must call VRDE_SP_NETWORK_BIND_PORT 
with the actual port value.
* VRDEDestroy must call VRDE_SP_NETWORK_BIND_PORT with port value == ~0 
(0xFFFFFFFF).

3. ClientLogon is called by the server when the client username/password 
is received, and allow the server to ask VBox if the client should be 
accepted. If ClientLogon returns an error, then the server must drop the 
client connection. ClientConnected is called after the connection with 
the client is completely established. So ClientConnected is actually 
called after ClientLogon.
For example in RDP:
* initial connection and encryption;
* logon packet -> the server calls ClientLogon;
* license exchange and demand active;
* now the client is ready and the server calls ClientConnected.

4. Lock and Unlock were designed to allow exclusive access to the 
framebuffer bitmap (they use a mutex).
But currently the server does not need the exclusive access, because 
VBox makes sure that the buffer is available for read access when a 
VRDEUpdate is called.
I think that we may change this is the future probably will remove these 
callbacks. This still needs some thinking.

Note: The server must access the framebuffer bitmap only when the 
VRDEUpdate is called. If for example the server has a second thread 
which access the framebuffer this can lead to crashes. For example, to 
avoid this problem the VRDP server uses an intermediate buffer and 
copies the framebuffer bitmap data to the intermediate buffer in 
VRDEUpdate. The intermediate buffer is then used to actually compress 
and send data to the client.

Note 2:  VRDECallbackFramebufferQuery can return 'false' if the 
framebuffer is not available. I see that VNCServerImpl::VRDEResize does 
not check the return value. The server should send a black image to the 
client if the framebuffer is not available.

Vitali.

Howard Su wrote:
> Thank you for the support. I need several answers about VRDE from you:
> 1. what's type of HVRDESERVER? I use it as a void* in my code if you 
> read it. I am not sure if this is a right way.
> 2. When should I call queryproperty with VRDE_SP_NETWORK_BIND_PORT? Is 
> this something important as part of state transition.
> 3. when should i call ClientLogon? Is it mandatory? Should it happen 
> right after ClientConnected?
> 4. What sort of operations require lock framebuffer? It is not clear 
> how to use Lock/Unlock framebuffer callback.
>
>
>
> On Wed, Feb 9, 2011 at 10:10 PM, Vitali Pelenjow 
> <Vitali.Pelenjow at oracle.com <mailto:Vitali.Pelenjow at oracle.com>> wrote:
>
>     Good work. That was the goal of VRDE interface to allow others to
>     write a remote desktop server.
>
>     What kind of state transition you would like to know about?
>     Is something not working as expected?
>
>
>     Thanks,
>     Vitali
>
>     Howard Su wrote:
>
>         I am experimenting a feature to implement VNC protocol server
>         based on VRDE interface.
>
>         Due to lack of document, i am not sure if my understanding to
>         the interface is correct. Especially, i am not sure the state
>         transition is understood correctly. If someone in this list
>         can give me a review, it will help me moving forward.
>
>         Current, the patch can work with OSE version as a
>         "Built-in-VBoxVRDP". I can successfully connect to VRDP with
>         mouse support.
>
>
>         -- 
>         -Howard
>
>
>         _______________________________________________
>         vbox-dev mailing list
>         vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
>         http://vbox.innotek.de/mailman/listinfo/vbox-dev
>
>
>
>
>
> -- 
> -Howard