2011-10-04 116 views
2

我正在開發一個項目,我想要一個像系統一樣的插件沙箱,但是我遇到的問題是雙向實時交叉進程通信。起初我想到了WCF,因爲它可以傳遞對象元數據,但是很快就意識到WCF的Service Client模型會帶來問題。但在我放下所有的想法和問題之前,這正是我的計劃。雙向交叉進程通信

我想要一個主機應用程序來完成大部分的工作,讓我們調用這個host.exe,host.exe將託管程序的主要應用程序邏輯,以及啓動,執行和查殺插件。插件將通過一個將通過MEF託管的插件代理託管,因此我們將其稱爲proxy.exe。 proxy.exe將加載插件dll並將其託管在一個僻靜的環境中,以隔離故障,如果插件失敗,它將終止代理而不是應用程序。主機和代理需要在兩個方向上進行實時通信,並且因爲要有多個代理主機,所以最好能夠傳遞對象數據。

所以這是我想要的基本想法。我在想幾種方法來做到這一點。第一個是WCF,但是我認爲WCF的工作方式對於服務器的服務器發送請求/命令將是困難的。下一個想法是什麼使用TCP,並讓主機成爲一個TCP服務器並開發一個可用於通信的消息傳遞協議,然而這帶來了一個問題,因爲我沒有WCF元數據的奢華和傳遞複雜的類信息精神錯亂。

通過我所有的研究,我已經提出了問題後的問題,它將非常感謝,如果有人能夠建議解決這個問題。謝謝。

+0

你如何幫助我們?你真的認爲使用幾個代碼示例我們可以解決你的問題嗎? –

+0

你在說IPC嗎?那麼,你不需要WCF,WCF不是實時的進程間通信服務,而是使用基於IPC的實時客戶端 - 服務器技術。 –

+0

@Artur Mustafin,我只是想要我的計劃到目前爲止的想法和反饋。是的,我知道WCF不是實時的。這是我正在看的一個選項。雖然我沒有代碼,但我不想要代碼,只是想法和反饋,謝謝。 – p1p3l1n3

回答

0

我的解決方案很可能是遠程處理。我不知道WCF是否以同樣的方式執行此操作。但遠程處理可以使用文本進行配置,並且可以將服務器隨意設置爲遠程對象。

我想提前警告你。我提到的這個項目是在不久之前發佈的,所以這可能是過時的信息(WCF可能做同樣的事情或不可能,我的公司不需要我的任何WCF工作。)

我遠程對我的對象從客戶端到服務器。我會運行服務器(實際上是在一臺單獨的機器上),然後使用tcp remoting,我想要的所有對象都將被聲明爲該應用程序。

現在,這裏是有趣的部分。該遠程對象使用非遠程委託對象。我會初始化對象(遠程),服務器會創建它。然後,我會初始化另一個(接口類型)對象本地,並將其附加到遠程對象。

當遠程對象想要與我通信時,它會向我發送可序列化的信息,我會將它構造成更多的對象或命令。不管需要什麼......(可能是更遠程的物體)

無論如何。一個服務器和多個遠程對象將使用CommonInterface.dll來回發送,其中定義了所有標準接口對象。

這是所有意圖和目的的盲插件設置,任何想要從我的服務器獲取信息的應用程序只要接口匹配就能夠實現和處理它們的類。 (帶有可串行化的命令數據)

如果插件(客戶端)崩潰,那麼應用程序(服務器)就不會受到影響。它只是將所有的通信封裝到try插件中,並且遠程對象會有某種時間來存活或ping式釋放機制。

我真的不知道你的場景會如何與沙箱一樣,但這可能會完成你所要求的。

這裏是一個.net遠程聊天服務器。

http://www.codeproject.com/KB/IP/dotnetchatapplication.aspx

這是同類型的項目我建立了我的第一次與遠程處理。我演變成我的服務器插件架構。我和你的使用之間的區別在於,服務器是我的客戶端是使用服務器的主要應用程序,而您的服務器將成爲允許多個客戶端插件的主應用程序。

+1

遠程處理已棄用WCF。 –

+0

謝謝你和我在想的一樣,它看起來像是有效的。我只需要設法將信息序列化成我可以處理它的方式,然後即時設置,非常感謝! – p1p3l1n3

0

在我看來,我建議你使用不同的應用程序域,與使用接口的插件進行通信,以及真正的代理對象引用。不要使用不同的進程,您可以通過應用程序域隔離實現插件隔離,因爲例外情況除非指定,否則不會跨越應用程序域邊界。

作爲替代方案,您可以將不推薦的技術用作.NET Remoting,用於創建編組和透明代理對象創建。

在我看來,WCF是太重和實時處理

+0

是的,我看着AppDomains,但加載和卸載似乎是更麻煩,然後它是值得的,從我讀的應用程序的參考從未真正收集。所以如果我在哪裏編譯一個新的對象來加載和卸載舊的,它永遠不會真正被卸載。 – p1p3l1n3

+0

當插件在其創建的線程中發生異常時,其應用程序域崩潰,並且.NET在任何應用程序域崩潰時終止整個過程。這樣主持人也被殺害了。需要進程隔離來防止來自插件的未處理的側線程異常。 –

0

進程間通信(IPC)太遠。其中可能應該稱爲跨進程通信(CPC)是已知的MS/Windows特定概念。

更多關於它here

在過去,我已經使用RPC和Windows管道(也適用於SQL服務器傳輸大型數據集/結果)

你總是可以嘗試其他方法溝通,WCF,套接字,酒吧/消息傳遞;例如,TibcoRv(本地將繞過套接字)。 我覺得這些有點矯枉過正。但可以完美滿足您的要求。