Я пытался набрать скорость на Named Pipes на этой неделе. Задача, которую я пытаюсь решить с ними, заключается в том, что у меня есть существующая служба Windows, которая действует как драйвер устройства, который направляет данные из внешнего устройства в базу данных. Теперь мне нужно изменить этот сервис и добавить дополнительный пользовательский интерфейс (на том же компьютере, используя форму IPC), который может отслеживать данные, передаваемые между устройством и БД, а также отправлять некоторые команды обратно в сервис. .
Моими первоначальными идеями для IPC были либо именованные каналы, либо файлы с отображением в памяти. До сих пор я работал над идеей именованного канала, используя WCF Tutorial Basic Interprocess Communication . Моя идея состоит в том, чтобы настроить службу Windows с дополнительным потоком, который реализует службу WCF NamedPipe, и использовать ее в качестве канала для внутренних компонентов моего драйвера.
У меня работает пример кода, однако я не могу разобраться с двумя проблемами, которые, я надеюсь, кто-то здесь может мне помочь:
В учебном пособии ServiceHost создается с использованием typeof (StringReverser), а не путем ссылки на конкретный класс. Таким образом, похоже, что у Сервера нет механизма взаимодействия с самой службой (между линиями host.Open () и host.Close ()). Можно ли создать ссылку между и передать информацию между сервером и классом, который фактически реализует службу? Если да, то как?
Если я запускаю один экземпляр сервера, а затем запускаю несколько экземпляров клиентов, кажется, что каждый клиент получает отдельный экземпляр класса обслуживания. Я попытался добавить некоторую информацию о состоянии в класс, реализующий службу, и она была сохранена только в экземпляре именованного канала. Возможно, это связано с первым вопросом, но есть ли способ заставить именованные каналы использовать тот же экземпляр класса, который реализует службу?
Наконец, есть мысли по поводу MMF против Named Pipes?
Редактировать - О решении
Согласно ответу Томасра, решение заключается в использовании правильного конструктора для предоставления конкретного одноэлементного класса, который реализует службу ( ServiceHost Constructor (Object, Uri []) ). В то время я не оценил его упоминание о том, что класс обслуживания является поточно-ориентированным. Простое изменение конструктора вызвало сбой в работе сервера, что в конечном итоге привело меня к пониманию InstanceContextMode из этой записи в блоге Instancecontextmode And Concurrencymode . Установка правильного контекста приятно завершила решение.