2010-07-08 46 views

回答

7

您可以使用IObservable.Remotable通過.NET Remoting直接從其他機器使用observables。

+0

嗨保羅,你有鏈接到某種文章,解釋它是什麼以及它是如何工作的? – theburningmonk 2010-07-09 14:21:46

+0

http://msdn.microsoft.com/en-us/library/kwdt6w2k(VS.71).aspx描述了遠程處理 - 但請注意,當涉及到版本控制時,Remoting有一些非常重要的注意事項(例如,計算機A已經構建1004和計算機B有1007 =>應用程序壞了) – 2010-07-09 15:30:44

+0

謝謝,實際上我正在尋找IObservable.Remotable的例子,因爲我還沒有碰到它的前一版本的Rx :-P無論如何,在Channel9視頻中找到它我在 – theburningmonk 2010-07-10 08:55:00

0

沒有理由不能爲此設計框架。框架必須提供一種方法來處理遠程對象,爲它們生成代理,然後跨應用程序邊界(即通過套接字通信)整理遠程對象的活動。 .NET Remoting可能是實現此目的的合適選項。 WCF會更好。

+0

因此,現在框架的立場,你不能只調用一個遠程服務器,並獲得一個IObservable並訂閱它?這是有道理的,因爲Rx需要知道在哪裏以及如何進行回調,而且肯定無法神奇地將它們自行排除!大聲笑 – theburningmonk 2010-07-08 11:01:13

+0

是的,這是它的要義。 – Jacob 2010-07-08 18:28:21

0

您是否特別接受使用Rx作爲解決方案? WCF提供雙工服務,客戶可以將回調端點註冊到服務。如有必要,服務可能會啓動回呼客戶。它實際上是一個遠程觀察者模式。如果RX是必須的,那麼使用RX支持框架來包裝WCF雙工服務應該是相當困難的,允許客戶「透明」地觀察IObservable的服務行爲。

+0

以下發布我們並不一定會使用Rx作爲解決方案,只是探索不同的可能性。一個雙工WCF服務也彈出來了,但是能夠使用Rx處理更復雜的複合事件會很好。 – theburningmonk 2010-07-09 14:24:38

2

是的。

RX內置支持使用.NET Remoting跨越進程邊界。

如果您安裝了NuGet軟件包rx-remoting,它將安裝程序集System.Reactive.Runtime.Remoting.dll,該程序集支持跨進程的RX消息。

有關Microsoft的演示代碼,請參閱RX Across Processes。我剛剛測試了這個頁面上的代碼,它很好地工作。爲了得到它來編譯,則需要添加下列引用:

  • NuGetReactive Extensions - Main Library(搜索reactive extensions main
  • NuGetReactive Extensions - .NET Remoting Support(搜索reactive extensions remoting
  • System.Runtime.Remoting(添加爲正常的參考,這個組件附帶.NET)

@theburningmonk提到的Channel 9視頻也很有趣。

更新

Unfortuantely,這種解決方案有一個大的限制:你只能有一個客戶端程序監聽(所有後續的客戶端無法連接)。 Pushqa解決了這個問題(請參閱我的其他答案)。實質上,任何在pub/sub信號總線上實現RX的庫都應該這樣做。

2

是的。

結賬Pushqa

  • 它易於使用。我在大約5分鐘後就起來跑步了。
  • 它適用於C#.NET,WPF,ASP.NET或Javascript。 SignalR內置於ASP.NET中,但如果您添加了正確的NuGet包,則它適用於任何C#.NET項目。
  • 由於我們可以有一個服務器和許多訂閱者(它是一個真正的pub/sub模型,就像RX一樣),它優於RX over .NET遠程處理(請參閱我的其他答案)。
  • 將查詢編譯到表達式樹中,並在服務器上執行(最小化網絡流量,因爲只從服務器返回相關結果)。
    • 如果我們想要過濾客戶端的查詢,那麼很簡單 - 只需對從pushqa返回的結果執行客戶端過濾。
  • 它的字面意思是痛苦的1%,樣板代碼的1%,以及Tibco的可用性的10倍。我爲Tibco寫了RX包裝,這是一個噩夢,讓它正確(Tibco有更多corner cases比浴盆dodecahedrons)。除非您需要連接到傳統大型機客戶端,或者希望通過UDP向數百個客戶端進行組播,或者想要隨意將許多國王浪費在許可費用中,否則此解決方案遠勝於Tibco。
  • 其免費。
  • 其開源。

enter image description here

3

另一種可能的解決辦法是使用命名管道。

有一個很好的NuGet包NamedPipeWrapper,請參閱source on GitHub。在此之上編寫一個精簡的RX封裝將很容易,即訂閱RX流並使用此庫將消息推送到其他.NET偵聽進程。

由於此解決方案使用命名管道,它將是一個真正的發佈/訂閱解決方案,它將支持不同進程中的多個訂戶。

更新

這的確是很容易通過命名管道庫編寫簡單的RX橋代碼。使用RX Subject並將RX橋代碼插入事件處理程序。它的兩端不超過4行額外的代碼。如果有人感興趣,我可以發佈代碼。

更新

有關命名管道的詳細信息,請參閱.NET 3.5 Adds Named Pipes SupportInterprocess Communication Using .NET 3.5 Named Pipes IO。前面提到的NuGet包NamedPipeWrapper是.NET 3.5引入的命名管道內置支持的更好版本。