與.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通信

回答

相關問題