与.NET Remoting的Intrasession通信

我有一个应用程序需要由第二个应用程序调用。这些应用程序需要在没有配置的情况下找到对方（最好不要触摸注册表），并在终端服务环境中正确运行。我听说.net远程使用命名管道可能是一种方法来实现这一点，但我不明白如何限制管道只能在创建它的会话内访问。谢谢与.NET Remoting的Intrasession通信

更新：我很好用WCF，问题不是特定于远程处理，但如何设置命名管道是本地的会话。

来源

2010-02-22 Mitch

C＃远程处理已过时，不再由MS推荐。你应该使用基于WCF服务的通信。 – 2010-02-22 19:25:53

请参阅http://msdn.microsoft.com/en-us/library/72x4h507.aspx：“本主题特定于遗留技术，为保持与现有应用程序的向后兼容性而保留，不建议用于新开发。现在应该使用Windows Communication Foundation（WCF）开发“ – 2010-02-22 19:32:46

如果您的应用程序在Windows Vista或Windows 7上运行，并且您使用的是WCF NetNamedPipeBinding，那么您将自动获得仅在同一会话中可访问的服务。管道没有SeCreateGlobalPrivilege权限。实际上，这通常意味着服务器可以是在交互式会话中启动的任何程序，只要它不以“以管理员身份运行”启动。

之所以这么做，是因为WCF创建的命名共享内存对象将实际管道名称（GUID）发布给潜在客户端。 I explain this mechanism on my blog。如果服务进程具有SeCreateGlobalPrivilege，则此发布对象将在全局内核名称空间中创建，并可供所有会话使用;如果它没有这个特权，则该对象在只在同一个会话中可见的本地内核命名空间中创建。请注意，这不提供绝对的安全性：如果管道名称GUID以某种方式另外披露，命名管道本身理论上可以从另一个会话（使用本机API调用而不是WCF客户端堆栈）进行访问。

如果您需要支持早期的操作系统，或者您希望管道本身具有绝对的安全性，则需要通过在WCF服务通道堆栈创建后在管道上修改DACL来显式实施限制。这需要一些修改标准绑定，我显示how this can be done here。您还需要编写一些P/Invoke代码，这不是特别简单，可以发现在DACL中为其创建ACE的正确登录会话SID。在.NET 4中，WCF服务堆栈本身发现并使用登录会话SID来限制创建新管道实例的权限，因此您可以使用Reflector来查看它是如何实现的 - 请参阅：System.ServiceModel.Channels.SecurityDescriptorHelper.GetProcessLogonSid()。

来源

2011-01-31 11:00:00

我会建议使用Windows Communication Foundation这个。

你必须配置的选项，不使用注册表，所有的不同的通信选项，包括使用命名管道，插座等

来源

2010-02-22 19:25:46

无论使用哪种技术，如何配置一个命名管道用于intrasession通信？ – Mitch 2010-02-22 19:31:33

@Mitch：我不知道如何将管道限制在同一个会话中使用。但是，它不可能在会议之外被无意中使用。这是一个安全问题吗？ – 2010-02-22 19:38:23

它需要被限制的原因不是增加安全性，而是允许多个用户独立地在终端服务器上使用应用程序。 – Mitch 2010-02-22 19:41:44

我一直在寻找这个确切的问题。迄今为止我发现的最好的解决方案（但尚未尝试）是使用session id创建一个唯一的命名管道名称。

来源

2011-01-30 04:48:28 Foole

使用会话ID为端口号。好想法。谢谢 – 2011-07-07 11:04:09

与.NET Remoting的Intrasession通信

回答

相关问题