Двусторонняя межпроцессная коммуникация

Question

Я работаю над проектом, в котором я хочу иметь плагин-песочницу, такую ​​как System, однако у меня возникают проблемы при разработке двухсторонней межпроцессной коммуникации в реальном времени.Сначала я думал о WCF, так как он может передавать метаданные объекта, но затем вскоре понял, что модель WCF с сервисным клиентом будет представлять проблему.но прежде чем я изложу все свои идеи и вопросы, вот что я запланировал.

Я хочу иметь хост-приложение, которое будет выполнять большую часть работы, давайте назовем этот host.exe, host.exeбудет содержать основную логику приложения для программы, а также запуск, выполнение и уничтожение плагинов.Плагины будут размещаться через прокси-модуль плагина, который будет размещать их через MEF, поэтому мы будем называть его proxy.exe.Proxy.exe будет загружать DLL-плагины и размещать их в изолированной среде, которая изолирует сбои, а в случае сбоя плагина будет убивать прокси, а не приложение.Хост и Прокси-сервер должны обмениваться данными в реальном времени в обоих направлениях, и поскольку будет несколько прокси-хостов, было бы лучше иметь возможность передавать объектные данные.

, так что это основная идея того, чтоя хочу.Я думал о нескольких способах сделать это.первый - WCF, однако я решил, что то, как работает WCF, было бы трудно, если не невозможно, серверу службы отправить клиенту запрос / команду.следующая идея, что использовать TCP, и чтобы хост был TCP-сервером и разработал протокол обмена сообщениями, который я мог бы использовать для связи, однако это создает проблему, поскольку у меня нет роскоши метаданных WCF, и передача информации о сложном классе могла быбудь совершенно безумным.

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

Answer 1

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

Answer 2

Межпроцессное взаимодействие (МПК).То, что, возможно, следует называть межпроцессным взаимодействием (CPC), является известной концепцией MS / Windows.

Подробнее об этом здесь

В прошлом я использовал RPC и Windows Pipes (которые также используются в SQL-сервере для передачи больших наборов данных / результатов)

Вы всегда можете попробовать другой способ связи, WCF, Sockets, Pub / Sub Messaging;Например, TibcoRv (который локально обходил бы сокеты).Я считаю, что это немного излишне.но может быть идеальным для вашего требования.

Answer 3

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

Я хочу предупредить вас заранее.Проект, о котором я упоминаю, был создан довольно давно, так что это может быть устаревшая информация (WCF может делать то же самое или нет). Моя компания не требовала от меня никакой работы WCF.)

Я удаленмои объекты от клиента до сервера.Я бы запустил сервер (фактически на отдельной машине), а затем с помощью удаленного взаимодействия tcp все объекты, которые я хотел бы, были бы объявлены в этом приложении.

Теперь вот самое интересное.этот удаленный объект использовал объекты удаленного делегата.Я бы инициализировал объект (удаленный) и сервер создал бы его.Затем я инициализирую другой объект (тип интерфейса) локально и присоединяю его к удаленному объекту.

Когда удаленный объект хочет связаться со мной, он посылает мне сериализуемую информацию, и я создаю ее в виде большего количества объектов иликоманды.Все, что было нужно ... (возможно, больше удаленных объектов)

В любом случае.Один сервер и несколько удаленных объектов будут отправлены туда и обратно вместе с CommonInterface.dll со всеми стандартными объектами интерфейса, определенными в нем.

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

Если плагин (клиент) падает, то приложение (сервер) не должно пострадать.Это просто обернуло бы все коммуникации с этим плагином в зацепку try, и удаленный объект имел бы какое-то время, чтобы жить или пинговать механизм выпуска стиля.

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

вот сервер чата удаленного взаимодействия .net.

http://www.codeproject.com/KB/IP/dotnetchatapplication.aspx

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