Подскажите плиз IPC работающий между приложениями на одной машине но запущенных под разными пользователями.
Оба процесса не оконные. Один запущен под Local Service второй под пользовательским аккаунтом.
boost::message_queue и SendThreadMessage к сожалению работают только под одним пользователем.
Буду очень признателен за ответ.
Сообщения короткие, не частые.
Здравствуйте, Denys V., Вы писали:
DV>Подскажите плиз IPC работающий между приложениями на одной машине но запущенных под разными пользователями. DV>Оба процесса не оконные. Один запущен под Local Service второй под пользовательским аккаунтом. DV>boost::message_queue и SendThreadMessage к сожалению работают только под одним пользователем. DV>Буду очень признателен за ответ. DV>Сообщения короткие, не частые.
Наиболее простые и эффективные механизмы IPC в Windows — это каналы (Pipes) и отображаемые в
память файлы (Memory Mapped Files, MMF). Оба реализованы через разделяемую память и при
правильном использовании дают максимальную скорость обмена данными.
При использовании канала все, что требуется — создать его, настроить безопасность и
прокинуть один из его концов нужному процессу, после чего можно будет читать и писать данные
функциями ReadFile и WriteFile. Возможен и вариант с открытием по имени (Named Pipes).
При использовании MMF все еще "веселее" — будет выдана область памяти, отображаемая в
адресные пространства нескольких процессов, все вносимые одним процессом изменения будут
сразу же видны другим, и т.д. Синхронизировать доступ придется при помощи других глобальных
объектов, таких как мьютексы, события или семафоры. Единственный, но серъезный минус в
том, что начиная с Windows Vista, создавать MMF в глобальном пространстве имен (а иначе
он не будет разделяться между сессиями) могут лишь системные службы и члены группы
"Администраторы", и это накладывает определенные архитектурные ограничения.
Для обмена между приложениями в стиле ООП можно соорудить глобальный COM-синглтон.
При условии, что нет жестких требований к производительности и есть определенные знания в
данной области. Реализация будет немного тяжеловатой, но получаемые удобства часто
перевешивают этот фактор. Зато получаем "из коробки" синхронизацию, безопасность,
сериализацию данных (при условии, что они все COM-совместимые) и т.д.
Еще люди советуют использовать "голый" RPC. Сам не пробовал, поэтому ничего толком сказать не могу.
Документации по этой теме мало, последняя актуальная литература выходила в начале двухтысячных.
O>Единственный, но серъезный минус в O>том, что начиная с Windows Vista, создавать MMF в глобальном пространстве имен (а иначе O>он не будет разделяться между сессиями) могут лишь системные службы и члены группы O>"Администраторы", и это накладывает определенные архитектурные ограничения.
А под глобальным пространством имен подразумевается "Global\\Мое_имя_MMF_файла"? Соответственно для "Local\\*" этих ограничений нет!?! Я правильно понял?
Здравствуйте, Carc, Вы писали:
C>А под глобальным пространством имен подразумевается "Global\\Мое_имя_MMF_файла"? Соответственно для "Local\\*" этих ограничений нет!?! Я правильно понял?
Да, правильно. Для создания MMF в глобальном пространстве имен (Global\MyMMF) необходима
привилегия SeCreateGlobalPrivilege ("Создание глобальных объектов"). До Windows Vista эта
привилегия была у служб, администраторов и интерактивных пользователей. Начиная с Vista,
группу "Интерактивные" из этого списка изъяли.
Здравствуйте, Denys V., Вы писали:
DV>Подскажите плиз IPC работающий между приложениями на одной машине но запущенных под разными пользователями. DV>Оба процесса не оконные. Один запущен под Local Service второй под пользовательским аккаунтом. DV>boost::message_queue и SendThreadMessage к сожалению работают только под одним пользователем. DV>Буду очень признателен за ответ. DV>Сообщения короткие, не частые.
Сокеты. Только надо помнить, что
1) Services that run as the Local Service account access network resources as a null session without credentials.
2) Трафик между локальными портами будет передаваться напрямую, без спуска на уровень драйверов, поэтому WireShark ничего не нанюхает (разве что у Вас две сетевухи, и посыл идёт с IP+порта одной на IP+порт другой).
Здравствуйте, Mr.Delphist, Вы писали:
MD>2) Трафик между локальными портами будет передаваться напрямую, без спуска на уровень драйверов, ...
Это не совсем так.
Часть стека TCP/IP находится в ядре (конкретно — tcpip.sys/tdx.sys) и данные,
отправленные на localhost, проходят через эти драйвера. Хотя до уровня драйверов
сетевой карты (NDIS) они не дойдут. Поэтому переключений в ядро при использовании
сокетов избежать не удастся.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, Mr.Delphist, Вы писали:
MD>>2) Трафик между локальными портами будет передаваться напрямую, без спуска на уровень драйверов, ...
O>Это не совсем так. O>Часть стека TCP/IP находится в ядре (конкретно — tcpip.sys/tdx.sys) и данные, O>отправленные на localhost, проходят через эти драйвера. Хотя до уровня драйверов O>сетевой карты (NDIS) они не дойдут. Поэтому переключений в ядро при использовании O>сокетов избежать не удастся.
Угу, спасибо за уточнение — а то я так по-рабоче-крестьянски изложил, в самом деле может кого спутать.
Здравствуйте, Mr.Delphist, Вы писали:
MD> Сокеты. Только надо помнить, что MD> 1) Services that run as the Local Service account access network resources as a null session without credentials. MD> 2) Трафик между локальными портами будет передаваться напрямую, без спуска на уровень драйверов, поэтому WireShark ничего не нанюхает (разве что у Вас две сетевухи, и посыл идёт с IP+порта одной на IP+порт другой).
Интерессно. В плане, что это проще всего.
А как насчет файервола? для localhost не прийдется создавать правило?
Здравствуйте, Denys V., Вы писали:
DV>Здравствуйте, Mr.Delphist, Вы писали:
MD>> Сокеты. Только надо помнить, что MD>> 1) Services that run as the Local Service account access network resources as a null session without credentials. MD>> 2) Трафик между локальными портами будет передаваться напрямую, без спуска на уровень драйверов, поэтому WireShark ничего не нанюхает (разве что у Вас две сетевухи, и посыл идёт с IP+порта одной на IP+порт другой).
DV>Интерессно. В плане, что это проще всего. DV>А как насчет файервола? для localhost не прийдется создавать правило?
Насколько помню, виндовый файервол стреляет в момент bind() — так что зависит от адреса. Надо пробовать.
