Внутрисессионная связь с .NET Remoting

У меня есть приложение, которое должно быть вызвано вторым приложением. Эти приложения должны находить друг друга без настройки (желательно, не затрагивая реестр) и должным образом функционировать в среде служб терминалов. Я слышал, что удаленное взаимодействие .net с использованием именованных каналов может быть способом добиться этого, но я не понимаю, как ограничить доступ к каналу только в рамках сеанса, в котором он был создан. Спасибо

Обновление: меня устраивает WCF, вопрос касается не удаленного взаимодействия, а того, как сделать именованный канал локальным для сеанса.


person Mitch    schedule 22.02.2010    source источник
comment
Удаленное взаимодействие C # устарело и больше не рекомендуется MS. Вы должны использовать связь на основе служб WCF.   -  person David Pfeffer    schedule 22.02.2010
comment
См. msdn.microsoft.com/en-us/library/72x4h507.aspx: этот раздел относится к устаревшей технологии, которая сохраняется для обратной совместимости с существующими приложениями и не рекомендуется для новой разработки. Распределенные приложения теперь должны разрабатываться с использованием Windows Communication Foundation (WCF).   -  person John Saunders    schedule 22.02.2010


Ответы (3)


Если ваше приложение работает в Windows Vista или Windows 7, и вы используете WCF NetNamedPipeBinding, вы автоматически получите службу, доступную только из того же сеанса, при условии, что процесс, реализующий конец службы канала, не имеет привилегия SeCreateGlobalPrivilege. На практике это обычно означает, что сервером может быть любая программа, запущенная в интерактивном сеансе, при условии, что она не запускается с помощью администратора запуска.

Причина, по которой это так, касается именованного объекта общей памяти, который WCF создает для публикации фактического имени канала (GUID) для потенциальных клиентов. Я объясняю этот механизм в своем блоге. Если сервисный процесс имеет SeCreateGlobalPrivilege, этот объект публикации создается в глобальном пространстве имен ядра, видимом для всех сеансов; если у него нет этой привилегии, объект создается в локальном пространстве имен ядра, видимом только в том же сеансе. Обратите внимание, что это не обеспечивает абсолютной безопасности: теоретически к именованному каналу можно получить доступ из другого сеанса (используя собственные вызовы API, а не клиентский стек WCF), если GUID имени канала каким-либо образом был раскрыт другим способом.

Если вам нужно поддерживать более раннюю ОС или если вам нужна абсолютная безопасность на самом канале, вам нужно будет явно реализовать ограничение, изменив DACL на канале после того, как стек канала службы WCF его создал. Для этого потребуется немного поработать со стандартной привязкой, и я покажу , как это можно сделать. здесь. Вам также потребуется написать некоторый код P / Invoke, который не очень прост, чтобы определить правильный SID сеанса входа в систему, для которого нужно создать ACE в DACL. В .NET 4 стек службы WCF сам обнаруживает и использует SID сеанса входа в систему, чтобы ограничить разрешение на создание новых экземпляров канала, поэтому вы можете использовать Reflector, чтобы посмотреть, как он это делает - см .: System.ServiceModel.Channels.SecurityDescriptorHelper.GetProcessLogonSid().

person Chris Dickson    schedule 31.01.2011

Я занимался именно этой проблемой. Лучшее решение, которое я нашел до сих пор (но еще не пробовал), - это создать уникальное имя именованного канала с помощью идентификатор сеанса.

person Foole    schedule 30.01.2011
comment
использовал идентификатор сеанса для номера порта. Отличная идея. Спасибо - person Summer-Time; 07.07.2011

Я бы рекомендовал использовать для этого Windows Communication Foundation.

У вас будет возможность настроить без использования реестра все различные параметры связи, включая использование именованных каналов, сокетов и т. Д.

person Reed Copsey    schedule 22.02.2010
comment
Независимо от используемой технологии, как настроить именованный канал для внутрисессионной связи? - person Mitch; 22.02.2010
comment
@Mitch: Я не знаю способа ограничить использование канала только в рамках одного сеанса. Однако маловероятно, что он будет случайно использован вне сеанса. Это проблема безопасности? - person John Saunders; 22.02.2010
comment
Причина, по которой его необходимо ограничить, заключается не в том, чтобы повысить безопасность, а в том, чтобы позволить нескольким пользователям использовать приложение независимо на сервере терминалов. - person Mitch; 22.02.2010
comment
Именованные каналы по умолчанию могут быть подключены к любому приложению на машине. Если они используются несколькими пользователями, они будут использоваться несколькими процессами - и это хороший вариант. Я бы по-прежнему использовал WCF, но вы можете проверить NamedPipeServerStream для примера использования вручную: msdn.microsoft.com/en-us/library/ - person Reed Copsey; 22.02.2010