2路跨进程通信
我正在开发一个项目，我想要一个像系统一样的插件沙箱，但是我在进行双向实时跨进程通信时遇到问题。一开始我想到了WCF，因为它可以传递对象元数据，但很快意识到WCF的服务客户端模型会带来问题。但在我提出所有想法和问题之前，我已经计划好了。
我想要一个主机应用程序来完成大部分工作，让我们称之为host.exe，host.exe将托管程序的主要应用程序逻辑，以及插件的启动、执行和终止。插件将通过插件代理托管，插件代理将通过 MEF 托管它们，因此我们将其称为 proxy.exe。 proxy.exe 将加载插件 dll 并将它们托管在一个隔离的环境中，该环境将隔离故障，如果插件失败，它将杀死代理而不是应用程序。主机和代理需要双向实时通信，并且由于将有多个代理主机，因此最好能够传递对象数据。
这就是我想要的基本想法。我正在考虑几种方法来做到这一点。第一个是 WCF，但是我认为 WCF 的工作方式对于服务服务器向客户端发送请求/命令来说可能是困难的，甚至是不可能的。下一个想法是使用 TCP，让主机成为 TCP 服务器并开发一个可用于通信的消息传递协议，但这会带来一个问题，因为我没有 WCF 元数据的奢侈，并且传递复杂的类信息将快疯了。
通过我的所有研究，我提出了一个又一个问题，如果有人能够提出解决这个问题的方案，我将不胜感激。谢谢。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的解决方案可能是远程处理。我不知道WCF是否也是这样做的。但可以使用文本配置远程处理，并且可以将服务器设置为随意远程到对象。
我想预先警告你。我提到的项目是很久以前的，所以这可能是过时的信息（WCF 可能会做同样的事情，也可能不会，我的公司不需要我做任何 WCF 工作。）
我将我的对象从客户端远程到服务器。我将运行服务器（实际上在单独的机器上），然后使用 tcp 远程处理，我想要的所有对象都将声明到该应用程序中。
现在这是有趣的部分。该远程对象使用非远程委托对象。我将初始化该对象（远程），然后服务器将创建它。然后我将初始化另一个（接口类型）本地对象并将其附加到远程对象。
当远程对象想要与我通信时，它会向我发送可序列化的信息，我会将其构造成更多对象或命令。无论需要什么......（可能是更遥远的物体）
无论如何。一台服务器和多个远程对象将通过 CommonInterface.dll 来回发送，其中定义了所有标准接口对象。
这是出于所有意图和目的的盲目插件设置，任何想要从我的服务器获取信息或从我的服务器获取信息的应用程序都能够实现和处理它们的类，只要接口匹配。 （使用可序列化的命令数据）
如果插件（客户端）崩溃，那么应用程序（服务器）不会受到影响。它只会将与该插件的所有通信包装在 try catch 中，并且远程对象将具有某种生存时间或 ping 风格的释放机制。
我真的不知道沙箱的情况会是什么样子，但这可能会满足您的要求。
这是一个 .net 远程聊天服务器。
http://www.codeproject.com/KB/IP/dotnetchatapplication.aspx
这与我第一次使用远程处理构建的项目类型相同。我将它演变为我的服务器插件架构。我的使用和你的使用之间的区别在于，服务器是我的客户端是使用服务器的主要应用程序，而你的服务器将是允许多个客户端插入的主要应用程序。
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.
在我看来，我建议您使用不同的应用程序域，使用接口与插件进行通信，以及真正的代理对象引用。不要使用不同的进程，可以通过应用程序域隔离来实现插件隔离，因为除非指定，否则异常不会跨越应用程序域边界。
作为替代方案，您可以使用已弃用的技术（例如 .NET Remoting）来进行自定义封送和透明代理对象创建。
在我看来，WCF太重了，离实时处理太远了
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
进程间通信（IPC）。也许应该称为跨进程通信 (CPC)，这是一个已知的 MS/Windows 特定概念。
有关详细信息，请此处
过去我使用过 RPC 和 Windows Pipes（也在 SQL Server 中用于传输大型数据集/结果）
您可以随时尝试另一种通信方法，WCF、Sockets、Pub/Sub消息传递；例如，TibcoRv（本地会绕过套接字）。
我觉得这些有点矫枉过正了。但可能非常适合您的要求。
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.