Нужна помощь в разработке межпроцессного коммуникационного слоя

Question

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

Некоторые процессы должны непрерывно передавать порции данных 60 раз в секунду, а некоторые очень спорадические.

Большинство процессов в C #, один из них C ++.

Все работает на одной машине с Windows 7.

В настоящее время каждый процесс имеет свое собственное внедрение (каналы, события и сокеты). Я ищу объединение в один коммуникационный слой.

• Как бы вы это реализовали?
• Может быть, какая-то передача с предполагаемым получателем в качестве заголовка?
• Какой метод взаимодействия процессов вы бы выбрали?

Спасибо

SW

Answer 1

Посмотрите на MSMQ.Это основано на сокетах и ​​довольно быстро.В этой статье описывается, как использовать его из C ++: http://msdn.microsoft.com/en-us/library/ms811055.aspx.

Вы также не упомянули, является ли ваше общение синхронным или асинхронным (должен ли писатель ждать ответа от читателя?).У вас есть несколько писателей и читателей?Это постоянная частота 60 Гц, или она входит в пучки с передышкой, где читатели могут догнать писателей?

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

Answer 2

Я бы предложил использовать ICE , который поддерживает удаленные объекты и передачу сообщений.У него не будет проблем с удовлетворением ваших скоростей и потребностей в пропускной способности.Он также кроссплатформенный и поддерживает языки, отличные от C # или C ++, предоставляя вам больше языков для других компонентов.

Answer 3

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

Answer 4

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

Они также относительно сложны и могут включать определенную степень «базового» обучения.

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