Добрый день.
Есть windows сервис который должен уведомлять десктопные приложения о смене своего статуса.
Раньше использовались передача сообщений через:
RegisterWindowMessage, EnumWindows, PostMessage.
Но в новых версиях Windows была введена разная безопасность, сервисы и приложения разнести по разным уровням и сообщения перестали доходить.
После пересылка была сделана через mailslot, она работала нормально.
Но теперь потребовалось чтобы несколько приложений получало статус, а mailslot с нужным именем можно создать только один, соответственно и только одно приложение получает сообщения.
Вопрос: какой механизм лучше использовать для рассылки от сервиса нескольким приложениям маленьких сообщений?
Здравствуйте, tryAnother, Вы писали:
A>RegisterWindowMessage, EnumWindows, PostMessage. A>Но в новых версиях Windows была введена разная безопасность, сервисы и приложения разнести по разным уровням и сообщения перестали доходить.
Есть же и функции для подавления этой изоляции: ChangeWindowMessageFilter/ChangeWindowMessageFilterEx.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>pipes, sockets
pipes работают 1-1, а мне нужно от одного ко многим
sockets да, этот вариант я рассматривал, тут потребуется написать небольшой сервер, который обслуживает подключения клиентов
имеется небольшая проблема с выбором порта, он должен быть статический, чтобы и сервис и приложения имели к нему доступ, но может оказаться кем то уже занят в системе (проблема маловероятная конечно).
Можно было бы задать динамический выбор порта (bind(0)), но как передать его клиентам.
PD>Полный список IPC тут
я с ним знаком, не ясно что использовать для данного конкретного случая
PD>Буфер обмена PD>Копирование данных PD>DDE PD>COM
как это все использовать из сервиса в моем случае?
PD>Сопоставление файлов
В этом варианте потребуется периодический опрос из приложений и синхронизация доступа?
Возможно вариант, но не очень красивый.
Изоляция процессов тут не помешает?
PD>Mailslots PD>Каналы
не работают в режиме от одного ко многим
PD>RPC
Не сталкивался с RPC, но судя по описанию тоже не очень подходящий вариант, для получения статуса клиентам нужно постоянно опрашивать сервис.
PD>Сокеты Windows
остается этот, или периодический опрос, или делать TCP сервер c сессиями на каждого клиента
Здравствуйте, tryAnother, Вы писали:
A>pipes работают 1-1, а мне нужно от одного ко многим
Ну не совсем.
The simplest pipe server creates a single instance of a pipe, connects to a single client, communicates with the client, disconnects from the client, closes the pipe handle, and terminates. However, it is more common for a pipe server to communicate with multiple pipe clients. A pipe server could use a single pipe instance to connect with multiple pipe clients by connecting to and disconnecting from each client in sequence, but performance would be poor. The pipe server must create multiple pipe instances to efficiently handle multiple clients simultaneously.
Например, SQL Server на локальной машине может взаимодействовать с локальными же клиентами через pipe (с удаленными только через сокеты). А он сервис, и клиентов может быть очень много.
Придется.
A>имеется небольшая проблема с выбором порта, он должен быть статический, чтобы и сервис и приложения имели к нему доступ,
Или указать его в настройках сервиса, в реестре.
>но может оказаться кем то уже занят в системе (проблема маловероятная конечно).
Теоретически может, но если брать из старшей половины, то вряд ли.
A>Можно было бы задать динамический выбор порта (bind(0)), но как передать его клиентам.
Через реестр.
PD>>Полный список IPC тут
A>я с ним знаком, не ясно что использовать для данного конкретного случая
PD>>Буфер обмена PD>>Копирование данных PD>>DDE PD>>COM
A>как это все использовать из сервиса в моем случае?
Буфер обмена — едва ли. Не уверен, что он вообще не привязан в window station, а сервис и приложение работают на разных window station. Кроме того, его может изменить любая программа , тот же Paint загонит туда картинку.
Копирование данных — довольно просто в теории, WM_COPYDATA . Но не уверен, что пройдет между разными window station. Не пробовал.
COM — не для этого случая, слишком много работы
PD>>Сопоставление файлов
A>В этом варианте потребуется периодический опрос из приложений и синхронизация доступа?
Или Event, сигнализирующий, что данные изменились.
A>Возможно вариант, но не очень красивый. A>Изоляция процессов тут не помешает?
Не в курсе.
PD>>Mailslots PD>>Каналы
A>не работают в режиме от одного ко многим
PD>>RPC
A>Не сталкивался с RPC, но судя по описанию тоже не очень подходящий вариант, для получения статуса клиентам нужно постоянно опрашивать сервис.
Слишком тяжелая артиллерия.
PD>>Сокеты Windows
A>остается этот, или периодический опрос, или делать TCP сервер c сессиями на каждого клиента
A>>Можно было бы задать динамический выбор порта (bind(0)), но как передать его клиентам.
PD>Через реестр.
Если задача состоит только в том, чтобы сообщить текущий статус сервиса (без истории) то его и можно записывать в некий заранее определенный ключ реестра.
А заинтересованые приложения будут оттуда читать (периодически или через RegNotifyChangeKeyValue).
PD>>Через реестр.
M>Если задача состоит только в том, чтобы сообщить текущий статус сервиса (без истории) то его и можно записывать в некий заранее определенный ключ реестра. M>А заинтересованые приложения будут оттуда читать (периодически или через RegNotifyChangeKeyValue).
Как вариант сойдет, но не очень хорошее решение. Не для этого реестр.
Можно ведь тогда и просто через некоторый файл и FindFirstChangeNotification или ReadDirectoryChangesW. Тоже решение.
PD>Как вариант сойдет, но не очень хорошее решение. Не для этого реестр. PD>Можно ведь тогда и просто через некоторый файл и FindFirstChangeNotification или ReadDirectoryChangesW. Тоже решение.
Да, и файл тоже. Но файл может быть заблокирован некоторым процессом, в отличие от registry key/value.
PD>А настоящий IPC — лучше все-таки pipe или socket.
Из этих двух вариантов, думаю, pipe будет проще, т.к. поддерживает message режим, помимо stream режима.
Здравствуйте, m2user, Вы писали:
M>Да, и файл тоже. Но файл может быть заблокирован некоторым процессом, в отличие от registry key/value.
Ну поскольку этот файл будет доступен только сервису и приложению, то сделай, чтобы не заблокировался.
PD>>А настоящий IPC — лучше все-таки pipe или socket.
M>Из этих двух вариантов, думаю, pipe будет проще, т.к. поддерживает message режим, помимо stream режима.
Да, если речь идет о небольших сообщениях, то message mode, видимо, подойдет лучше всего.
Но почитай про права доступа. Сервис и приложение работают на разных window station. К тому же сервис, скорее всего, запущен не от юзера, а от Local System (хотя можно и от юзера). Так что, возможно, придется кое-что в этом плане настраивать.
PD>>>Через реестр.
M>>Если задача состоит только в том, чтобы сообщить текущий статус сервиса (без истории) то его и можно записывать в некий заранее определенный ключ реестра. M>>А заинтересованые приложения будут оттуда читать (периодически или через RegNotifyChangeKeyValue).
PD>Как вариант сойдет, но не очень хорошее решение. Не для этого реестр.
Тем не менее, performance counters именно в реестр пишутся, например.
Здравствуйте, flаt, Вы писали:
f> PD>Как вариант сойдет, но не очень хорошее решение. Не для этого реестр.
f> Тем не менее, performance counters именно в реестр пишутся, например.
Нет, перфкаунтеры в реестр не пишутся. Перфкаунтеры читаются из hkey_performance_data, но это фейковый раздел, данные которого формируются путем опроса dll'ек зарегистрированных в качестве источников данных о производительности.
Здравствуйте, rudzuk, Вы писали:
f>> Тем не менее, performance counters именно в реестр пишутся, например.
R>Нет, перфкаунтеры в реестр не пишутся. Перфкаунтеры читаются из hkey_performance_data, но это фейковый раздел, данные которого формируются путем опроса dll'ек зарегистрированных в качестве источников данных о производительности.
Ну и кроме того, это данные для неопределенного круга потребителей, а не для взаимодействия процессов
Здравствуйте, rudzuk, Вы писали:
R>Нет, перфкаунтеры в реестр не пишутся. Перфкаунтеры читаются из hkey_performance_data, но это фейковый раздел, данные которого формируются путем опроса dll'ек зарегистрированных в качестве источников данных о производительности.
Performance data is not actually stored in the registry. Calling the registry functions causes the system to collect the data from the appropriate performance data provider.
