blocks|key|2932124|text|为什么不把服务器和客户端放在两端，谁先来谁就是服务器呢？如果服务器退出，仍处于活动状态的客户端将切换角色。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2932125|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|5187882|text|有许多方法可以处理进程间通信(.net或非)，通过TCP/HTTP隧道是一种，way...but可能是一个非常糟糕的选择(取决于环境和环境)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5187883|共享内存和命名管道是两种可能对您更好的解决方案(是的，它们可以在.Net中完成)。由于一些AppDomain问题，我个人不喜欢.Net+Framework...but中的IPC类……|5187884|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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...

blocks|key|5188039|text|使用共享内存比较困难，因为您必须管理共享内存缓冲区的大小(或者只是预先分配足够的内存)。您还必须手动管理放入其中的数据结构。一旦你对它进行了测试和工作，由于它的简单性，它将更容易使用和测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5188040|如果使用远程处理路由，则可以使用命名管道进行单个系统通信，而不是使用IpcChannel或HTTP通道。http://msdn.microsoft.com/en-us/library/4b3scst2.aspx。此解决方案的问题在于，您需要提出一个注册表类型的解决方案(在共享内存或其他持久性存储中)，以便进程可以向其注册其端点。这样，当您查找它们时，您可以找到一种方法来查询系统上运行的所有端点，并且您可以找到您正在查找的端点。使用远程处理的好处是序列化和方法调用都非常简单。此外，如果您决定移动到网络上的多台计算机，则只需翻转开关即可使用网络通道。缺点是，除非您清楚地将什么是“远程”调用与什么是“本地”调用分开，否则远程处理可能会令人沮丧。|offset|length|5188041|我对WCF了解不多，但这可能也值得研究一下。Spider+sense表示，对于这个问题，它可能有一个更优雅的解决方案。也许吧。|5188042|或者，您可以创建一个独立于所有其他进程的“服务器”进程，并启动该进程(使用系统互斥锁确保不会启动多个进程)，以充当所有其他进程的中介和注册中心。|5188043|还有一件事要研究事件的发布-订阅模型(发布/订阅)。当您的侦听器在事件源可用之前启动，但您不想等待注册该事件时，此技术会很有帮助。“服务器”进程将处理事件注册表，以链接发布者和订阅者。|5188044|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/4b3scst2.aspx^0|0|1G|1H|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]]]

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. <a href="http://msdn.microsoft.com/en-us/library/4b3scst2.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/4b3scst2.aspx</a>. 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.

blocks|key|5188146|text|我同意加罗的观点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5188147|使用发布/订阅服务将是一个很好的解决方案。这显然意味着这个服务需要在其他两个服务之前启动和运行。|5188148|如果您想跳过发布/订阅，您可以在两个不同端点的应用程序中实现该服务。当启动这两个应用程序之一时，它会尝试通过IPC代理访问另一个已知对象。如果代理失败，另一个对象就不会启动。|5188149|-Scott|5188150|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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

blocks|key|5188205|text|我花了两天时间研究了可用于IPC的所有选项，同时寻找一种可靠、简单、快速的方式来实现全双工IPC。我在Codeplex.com上找到的IPCLibrary，在我尝试的所有选项中，到目前为止工作得很好。所有这些都只有7行代码。:D如果有人在尝试寻找全双工IPC时遇到这种情况，请节省大量时间，并尝试一下这个库。获取源代码，编译data.dll，然后按照给出的示例进行操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5188206|HTH，圆形|5188207|entityMap|0|LINK|mutability|MUTABLE|url|http://ipclibrary.codeplex.com/^0|1V|A|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

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. <a href="http://ipclibrary.codeplex.com/" rel="nofollow noreferrer">IPCLibrary</a>, 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

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 <a href="http://www.developer.com/net/net/article.php/3520891" rel="nofollow noreferrer">this article</a>. 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?

.NET IPC without having a service mediator

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有两个不相关的进程，它们使用.NET程序集作为插件。但是，这两个进程都可以在任何时候启动/停止。我不能依赖某个特定的进程作为服务器。实际上，其中一个进程可能有多个副本在运行，但另一个进程中只有一个。我最初实现了一个基于的解决方案。但是，这要求实现服务器的服务器在客户端之前运行。当客户端首先运行时，实现对服务器的某种通...

问没有服务中介者的.NET IPC
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问没有服务中介者的.NET IPCEN