2

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.

p1p3l1n3
  • 51
  • 2
  • 4
  • how you gonna us help you? Do you really think that using couple of code samples we can resolve your issue? – Alan Turing Oct 04 '11 at 01:22
  • Are you talking about IPC? Then, you do not need WCF, WCF is NOT real-time inter process communication service, use real-time IPC-based client-server technologies. – Alan Turing Oct 04 '11 at 01:25
  • @Artur Mustafin, i just wanted ideas and feedback of what i have planed so far. and yes i know WCF is not real time. it was an option that i was looking at. although i don't have code, i don't want code, just ideas and feedback, thanks though. – p1p3l1n3 Oct 04 '11 at 02:03
  • You might be interested in the Managed AddIn Framework: http://msdn.microsoft.com/en-us/library/bb384200.aspx – Scott Oct 04 '11 at 05:27
  • How about using something like ZeroMQ? – code4life Jan 29 '15 at 01:09

3 Answers3

0

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.

WeSam Abdallah
  • 1,050
  • 1
  • 10
  • 16
0

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.

The Lazy Coder
  • 11,560
  • 4
  • 51
  • 69
  • 1
    Remoting has been deprecated in favor of WCF. – John Saunders Oct 04 '11 at 02:08
  • Thank you this is way alike to what i was thinking and it seems like it works. i just need to work out way to serialize the information into a way i can process it then im set, thank you so much! – p1p3l1n3 Oct 04 '11 at 02:11
0

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

Alan Turing
  • 2,482
  • 17
  • 20
  • yes i looked into AppDomains but the loading and unloading seemed to be more trouble then it was worth and from what i read the reference to the application never really gets collected. So if i where to compile a new object to load and unloaded the old one it would never really get unloaded. – p1p3l1n3 Oct 04 '11 at 02:07
  • When a plug-in has an exception in a thread it created, its app domain crashes and .NET terminates the whole process on any app domain crash. Such that the host is killed too. Process isolation is needed to protect from unhandled exceptions in side-threads from a plug-in. – David Burg Mar 20 '13 at 19:31