2011-10-15 44 views
2

我試圖闡明一個項目的想法,其中可以在python中開發客戶端GUI,並且GUI可以由後端驅動可能是任何其他語言,通過RPC。 更具體地說,現在我在客戶端使用PyQt,並將Go作爲最初的後端。跨語言客戶端/服務器的雙向RPC選項

這裏是我的目標:

  • PyQt的客戶
    • 角色:視圖,控制器
    • 單向調用(SIGNAL/SLOT),如:button.clicked -> RPC.handleSignal
    • 請求/回覆RPC,如:rowCount = model.rowCount -> RPC.call.model.rowCount
  • 不可知論後端(在這種情況下轉到)
    • 角色:控制器,型號
    • 單向調用(發射信號)時,如:model.dataChanged -> RPC.emitSignal

我因爲用戶可以在GUI客戶端定義信號/插槽連接,或者後端可以定義它自己的信號假設有關客戶端視圖的知識,通過RPC進行nal/slot連接。這完全取決於用戶想要如何設置控制器。

我現在正在看Thrift,vs比較輕的基本rpc沒有IDL。但主要是我的問題是,嘗試使用Thrift作爲兩個.thrift文件(客戶端/服務器< ---->客戶端/服務器(兩個連接))以實現雙向功能?我在Thrift看到的好處是IDL,因此我可以專門構建我的界面,而後端代碼可以實現他們想要的部分。

有沒有人有對此解決方案的建議?兩個Thrift接口?一個Thrift接口,提供服務讓客戶端建立第二個簡單的套接字來接收來自服務器的單向呼叫?還是節儉有點甚至矯枉過正?雖然後端 - > GUI界面實際上只是一個單一的服務功能,GUI - >後端可能會擴展一些(modelHandlers,slotHandlers,一般服務器狀態查詢)。

(編輯)更多的思考

部分的我在想,該模式可以與任何RPC框架來完成,它會是這樣?

  1. 後臺服務器進程啓動;監聽端口
  2. 客戶端GUI啓動;連接到服務器RPC;聽新港口;通過RPC調用發送端口到服務器
  3. 服務器接收來自客戶端端口,並結合到它的第二個RPC連接
  4. 客戶端和服務器有2個連接,用於雙向RPC

回答

2

在網絡上時當您連接您的PC已經選擇並偵聽(僞/相對)隨機端口以便接收服務器答案時,您通過TCP(或任何其他類似的基於連接的協議)連接到服務器。所以就此而言,只要服務器保持連接,並且雙方都保持連接處於活動狀態,則您已經擁有雙向連接。所以從技術層面來看,你不需要發起第二次連接

根據您的RPC系統它可能會或可能不會使用TCP和它可能會或可能不會擁有雙向通信(或者更確切地說,雙向通信初始化)。

現在,對於節儉,那裏似乎還沒有太多的文檔(沒有API參考)。但是檢查示例代碼似乎將連接處理抽象出來並僅使用請求/響應通信。所以在這種情況下,是的,您必須在定義的端口客戶端監聽並告訴服務器,以便服務器可以發起請求/響應通信

轉到本身提供RPC包,這是唯一去的數據,因此不會幫你。

但是,它也提供了websocket。儘管最初針對web服務器到web瀏覽器通信,但它是一個雙向協議(這就是它最終的目的),並且可以被任何應用程序類型使用。它可能不是有效的尺寸/帶寬方面,但它可以完成這項工作。

我不確定在go包中的實現狀態。 Conn類型確實有一個源字段,但Conn.Dial函數示例通過了http://localhost;我不確定這是否被替換爲可遠程訪問的websocket來源。 Handler.ServeHTTP函數提供了一個http.ResponseWriter,你也可以用它來啓動連接。 至少這是我會測試的第一件事。

的選擇,如果您熟悉使用定義DATAFORMAT和手柄聯網自己,是protobuf。有一個community project for go bindings to protobuf。然後您可以自己處理TCP連接(連接到它併發送數據,接收數據,保存連接信息等)。

至於其他替代,你可能要檢查的community packages page和或community projects page(特別是圍棋的Ajax和走向XMLRPC - 都是非常基本的在這一點上,雖然)。

+0

Go protobuf現在不支持rpc,所以我將不得不爲我的rpc包做我自己的編碼器解碼器。所以你通常建議選擇兩個連接和一個節儉或protobuf層?我認爲有一個單一的連接的唯一方法是做一個直接的套接字連接和多個。雙向rpc呼叫。 Websocket似乎在這個混合中完全沒有意義。除非我這麼抽象地想讓pyqt ui與基於http的服務器通信。但在那種情況下,這些服務器中的任何一個都可以做原始tcp – jdi

+0

我從來沒有聽說過我的評論有任何更多的細節,但它已經這麼久了,我認爲這是我將得到的最好答案:-) – jdi