WCF именованный канал IPC

На этой неделе я пытался войти в курс дела по именованным каналам. Задача, которую я пытаюсь решить с их помощью, заключается в том, что у меня есть существующая служба windows, которая действует как драйвер устройства, который передает данные с внешнего устройства в базу данных. Теперь я должен изменить эту службу и добавить дополнительный пользовательский интерфейс (на той же машине, используя форму IPC), который может отслеживать данные, когда они проходят между устройством и БД, а также отправлять некоторые команды обратно в службу.

Мой первоначальные идеи для МПК были именованные каналы или отображаемые в память файлы. До сих пор я работал над идеей именованного канала, используя WCF Tutorial Basic Interprocess Communication . Моя идея состоит в том, чтобы установить службу Windows с дополнительным потоком, который реализует службу WCF NamedPipe, и использовать ее в качестве канала к внутренним устройствам моего драйвера.

У меня есть пример кода работает, однако я не могу получить мою голову вокруг 2 вопросов, которые я надеюсь, что кто-то здесь может помочь мне с:

  1. В учебнике ServiceHost создается с помощью typeof (StringReverser), а не путем ссылки на конкретный класс. Таким образом, кажется, что нет никакого механизма для сервера, чтобы взаимодействовать с самой службой (между хостом.Open () и хост.Замкнутая линия). Возможно ли создать связь и передать информацию между сервером и классом, который фактически реализует сервис? Если да, то как?

  2. Если я запускаю один экземпляр сервера а затем запустить несколько экземпляров клиентов, кажется, что каждый клиент получает отдельный экземпляр класса службы. Я попытался добавить некоторую информацию о состоянии в класс, реализующий службу, и она была сохранена только в экземпляре именованного канала. Возможно, это связано с первым вопросом, но можно ли заставить именованные каналы использовать один и тот же экземпляр класса, реализующего службу?

  3. Наконец, любые мысли о MMF vs названы Трубы?

Edit-о решении

Согласно ответу Tomasr, решение заключается в использовании правильного конструктора для предоставления конкретного одноэлементного класса, реализующего service (ServiceHost Constructor (Object, Uri[])). Что я не оценил в то время, так это его ссылку на обеспечение потокобезопасности класса обслуживания. Наивно просто изменение конструктора вызвало сбой в работе сервера, и это в конечном итоге привело меня на путь понимание свойство instancecontextmode из этой записи в блоге свойство instancecontextmode и значения concurrencymode. Установка правильного контекста красиво завершила решение.

1 6
wcf named-pipes

1 ответ:

Для (1) и (2) Ответ прост: вы можете попросить WCF использовать одноэлементный экземпляр вашей службы для обработки всех запросов. В основном все, что вам нужно сделать, это использовать альтернативный конструктор ServiceHost , который принимает экземпляр объекта вместо типа.

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

Что касается 3, то это действительно во многом зависит от того, что вам нужно сделать, от ваших потребностей в производительности, от того, сколько клиентов вы ожидаете одновременно., объем данных, которые вы будете перемещать, и как долго они должны быть доступны, и т. д.

2