.NET IPC，无需服务中介
我有两个不相关的进程，它们使用 .NET 程序集作为插件。 但是，任一进程都可以随时启动/停止。 我不能依赖特定的进程作为服务器。 事实上，其中一个进程可能有多个副本在运行，而另一个则只有一个副本在运行。
我最初根据本文实现了一个解决方案。 然而，这要求实现服务器的程序在客户端之前运行。
当客户端首先运行时向服务器实现某种通知的最佳方法是什么？
I have two unrelated processes that use .NET assemblies as plugins. However, either process can be started/stopped at any time. I can't rely on a particular process being the server. In fact, there may be multiple copies running of one of the processes, but only one of the other.
I initially implemented a solution based off of this article. However, this requires the one implementing the server to be running before the client.
Whats the best way to implement some kind of notification to the server when the client(s) were running first?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我同意加罗的观点。
使用发布/订阅服务将是一个很好的解决方案。 这显然意味着该服务需要在其他两个服务之前启动并运行。
如果您想跳过发布/订阅，您可以在具有不同端点的两个应用程序中实现该服务。 当任一应用程序启动时，它会尝试通过 IPC 代理访问另一个已知对象。 如果代理失败，则另一个对象不会启动。
-斯科特
I agree with Garo.
Using a pub/sub service would be a great solution. This obviously means that this service would need to be up and running before either of the other two.
If you want to skip the pub/sub you can just implement the service in both applications with different end points. When either of the applications is launched it tries to access the other known object via the IPC proxy. If the proxy fails, the other object isn't up.
-Scott
我花了 2 天时间仔细研究了 IPC 的所有可用选项，同时寻找一种可靠、简单且快速的方法来实现全双工 IPC。 我在 Codeplex.com 上找到的 IPCLibrary 到目前为止，在我尝试过的所有选项中都运行得很好。 只需 7 行代码即可完成所有操作。 :D 如果有人在尝试寻找全双工 IPC 时偶然发现这个问题，请尝试一下这个库，这样可以节省大量时间。 获取源代码，编译 data.dll 并按照给出的示例进行操作。
哈特哈，
环路
I've spent 2 days meandering through all the options available for IPC while looking for a reliable, simple, and fast way to do full-duplex IPC. IPCLibrary, which I found on Codeplex.com, is so far working perfectly out of all the options that I tried. All with only 7 lines of code. :D If anyone stumbles across this trying to find a full-duplex IPC, save yourself a ton of time and give this library a try. Grab the source code, compile the data.dll and follow the examples given.
HTH,
Circ
处理 IPC 的方法有很多种（.net 或非 .net），通过 TCP/HTTP 隧道是一种方法……但可能是一个非常糟糕的选择（取决于具体情况和环境）。
共享内存和命名管道是两种方式（是的，它们可以在 .Net 中完成），这两种方式可能对您来说是更好的解决方案。 .Net Framework 中还有 IPC 类...但由于一些 AppDomain 问题，我个人不喜欢它们...
There are many ways to handle IPC (.net or not) and via a TCP/HTTP tunnel is one way...but can be a very bad choice (depending on circumstances and enviornment).
Shared memory and named pipes are two ways (and yes they can be done in .Net) that might be better solutions for you. There is also the IPC class in the .Net Framework...but I personally don't like them due to some AppDomain issues...
为什么不把服务器和客户端分别托管在两边，谁先出现就成为服务器呢？ 如果服务器退出，仍处于活动状态的客户端会切换角色。
Why not host the server and the client on both sides, and whoever comes up first gets to be the server? And if the server drops out, the client that is still active switches roles.
使用共享内存比较困难，因为您必须管理共享内存缓冲区的大小（或者只是预先分配足够的大小）。 您还必须手动管理放入其中的数据结构。 一旦您对其进行了测试并正常工作，由于其简单性，它将更容易使用和测试。
如果您选择远程处理路线，则可以使用 IpcChannel 而不是 TCP 或 HTTP 通道来使用命名管道进行单个系统通信。 http://msdn.microsoft.com/en-us/library/4b3scst2。 .aspx. 此解决方案的问题在于，您需要提出一个注册表类型的解决方案（在共享内存或其他持久存储中），进程可以向其注册其端点。 这样，当您查找它们时，您可以找到一种方法来查询系统上运行的所有端点，并且可以找到您要查找的内容。 使用远程处理的好处是序列化和方法调用都非常简单。 此外，如果您决定转移到网络上的多台计算机，您只需翻转开关即可使用网络通道。 缺点是，除非您明确区分“远程”调用和“本地”调用，否则远程处理可能会令人沮丧。
我对 WCF 不太了解，但这也可能值得研究。 蜘蛛感知说它可能有一个更优雅的解决方案来解决这个问题......也许吧。
或者，您可以创建一个与所有其他进程分开并启动的“服务器”进程（使用系统互斥体确保不会启动多个进程）作为所有进程的中间人和注册中心其他进程。
还有一件事需要研究事件的发布-订阅模型 (Pub/Sub)。 当您有一个在事件源可用之前启动的侦听器，但您不想等待注册事件时，此技术会有所帮助。 “服务器”进程将处理事件注册表以链接发布者和订阅者。
Using shared memory is tougher because you'll have to manage the size of the shared memory buffer (or just pre-allocate enough). You'll also have to manually manage the data structures that you put in there. Once you have it tested and working though, it will be easier to use and test because of its simplicity.
If you go the remoting route, you can use the IpcChannel instead of the TCP or HTTP channels for a single system communication using Named Pipes. http://msdn.microsoft.com/en-us/library/4b3scst2.aspx. The problem with this solution is that you'll need to come up with a registry type solution (either in shared memory or some other persistent store) that processes can register their endpoints with. That way, when you're looking for them, you can find a way to query for all the endpoints that are running on the system and you can find what you're looking for. The benefits of going with Remoting are that the serialization and method calling are all pretty straightforward. Also, if you decide to move to multiple machines on a network, you could just flip the switch to use the networking channels instead. The cons are that Remoting can get frustrating unless you clearly separate what are "Remote" calls from what are "Local" calls.
I don't know much about WCF, but that also might be worth looking into. Spider sense says that it probably has a more elegant solution to this problem... maybe.
Alternatively, you can create a "server" process that is separate from all the other processes and that gets launched (use a system Mutex to make sure more than one isn't launched) to act as a go-between and registration hub for all the other processes.
One more thing to look into the Publish-Subscribe model for events (Pub/Sub). This technique helps when you have a listener that is launched before the event source is available, but you don't want to wait to register for the event. The "server" process will handle the event registry to link up the publishers and subscribers.