2路跨流程通讯

Question

I am working on a project that i want to have a plugin-sandbox like System, However i am having issues working out 2-Way Real time Cross Process Communication. At first i thought of WCF, as it can pass object Metadata, but then soon realized that the Service Client model of WCF will pose an issue. but before i lay down all my ideas and questions here is what i have planned out.

I want to have a host application that will do most of the work, let us call this host.exe, host.exe will host the main application logic for the program, as well as the launching, executing, and killing of Plugins. Plugins will be hosted via a Plugin Proxy that will host them via MEF, so we will call it proxy.exe. The proxy.exe will load plugin dlls and host them in a secluded environment that will isolate faults and if the plugin fails it will kill the proxy and not the application. The Host and the Proxy need to communicate in real time in both directions and because there are going to be multiple proxy hosts it would be best to be able to pass object data.

so that is the basic idea of what i want. I was thinking of several ways to do this. the first being WCF, however i figured that the way WCF works it would be difficult if not impossible for the server of the service to send the client a request/command. the next idea what to use TCP, and have the host be a TCP server and develop a messaging protocol that i can use to communicate, however that poses an issue as i do not have the luxury of the WCF metadata and passing complex class information would be down right insane.

Through all my research i have came up with issue after issue after issue, it would much appreciated if anyone is able to suggest a solution to this issue. Thank you.

Answer 1

Interprocess communication (IPC). Which maybe should called cross-process communication (CPC) is a known MS/Windows specific concept.

More about it here

In the past I've used RPC and Windows Pipes (which is used also in SQL server for transferring large data-sets/results)

You can always try another method of communication, WCF, Sockets, Pub/Sub Messaging; example, TibcoRv (which locally would bypass sockets). I find these to be a bit of an overkill. but could be perfect for your requirement.

Answer 2

My solution for this would likely be remoting. I dont know if WCF does this the same way. but remoting can be configured with text and servers can be setup to remote to an object at will.

I want to warn you up front. The project I am mentioning is from quite a while ago so this may be out dated information (WCF may do the same thing or it may not, My company has not required any WCF work from me.)

I remoted my objects from the client to the server. I would run the server (actually on a separate machine) then using tcp remoting, all the objects I wanted would be declared into that application.

Now here is the fun part. that remoted object used non remoted delegate objects. I would initialize the object (remoted) and the server would create it. Then I would initialize another (Interface Typed) object local and attach it to the remote object.

When the remote object wanted to communicate to me it would send serializable information to me and I would construct that into more objects or commands. Whatever was needed... (possibly more remote objects)

In any rate. One server and multiple remote objects would be sent back and forth with a CommonInterface.dll with all the standard interface objects defined in it.

This was for all intents and purposes a blind plugin setup that any application wanting to get information to or from my server would be able to implement and handle their classes as long as the interfaces matched. (with serializable command data)

If the plugin (client) crashes then the application (server) would not have to suffer. It would just wrap all communication to that plugin in a try catch and the remoted object would have some sort of time to live or ping style release mechanism.

I dont really know what your scenario is going to be like with the sandboxing but this may accomplish what you are asking.

here is a .net remoting chat server.

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

This is the same type of project I build my first time with remoting. and I evolved it into my server plugin architecture. The difference between my use and yours is that the server was my client was the main application using the server and yours the server will be the main application allowing multiple clients to plugin.

Answer 3

In my opinion, I advice you use different application domains, an communicate with plug-ins using interfaces, and a real proxy object references. Do not use different processes, you can achieve plug-ins isolation through application domain isolation, because exceptions do not cross application domain boundaries unless specified.

As an alternative, you can use deprecated technologies, as .NET Remoting, for tje cusom marshaling and transparent proxy object creation.

In my opinion, WCF is too heavy and too far from real-time processing