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.pelen...@oracle.com <mailto:vitali.pelen...@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@virtualbox.org <mailto:vbox-dev@virtualbox.org>
http://vbox.innotek.de/mailman/listinfo/vbox-dev
--
-Howard
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
http://vbox.innotek.de/mailman/listinfo/vbox-dev
