CODEWITHSUNDEEP
c++multithreadingasynchronousmfcvnc
egnarts-ms
egnarts-ms

Reputation: 146

VNC viewer implementation

Our team is implementing a VNC viewer (=VNC client) on Windows. The protocol (called RFB) is stateful, meaning that the viewer has to read 1 byte, see what it is, then read either 3 or 10 bytes more, parse them, and so on.

We've decided to use asynchronous sockets and a single (UI) thread. Consequently, there are 2 ways to go:

1) state machine -- if we get a block on socket reading, just remember the current state and quit. Later on, a socket notification will arrive and the interrupted logic will resume from the proper stage;

2) inner message loop -- once we determine that reading from the socket would block, we enter an inner message loop and spin there until all the necessary data is finally received. UI is not thus frozen in case of a block.

As experience showed, the second approach is bad, as any message can come while we're in the inner message loop. I cannot tell the full story here, but it simply is not reliable enough. Crashes and kludges.

The first option seems to be quite acceptable, but it is not easy to program in such a style. One has to remember the state of an algorithm and values of all the local variables required for further processing.

This is quite possible to use multiple threads, but we just thought that the problems in this case would be even much harder: synchronization of frame-buffer access, multi-threading issues, etc. Moreover, even in this variant it seems necessary to use asynchronous sockets as well.

So, what way is in your opinion the best ?

The problem is quite a general one. This is the problem of organizing asynchronous communication through stateful protocols.

Edit 1: We use C++ and MFC as UI framework.

Upvotes: 1

Views: 2467

Answers (3)

8bitwide
8bitwide

Reputation: 2071

I think you will find that your design will be simplified greatly by using a separate thread to handle a blocking socket.

The main reason for this is you don't need to spin and wait. The UI remains responsive while the network thread(s) block when it has nothing to do and comes back when it has stuff to do. You are effectively offloading a large portion of your overhead to the OS.

Remember, RFB does not require a whole lot of state info to work. Because client to server messages are short; there is nothing requiring you to receive a frame buffer before you send your next pointer input.

My point being is messages in RFB can be intermixed; the server will work on your schedule.

Now, Windows provides easy to use synchronization API's that while not always the most efficient, are more than enough for your purposes and will ease getting a proof of concept up and going. Take a look at Windows Synchronization and specifically Critical Sections

Just my 2cents, I've implemented both a vnc server and client on windows, these were my impressions.

Upvotes: 0

snowdude
snowdude

Reputation: 3874

Don't bother with CSocket, you'll move to CAsyncSocket in the end because of the extra control you get (interrupting, shutting down etc.). I'd also recommend using a separate thread to manage the communication, it adds complexity but keeping the UI responsive should be a top priority.

Upvotes: 1

h9uest
h9uest

Reputation: 11628

I've done a few parallel computing projects and it seems that MPI (Message Passing Interface) might be helpful to your VNC project. You're probably not so interested in the parallel computing power provided by MPI, but you may want to use the simplified socket-like interface for asynchronous communication over a network.

http://www.open-mpi.org/

You can find other implementations of MPI and tons of use examples from google.

Upvotes: 1

Related Questions