Помогите определиться со схемой межпроцессного взаимодействия.
Существует процесс Менеджер. Время жизни этого процесса назовем Сессией.
Менеджер порождает от одного до нескольких многопоточных дочерних процессов. Т.о. за время сессии может существовать (на данный момент последовательно, но возможно и параллельно) несколько однотипных многопоточных дочерних приложений.
Любой из потоков дочернего приложения может отправить запрос Менеджеру. Запросы бывают нескольких типов с различным количеством и типами аргументов. Для примера возьмем запрос определенного файла.
Менеджер обладает кешем данных (для примера - файловым кешем). Если в кеше есть данные соотв-щие запросу, они отправляются дочернему процессу (для примера - путь к файлу). Если в кеше нет соотв. инф., она запрашивается на удаленном сервере, помещается в кеш и передается дочернему процессу. Для примера - файл скачивается по сети, размещается в файловом кеше, и путь до него передается дочернему процессу.
Обращаю внимание, что система многопоточная, а кеш валиден в пределах одной сессии.
Собственно вопрос: как это лучше организовать?
Первой мыслью было: создать именнованный pipe и обеспечить многопоточную обработку запросов в Менеджере. При этом по каналу (pipe) передавать пакеты (message), в которых будет информация о типе запроса, количестве аргументов и сами аргументы.
Другая мысль: создать локальный COM-сервер, клиентами которого станут дочерние процессы, а запросы осуществлять вызовами соотв. методов COM-интерфейса.
Т.е. все проблемы с маршалингом и многопоточностью возложить на технологию COM.
Я не силен в технологии COM, а потому хотелось бы получить Ваши советы, прежде, чем зарываться.
На сколько предпочтительнее получится вторая схема?
Поможет ли она в обеспечении thread-safe?
Как обеспечить "сессионность" в случае с COM? Как это будет выглядеть в случае нескольких сессий одновременно (несколько одновременно запущенных Менеджеров)?
Будет ли логичным (и эффективным) использовать в дальнейшем для связи с удаленным сервером DCOM ?
Может, есть более эффективные схемы для такого взаимодействия?
Поможет ли она в обеспечении thread-safe?
Как обеспечить "сессионность" в случае с COM? Как это будет выглядеть в случае нескольких сессий одновременно (несколько одновременно запущенных Менеджеров)?
Будет ли логичным (и эффективным) использовать в дальнейшем для связи с удаленным сервером DCOM ?
Может, есть более эффективные схемы для такого взаимодействия?
Вторая схема, на мой взгляд более простая и достаточно эффективная, но при ее использовании скорее всего не получиться использовать несколько менеджеров одновременно.
По поводу thread-safe. Да, COM поддерживает различные thread модели. Начиная от жесткой привязки COM объекта к потоку, в котором он создан, заканчивая полным мультитредингом без всякого контроля со стороны COM. Также есть и "промежуточные", которые сами каким-то образом синхронизируются и т.п. :)
Сессионность с одним менеджером обеспечить вообще никаких проблем не составит (загрузился exe-шник в память, началась сессия, выгрузился - закончилась). Также, я не вижу пока способов заставить работать несколько серверов одновременно. COM объекты создаются с помощью гуида и я не вижу возможности указать процесс, в котором должен создаваться объект.
DCOM также можно будет потом спокойно использовать, единственное, что необходимо будет указывать при создании COM объектов: имя удаленной машины.
Теперь укажу, какие преимущества (или недостатки, решай сам) дает использование COM:
1. Локальный сервер стартует автоматически, при первой же попытке какой либо программулины создать его COM объект.
2. Также он может автоматически "умирать", как только "умирает" последний созданный в нем объект (работает до последнего клиента :) ).
3. Может использоваться программой/скриптом, написанной на любом другом языке (конечно, при этом он должен поддерживать COM), блин, да хоть на VBScript в окошечке Internet Explorera :).
4. Возможна поддержка событий, например, может оповещать клиентов только в тот момент, когда файл скачался и не будет необходимости опрашивать менеджера переодически в цикле.
5. Ну и наконец, удобно блин :)
Как оказалось, получится. При этом local server один, но внутри него порождается несколько экземпляров, по одному на сессию.
Но всё же видимо от COM придется отказаться, т.к. дочернее приложение может само по себе использовать COM и могут возникнуть конфликты в способе использования (MTA, STA и т.п.).
Т.е. все проблемы с маршалингом и многопоточностью возложить на технологию COM....
Я не рекомендовал бы использовать технологию COM и производные от нее, если быстродействие критично.
Возможно, мои данные устарели :), но, насколько мне известно, есть in-process COM-серверы (по сути, DLL), а есть выделенные, работающие в отдельном процессе, и как я понимаю, ваше приложение будет именно таким. В таком случае COM-технология удобна, но довольно медлительна.
К тому же, если бы вы писали приложение типа Excel/Word и т. п., которое потенциально может использоваться всеми, имеет смысл создавать COM-сервер, для того они и нужны; в вашем случае, как я понимаю, использоваться ваш сервер будет конкретно вашими же дочерними процессами, т. е. Менеджер не предназначен для работы со сторонними приложениями.
Т.е. все проблемы с маршалингом и многопоточностью возложить на технологию COM....
Я не рекомендовал бы использовать технологию COM и производные от нее, если быстродействие критично.
Возможно, мои данные устарели :), но, насколько мне известно, есть in-process COM-серверы (по сути, DLL), а есть выделенные, работающие в отдельном процессе, и как я понимаю, ваше приложение будет именно таким. В таком случае COM-технология удобна, но довольно медлительна.
К тому же, если бы вы писали приложение типа Excel/Word и т. п., которое потенциально может использоваться всеми, имеет смысл создавать COM-сервер, для того они и нужны; в вашем случае, как я понимаю, использоваться ваш сервер будет конкретно вашими же дочерними процессами, т. е. Менеджер не предназначен для работы со сторонними приложениями.
---
При соответствующем использовании, я уверен, можно реализовать систему с помощью обычных объектов синхронизации, а также каналов (pipe), отображения файлов на память, и даже сокетов. Тем более, что объекты синхронизации, скорее всего, придется использовать в любом случае.
Сокеты удобны тем, что, во-первых, позволят запускать дочерние процессы на удаленных машинах, во-вторых, очень удобно: получили входящий клиентский запрос, тут же запустили поток для его обработки, даже не читая данные из сокета, и мы уже готовы принять следующий клиентский запрос.
Все зависит от требований к производительности, переносимости кода и т. д.