VNC查看器實現

Question

我們的團隊在Windows上實現VNC查看器（= VNC客戶端）。該協議（稱爲RFB）是有狀態的，這意味着觀看者必須讀取1個字節，看看它是什麼，然後再讀取3或10個字節，解析它們，等等。

我們決定使用異步套接字和單個（UI）線程。因此，有兩種方法可行：

1）狀態機 - 如果我們在套接字讀取中遇到阻塞，只記得當前狀態並退出。稍後，套接字通知將到達，中斷的邏輯將從適當的階段恢復; 2）內部消息循環 - 一旦我們確定從套接字讀取將阻塞，我們進入一個內部消息循環並在那裏旋轉，直到最終接收到所有必要的數據爲止。 用戶界面不會在塊凍結的情況下被凍結。

經驗表明，第二種方法是不好的，因爲任何消息都可能在我們進入內部消息循環時發生。我不能在這裏講完整的故事，但它不夠可靠。崩潰和kludges。

第一個選項似乎是完全可以接受的，但在這種風格下編程並不容易。必須記住算法的狀態以及進一步處理所需的所有局部變量的值。

這是很有可能使用多線程，但我們只是認爲在這種情況下的問題將更加困難：幀緩衝區訪問的同步，多線程問題等。此外，即使在這種變體中似乎也需要使用異步套接字。

那麼，你認爲最好的方式是什麼？

問題是相當普遍的問題。這是通過有狀態協議組織異步通信的問題。

編輯1：我們使用C++和MFC作爲UI框架。

Answer 1

我已經完成了一些並行計算項目，似乎MPI（消息傳遞接口）可能對您的VNC項目有幫助。您可能對MPI提供的並行計算能力不太感興趣，但您可能希望使用簡化的類似套接字的接口在網絡上進行異步通信。

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

你可以找到MPI的其他實現方式和大量的從谷歌使用的例子。

Answer 2

不要打擾CSocket，因爲你得到的額外控制（中斷，關閉等），你最終會轉移到CAsyncSocket。我還建議使用單獨的線程來管理通信，它會增加複雜性，但保持UI的響應應該成爲首要任務。

Answer 3

我想你會發現，通過使用單獨的線程來處理阻塞的插座，您的設計將會大大簡化。

這樣做的主要原因是你不需要旋轉和等待。用戶界面保持響應，而網絡線程阻塞時無所事事，當有事情要做時會回來。您正在有效地將大部分開銷卸載到操作系統。

請記住，RFB並不需要大量狀態信息才能工作。由於客戶端到服務器的消息很短，在發送下一個指針輸入之前，沒有什麼要求您接收幀緩衝區。

我的觀點是RFB中的消息可以混合在一起;服務器將按照您的時間表工作。

現在，Windows提供了簡單易用的同步API，雖然並不總是最高效的，但對於您的目的來說已經綽綽有餘，並且會輕鬆地獲得概念證明。 看看Windows Synchronization特別Critical Sections

只是我的2分錢小費，我實現了兩個VNC服務器和客戶端在Windows上，這些都是我的印象。