Can Reactive Extensions (Rx) be used across process or machine boundaries?

Question

Vaguely remember seeing some discussions on this quite a while back but haven\'t heard anything since. So basically are you able to subscribe to an IObservable on a remote machi

Answer 1

Another possible solution could be to use named pipes.

There is an excellent NuGet package NamedPipeWrapper, see the source on GitHub. It would be easy to write a thin RX wrapper over this, i.e. subscribe to the RX stream and push the messages out to other .NET listening processes using this library.

As this solution uses named pipes, it would be a true pub/sub solution which would support multiple subscribers in different processes.

Update

It is indeed very easy to write simple RX bridge code over the named pipes library. Use an RX Subject and insert the RX bridge code into the event handlers. Its not more than 4 lines of additional code at both ends. I can post the code if anyone is interested.

Update

For more information on named pipes, see .NET 3.5 Adds Named Pipes Support and Interprocess Communication Using .NET 3.5 Named Pipes IO. The aforementioned NuGet package NamedPipeWrapper is a much nicer version of the built-in support for named pipes that .NET 3.5 introduced.

Answer 2

There's no reason that a framework couldn't be devised for doing that. The framework would have to provide a means to address remote objects, generate proxies for them, then marshal the activity of the remote object across the application boundaries (i.e. through socket communication). .NET Remoting may be a suitable option for implementing this. WCF would be even better.

Answer 3

Found this cool video on Channel 9 which an example of using IObservable.Remotable as Paul pointed out:

http://channel9.msdn.com/posts/J.Van.Gogh/Whats-different-about-the-3-versions-of-Rx-Part-3-NET-35-SP1/

Very interesting stuff, gonna spend a bit of time playing around with it now! :-D

Answer 4

Yes.

RX has built in support for using .NET Remoting to cross process boundaries.

If you install the NuGet package rx-remoting, it will install the assembly System.Reactive.Runtime.Remoting.dll which provides support for cross-process RX messages.

For demo code from Microsoft, see RX Across Processes. I've just tested the code on this page, and it works nicely. In order to get it to compile, you will need to add the following references:

• NuGet: Reactive Extensions - Main Library (search for reactive extensions main)
• NuGet: Reactive Extensions - .NET Remoting Support (search for reactive extensions remoting)
• System.Runtime.Remoting (add as a normal reference, this assembly ships with .NET)

The Channel 9 video mentioned by @theburningmonk is also interesting to watch.

Update

Unfortuantely, this solution has one large limitation: you can only have one client process listening (all subsequent clients cannot connect). Pushqa solves this problem (see my other answer). Essentially, any library which implements RX on top of a pub/sub signalling bus should do the trick.

Answer 5

Yes.

Check out Pushqa.

• Its easy to use. I was up and running in about 5 minutes.
• It works with C# .NET, WPF, ASP.NET or Javascript. SignalR is built into ASP.NET, but it works for any C# .NET project if you add the right NuGet package.
• It is superior to RX over .NET remoting (see my other answer), as we can have one server and many subscribers (it is a true pub/sub model, just like RX).
• The queries are compiled into expression trees, and executed on the server (which minimizes network traffic, as only relevant results are returned from the server).
  • If we want queries to be filtered client side, then its easy - just do a client side filter on the results returned from pushqa.
• Its literally 1% of the pain, 1% of the boilerplate code, and 10x the usability of Tibco. I wrote RX wrappers for Tibco and it was a nightmare to get it correct (Tibco has more corner cases than a tub of dodecahedrons). Unless you need to connect to legacy mainframe clients, or want to multicast to hundreds of clients over UDP, or want to waste a kings random in licensing fees, this solution is far superior to Tibco.
• Its free.
• Its open source.

Answer 6

Are you specifically bound to using Rx as the solution to your problem? WCF provides duplex services, which have the ability for clients to register callback endpoints to a service. The service may then initiate calls back to its clients as necessary. It is effectively a remoted observer pattern. If RX is a must, then it should be fairly strait forward to wrap WCF duplex services with an RX support framework, allowing your clients to "transparently" observe service behavior with IObservable.