Какой способ IPC выбрать, если нужно передать данные (небольшой массив)
для еще не существующего процесса? При этом этого процесса может и не
быть вовсе.. Почитав статьи единственное подходящее на мой взгляд
Microsoft Message Queue, но возможно что-то попроще можно придумать?
Идеальный вариант для меня — это средство IPC позволяющее в асинхронном режиме
передавать данные, организованное как стек (последний пришёл — первый вышел).
При этом обмен должен происходить между разными процессами одного компьютера.
Спасибо.

Здравствуйте, Аноним, Вы писали:

А>Какой способ IPC выбрать, если нужно передать данные (небольшой массив)
А>для еще не существующего процесса? При этом этого процесса может и не
А>быть вовсе.. Почитав статьи единственное подходящее на мой взгляд
А>Microsoft Message Queue, но возможно что-то попроще можно придумать?
А>Идеальный вариант для меня — это средство IPC позволяющее в асинхронном режиме
А>передавать данные, организованное как стек (последний пришёл — первый вышел).
А>При этом обмен должен происходить между разными процессами одного компьютера.

Ещё можно в файл писать

Здравствуйте, SergH, Вы писали:

SH>Ещё можно в файл писать
Да, думал над этим — решил подумать еще

Здравствуйте, Аноним, Вы писали:

А> Да, думал над этим — решил подумать еще
Забыл аргументировать — не хочется чтобы что-то оставалось от работы, т.е. созданый файл могут и не прочитать/удалить.

Здравствуйте, Аноним, Вы писали:

А> Забыл аргументировать — не хочется чтобы что-то оставалось от работы, т.е. созданый файл могут и не прочитать/удалить.

Ну тут идея такая: чтобы сообщение шло асинхронно, оно должно где-то хранится. Есть встроенные механизмы: файлы, реестр, MSMQ. Пожалуй всё. Есть базы данных. Есть самопальные решения — навалять сервис, который будет работать промежуточным хранилищем.

Других вариантов я пока не вижу.

>но возможно что-то попроще можно придумать?
можно поизвращаться — находим процесс, который создал окно GetDesktopWindow(), выделяем в нём память, пишем туда, чего надо, и назначаем адрес этой памяти в качестве какого-нть GUID-named свойства окну GetDesktopWindow() ...

правда,
0. нужно выяснить, является ли указатель на память выделенную VirtualAllocEx, переносимым между процессами
1. если память будет не востребована, то она может так и болтаться бесхозной...
2. не факт, что всегда будет доступ к процессу, который создал десктоп

Здравствуйте, Вумудщзук, Вы писали:

В>0. нужно выяснить, является ли указатель на память выделенную VirtualAllocEx, переносимым между процессами

Является.

В>1. если память будет не востребована, то она может так и болтаться бесхозной...
В>2. не факт, что всегда будет доступ к процессу, который создал десктоп

Имхо, решение только для админа.

Здравствуйте, Вумудщзук, Вы писали:

В> выделяем в нём память, пишем туда, чего надо
Не поверите, пробовал ^^^^^^^^^^ На этом этапе фаервол говорит что процесс А пытается записать
данные в АП процесса Б (если Б имеет доступ к сети, т.е. для него создано правило).

> Не поверите, пробовал ^^^^^^^^^^ На этом этапе фаервол говорит что процесс А пытается записать
> данные в АП процесса Б (если Б имеет доступ к сети, т.е. для него создано правило).
а, точно... вот гадство-то ? а зачем, интересно, процессу csrss.exe доступ к сети?

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

Здравствуйте, Вумудщзук, Вы писали:

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

Страсти какие! Драйвер! Зачем же так жестоко-то? Максимум — сервис.

>Страсти какие! Драйвер! Зачем же так жестоко-то? Максимум — сервис.
пасему жестоко ? пара строчек кода буквально... да и это всего лишь идея, чтоб топиккреатору было, из чего выбирать, раз в файлы/реестр писать не хочет

Здравствуйте, <Аноним>, Вы писали:

А>Какой способ IPC выбрать, если нужно передать данные (небольшой массив)
А>для еще не существующего процесса?

dll с shared секцией данных — разделяется между процессами. Или MMF.

Hello gear nuke, you wrote:

> dll с shared секцией данных — разделяется между процессами. Или MMF.

Зачем? На уровне ядра и так общее адресное пространство.

--
Всего хорошего, Слава
ICQ: 197577902

Здравствуйте, Slava Antonov, Вы писали:

SA>Зачем? На уровне ядра и так общее адресное пространство.

Не понял, откуда ядро

обмен должен происходить между разными процессами одного компьютера.

Hello gear nuke, you wrote:

>> Зачем? На уровне ядра и так общее адресное пространство.
> Не понял, откуда ядро

Возможно я глюкнул
Надо патч поставить.

--
Всего хорошего, Слава
ICQ: 197577902

>dll с shared секцией данных — разделяется между процессами. Или MMF.
это если в какой-то момент они оба работают, а (насколько я понял ), может быть ситуация, когда один запустился, отработал, завершился, и только после него стартует второй

Здравствуйте, Abandoned, Вы писали:

>>dll с shared секцией данных — разделяется между процессами. Или MMF.
A>это если в какой-то момент они оба работают, а (насколько я понял ), может быть ситуация, когда один запустился, отработал, завершился, и только после него стартует

Вообще-то, в этой ситуации самым простым (IMHO), представлявляется создание отдельного
приложения (пусть даже и не сервиса), обученного отдавать оные данные (LIFO)
по запросу, скажем, в ответ на SendMessage (и, например, хендл mmf).

В>>0. нужно выяснить, является ли указатель на память выделенную VirtualAllocEx, переносимым между процессами

SH>Является.

Это как? Память будет доступна только в адресном пространстве процесса, где она выделена. Максимум, что можно — это MMF.
Кстати, неплохое решение проблемы — именованый MMF. А еще лучше — ком сервер, который атоматически создается при первом обращении к соотв. функциям записи\чтения. Мы так делали, работало неплохо.

Здравствуйте, Andrew S, Вы писали:

В>>>0. нужно выяснить, является ли указатель на память выделенную VirtualAllocEx, переносимым между процессами

SH>>Является.

AS>Это как? Память будет доступна только в адресном пространстве процесса, где она выделена.

Конечно. Учти контекст, в котором задовался вопрос.

можно поизвращаться — находим процесс, который создал окно GetDesktopWindow(), выделяем в нём память, пишем туда, чего надо, и назначаем адрес этой памяти в качестве какого-нть GUID-named свойства окну GetDesktopWindow() ...

Т.е. алгоритм чтения — прочитать свойство, получить адрес, читать память процесса, в котором она выделена. А вопрос про переносимость адреса между процессами, насколько я понимаю, заключался в следующем: правда ли, что один и тот же кусок адресного пространства процесса виден всеми снаружи по одному и тому же адресу. Я написал что правда.

AS>Кстати, неплохое решение проблемы — именованый MMF.

Оно не до конца асинхронное.

AS>А еще лучше — ком сервер, который атоматически создается при первом обращении к соотв. функциям записи\чтения. Мы так делали, работало неплохо.

Поясни, не понял.

Здравствуйте, Аноним, Вы писали:

А>Какой способ IPC выбрать, если нужно передать данные (небольшой массив)
А>для еще не существующего процесса? При этом этого процесса может и не
А>быть вовсе.. Почитав статьи единственное подходящее на мой взгляд
А>Microsoft Message Queue, но возможно что-то попроще можно придумать?
А>Идеальный вариант для меня — это средство IPC позволяющее в асинхронном режиме
А>передавать данные, организованное как стек (последний пришёл — первый вышел).
А>При этом обмен должен происходить между разными процессами одного компьютера.
А>Спасибо.

Предлагаю радикальное решение: использовать COM
Напишите небольшую программу сервер куда будут поступать данные.
А другие будут подключаться к этому серверу (через COM Remoting) и брать то что нужно.
Преимущество у этого решения в том что не нужно заморачиваться с тем как передавать данные, все автоматически будет за вас.

SH>Т.е. алгоритм чтения — прочитать свойство, получить адрес, читать память процесса, в котором она выделена. А вопрос про переносимость адреса между процессами, насколько я понимаю, заключался в следующем: правда ли, что один и тот же кусок адресного пространства процесса виден всеми снаружи по одному и тому же адресу. Я написал что правда.

Неоднократно видел упоминания, что на какой-то из систем с последним сервис паком ReadProcessMemory не работает. По крайней мере, у меня сложилось впечатление, что это _очень_ неправильное решение, и оно _ничем_ не лучше MMF.

AS>>Кстати, неплохое решение проблемы — именованый MMF.

SH>Оно не до конца асинхронное.

Ровно так же, как и ReadProcessMemory. А применительно к Com серверу — вполне асинхронное. Просто надо _уметь_

AS>>А еще лучше — ком сервер, который атоматически создается при первом обращении к соотв. функциям записи\чтения. Мы так делали, работало неплохо.

SH>Поясни, не понял.

Все просто. Создается некий ком сервер-синглтон (не inproc, естественно). Соответственно, он и занимается менеджментом очереди сообщений, которая может быть представлена как в виде MMF, так и виде любой базы данных. Реализовать ком сервер на ATL не просто, а очень просто. Для интерфеса с ним делается несколько функций (чтения сообщений и помещения сообщений в очередь), которые и создают экземпляр сервера при необходимости. Просто и эффективно.

Здравствуйте, Andrew S, Вы писали:

AS>Неоднократно видел упоминания, что на какой-то из систем с последним сервис паком ReadProcessMemory не работает. По крайней мере, у меня сложилось впечатление, что это _очень_ неправильное решение, и оно _ничем_ не лучше MMF.

Согласен. Я его и не советовал.

AS>Все просто. Создается некий ком сервер-синглтон (не inproc, естественно). Соответственно, он и занимается менеджментом очереди сообщений, которая может быть представлена как в виде MMF, так и виде любой базы данных. Реализовать ком сервер на ATL не просто, а очень просто. Для интерфеса с ним делается несколько функций (чтения сообщений и помещения сообщений в очередь), которые и создают экземпляр сервера при необходимости. Просто и эффективно.

А, ну это понятно. Прсото вынесение в отдельную службу, с использованием COM в качестве транспорта. Я думал что-то хитрое

>Неоднократно видел упоминания, что на какой-то из систем с последним сервис паком ReadProcessMemory не работает. По крайней мере, у меня сложилось впечатление, что это _очень_ неправильное решение, и оно _ничем_ не лучше MMF.
в вопросе речь (как мне кажется) шла о возможности передать данные из одного процесса в другой, причём этот второй процесс может быть запушен после завершения первого, то есть в какой-то момент времени первый уже завершился, а второй ещё не стартовал... как в таком случае использовать MMF, если с завершением процесса все хэндлы/мэппинги удаляются автоматически?

просто так передать данные между процессами, конечно, проблем не вызывает... можно даже без mmf — просто через wm_copydata послать (по условию объём данных небольшой)

>>Неоднократно видел упоминания, что на какой-то из систем с последним сервис паком ReadProcessMemory не работает. По крайней мере, у меня сложилось впечатление, что это _очень_ неправильное решение, и оно _ничем_ не лучше MMF.
A>в вопросе речь (как мне кажется) шла о возможности передать данные из одного процесса в другой, причём этот второй процесс может быть запушен после завершения первого, то есть в какой-то момент времени первый уже завершился, а второй ещё не стартовал... как в таком случае использовать MMF, если с завершением процесса все хэндлы/мэппинги удаляются автоматически?

Народ, ну вы что, издеваетесь. Сколько раз повторять, что предлагаемое решение — использовать Com сервер и MMF только в его рамках.

A>просто так передать данные между процессами, конечно, проблем не вызывает... можно даже без mmf — просто через wm_copydata послать (по условию объём данных небольшой)

Это все равно будет через MMF, хотя и неявно.
Еще есть mailslots, кстати. Но глючные до безобразия, не рекомендую.