Двухсторонняя кросс-коммуникация
Я работаю над проектом, в котором я хочу иметь плагин-песочницу, такую как System, однако у меня возникают проблемы при разработке двухсторонней межпроцессной коммуникации в реальном времени. Сначала я думал о WCF, так как он может передавать метаданные объекта, но потом вскоре понял, что модель WCF Service Client создаст проблему. но прежде чем я изложу все свои идеи и вопросы, вот что я спланировал.
Я хочу иметь хост-приложение, которое будет выполнять большую часть работы, давайте назовем это host.exe, host.exe будет содержать основную логику приложения для программы, а также запуск, выполнение и уничтожение плагинов. Плагины будут размещаться через прокси-модуль плагина, который будет размещать их через MEF, поэтому мы будем называть его proxy.exe. Proxy.exe будет загружать библиотеки подключаемых модулей и размещать их в изолированной среде, которая изолирует сбои, а в случае отказа подключаемого модуля будет отключен прокси-сервер, а не приложение. Хост и Прокси должны обмениваться данными в реальном времени в обоих направлениях, и, поскольку будет несколько хостов прокси, было бы лучше иметь возможность передавать данные объекта.
так что это основная идея того, что я хочу. Я думал о нескольких способах сделать это. первый - WCF, однако я решил, что то, как работает WCF, было бы трудно, если не невозможно, серверу службы отправить клиенту запрос / команду. следующая идея, что использовать TCP, и чтобы хост был TCP-сервером и разработал протокол обмена сообщениями, который я мог бы использовать для связи, однако это создает проблему, поскольку у меня нет роскоши метаданных WCF, и передача информации о сложном классе могла бы быть вниз безумным.
На протяжении всего моего исследования, которое я придумывал, проблема за проблемой, было бы очень полезно, если бы кто-нибудь смог предложить решение этой проблемы. Спасибо.
3 ответа
Моим решением для этого, вероятно, будет удаленное взаимодействие. Я не знаю, если WCF делает это так же. но удаленное взаимодействие можно настроить с помощью текста, а серверы можно настроить для удаленного доступа к объекту по желанию.
Я хочу предупредить вас заранее. Проект, о котором я упоминаю, был создан довольно давно, поэтому это может быть устаревшая информация (WCF может делать то же самое или нет). Моя компания не требовала от меня никакой работы WCF.)
Я удалил свои объекты с клиента на сервер. Я бы запустил сервер (на самом деле на отдельной машине), а затем с помощью удаленного взаимодействия tcp все нужные объекты были бы объявлены в этом приложении.
Теперь вот самое интересное. этот удаленный объект использовал объекты удаленного делегата. Я бы инициализировал объект (удаленный) и сервер создал бы его. Затем я бы инициализировал другой объект (тип интерфейса) локально и прикрепил бы его к удаленному объекту.
Когда удаленный объект хочет связаться со мной, он посылает мне сериализуемую информацию, и я превращаю ее в большее количество объектов или команд. Все, что было нужно... (возможно, больше удаленных объектов)
Во всяком случае. Один сервер и несколько удаленных объектов будут отправлены туда и обратно вместе с CommonInterface.dll со всеми стандартными объектами интерфейса, определенными в нем.
Для всех намерений и целей это была скрытая установка плагинов, которую любое приложение, желающее получить информацию на мой сервер или с него, могло бы реализовывать и обрабатывать свои классы при условии соответствия интерфейсов. (с сериализуемыми данными команды)
Если плагин (клиент) падает, то приложение (сервер) не должно пострадать. Это просто обернуло бы все коммуникации с этим плагином в попытку, и у удаленного объекта было бы какое-то время, чтобы жить или пинговать механизм выпуска стиля.
Я действительно не знаю, каким будет ваш сценарий с песочницей, но это может выполнить то, что вы просите.
Здесь находится чат-сервер.net.
http://www.codeproject.com/KB/IP/dotnetchatapplication.aspx
Это тот же тип проекта, который я строил в первый раз с удаленным взаимодействием. и я превратил его в архитектуру моего плагина сервера. Разница между моим использованием и вашим заключается в том, что сервер был моим клиентом и был основным приложением, использующим сервер, а ваш сервер будет основным приложением, позволяющим подключаться нескольким клиентам.
Межпроцессное взаимодействие (МПК). То, что, возможно, следует называть межпроцессным взаимодействием (CPC), является известной концепцией MS/Windows.
Подробнее об этом здесь
В прошлом я использовал RPC и Windows Pipes (которые также используются в SQL-сервере для передачи больших наборов данных / результатов)
Вы всегда можете попробовать другой способ связи, WCF, Sockets, Pub/Sub Messaging; Например, TibcoRv (который локально обходил бы сокеты). Я считаю, что это немного излишне. но может быть идеальным для вашего требования.
На мой взгляд, я советую вам использовать разные домены приложений, общаться с плагинами с помощью интерфейсов и ссылки на реальные прокси-объекты. Не используйте разные процессы, вы можете добиться изоляции плагинов через изоляцию домена приложения, поскольку исключения не пересекают границы домена приложения, если не указано иное.
В качестве альтернативы вы можете использовать устаревшие технологии, такие как.NET Remoting, для маршалинга и создания прозрачных прокси-объектов.
На мой взгляд, WCF слишком тяжелый и слишком далек от обработки в реальном времени.