следующее пытается получить представление о том, какие технологии будут подходить для конкретной (как обрисовано в общих чертах) распределенной / RPC-проблемы. Если что-то не понятно, я очень рад добавить больше подробностей, но, пожалуйста, запросите их в комментарии , а не в "ответе". Спасибо.
Сначала я опишу текущую ситуацию, а затем последую за тем, чего мы хотим достичь, и актуальным вопросом. Несмотря на то, что это довольно длинный пост, чтобы получить некоторый контекст, сам вопрос довольно короткий (см. В конце).
Вызов приложения Split
Описание приложения:
Приложение позволяет пользователю настроить несколько аппаратных устройств (*)
а затем общаться с ними, чтобы контролировать и собирать измерения
каналы физического эксперимента.
(*) Аппаратные устройства включают датчики температуры, датчики давления,
двигатели, ... Диапазон связи от последовательного порта связи,
TCP / UDP связь для взаимодействия с драйверами сторонних производителей
плагин карты.
Управление включает в себя отправку команд различным аппаратным устройствам.
настроить их в соответствии с протоколами, которые они поддерживают.
Измерение включает получение данных от (некоторых) этих устройств.
Нам трудно держать все как клиенты
требовать все больше и больше каналов с более высокой частотой дискретизации, и мы должны
не отставайте от записи данных + временных меток, которые мы получаем со всех устройств на
диск, отображать подмножество данных и по-прежнему держать систему
отвечает правильно.
Текущая ситуация:
[ DisplayAndControl.exe ]
|| /\
|| DLL Interface ||
|| || Window Messages (SendMessage, PostMessage)
|| ||
\/ ||
[ ChannelManager.dll ]
Краткое описание текущей ситуации:
Приложение на данный момент уже несколько модульное
в том, что (основной) исполняемый файл выполняет отображение + взаимодействие и
(одна из нескольких) DLL осуществляет управление данными (сохранение живых данных
на диск, связь с устройствами и т. д.)
Из представления POV, кстати, связь. модуль дисплея и
модуль управления данными на данный момент оптимально работает.
Новая ситуация:
[ DisplayAndControl.exe ]
|| /\
|| ? RPC/Messaging ||
|| || ? RPC/Messaging
|| ||
\/ ||
[ ChannelManager.exe (same PC or another) ]
Краткое описание предполагаемой новой ситуации:
По соображениям удобства использования, производительности и безопасности мы хотим разделиться
это приложение Windows на два отдельных приложения, так что
чувствительный к производительности (и безопасности) модуль ChannelManager может работать как
возможно, отдельный процесс на отдельном ПК с Windows.
Дополнительно , так как мы уже собираемся разделить это, мы будем
разрешить несколько приложений DisplayAndControl.exe, подключенных к одному
single ChannelManager.exe.
Один ВОПРОС сейчас заключается в том, какую технологию мы должны использовать для облегчения
Кстати, между прочим теперь два (или, скорее, 1 : small_n) приложения.
Производительность важна, потому что, между прочим, много данных перемещается.
два приложения и задержки должны быть сведены к минимуму. Это "только"должен работать в Windows, но его можно использовать только на родном C ++, что делает все технологии, основанные исключительно на .NET, непривлекательными.(Примечание. Планирование переноса частей DisplayAndControl.exe в .NET / WPF запланировано, но ChannelManager.exe должен оставаться чистым, поскольку мы не хотим, чтобы внутри этого процесса выполнялось содержимое .NET.)
Относительно задержки : Важно, чтобы мы достигли некоторого уровня мягкого реального времени в том смысле, что небольшая задержка является приемлемой, но большая и особенно изменяющаяся задержка неприемлема из соображений удобства использования и безопасности.Поэтому предпочтителен любой протокол, который поможет получить какое-то (мягкое) поведение в реальном времени.
Технологии RPC, которые мы рассмотрели:
WCF (или.NET remoting) - только дотнет, поэтому не привлекателен.Показатели производительности тоже не очень хорошие.
(D) COM - COM отлично подходит для связи Windows RPC, но он выходит из строя, когда вам необходимо установить связь между ПК, потому что ужасно, когда настройки безопасности работают вкорпоративная ИТ-сеть.
CORBA - У нас был хороший опыт общения с CORBA в прошлом.Общение легко начать работать;не так много инфраструктуры над головой;хорошо работает с C ++;Написание оболочки .NET довольно тривиально.Проблема с CORBA заключается в том, что в C ++ его сложно использовать правильно (люди будут тратить много времени на поиски утечек памяти, особенно неопытных разработчиков C ++).Это также станет кривой обучения для каждого разработчика и каждого нового разработчика, так как никто не ожидает, что люди будут «знать» CORBA в наши дни.Кроме того, он может работать не так хорошо, как хотелось бы, и, насколько я знаю, в настоящее время нет легкодоступной поддержки в реальном времени.
Thrift - все еще выглядит недоделанным для использования внаш сценарий.
ICE (от ZeroC) - я бы предпочел ICE вместо CORBA в любое время, ведь он обещает быть «лучшим CORBA», и я думаю, что он действительно справляется с этим.Однако их лицензионная политика очень неоптимальна, поскольку они продают не лицензии на разработку, а только лицензии на установку.(Хорошо, что они сказали нам в прошлый раз, когда мы спрашивали в конце 2009 года.) Их политика лицензирования также предполагает, что любая третья сторона, возможно, заинтересованная во взаимодействии с нашими модулями, сначала должна будет также договориться о лицензионном договоре с ZeroC.
Открытый MPI - интерфейс передачи сообщений, по-видимому, нацелен на сценарии с большим количеством клиентов, "сильно" распределенных.Кажется, не соответствует нашей проблеме.
Написание нашего собственного уровня связи с использованием TCP / UDP - О, боже.Я бы не стал: -)
Буферы протокола Google - не технология RPC.
Распределенный общий доступПамять - хорошо.Это было добавлено несколькими разработчиками, и I , например, не уверен, есть ли работающая реализация или подходит ли она для нас.
Итак, снова ВОПРОС - какую технологию типа RPC вы бы предпочли в этой ситуации и почему?