Кто-нибудь знает о быстрой шине для локального обмена сообщениями между приложениями на одной машине?

Я ищу механизм pub/sub, который может использоваться приложениями .NET, работающими на одном компьютере (смесь разных доменов приложений и процессов). Я действительно предпочел бы избежать запуска отдельной службы или чего-либо, что требует слишком большой настройки. Очевидно, я также хотел бы свести к минимуму нагрузку на память и процессор.

В частности, я хочу транслировать большие объемы небольших сообщений подписчикам на одном хосте. Поэтому мне нужна шина (например, MSMQ или NServiceBus), но мне не нужны накладные расходы на полную поддержку сети (требуются только локальные именованные каналы) или стоимость и сложность корпоративной шины.


.net messaging bus
person open-collar    schedule 29.11.2011    source источник
comment
Не могли бы вы немного уточнить свои требования: 1. вам нужны надежные/постоянные сообщения 2. нужна ли вам обработка транзакций (отправка и получение) 3. сколько сообщений вы хотите обрабатывать   -  person nightwatch    schedule 29.11.2011
comment
Он не обязательно должен быть устойчивым (в том смысле, что все это может находиться в памяти — если процесс выйдет из строя, он никогда не получит сообщение), но он должен быть транзакционным (т. е. процесс должен быть уверен, что если он разместил сообщение, оно должно быть получено всеми действующими подписчиками)   -  person open-collar    schedule 29.11.2011
comment
О, и максимум около 10 сообщений в секунду.   -  person open-collar    schedule 29.11.2011

Ответы (5)


arrow_upward
4
arrow_downward

Именованные каналы — это самый быстрый способ локального взаимодействия процессов.

Ссылка:
NamedPipeServerStream
NamedPipeClientStream
Choosing a transport

Важное чтение:
Не заходите в тупик

person Peter    schedule 29.11.2011
comment
Однако WCF не предоставляет простой реализации обмена сообщениями pub/sub. - person open-collar; 29.11.2011

arrow_upward
1
arrow_downward

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

person George Mamaladze    schedule 29.11.2011

arrow_upward
1
arrow_downward

Я предполагаю, что при правильной настройке MSMQ + NServiceBus сможет достичь желаемой пропускной способности на одной машине. Существует атрибут [Express], который запрещает запись ваших сообщений на диск. Если производительность достаточна, вам гораздо лучше использовать высокоуровневую структуру, подобную этой, чем создавать собственную.

person jlew    schedule 29.11.2011
comment
Этот подход, вероятно, является наиболее традиционным, но он довольно тяжеловесен для настольного развертывания. Я действительно надеялся на что-то гораздо более простое, что можно было бы настроить на специальной основе с помощью работающего приложения. - person open-collar; 29.11.2011
comment
Вы правы, я не заметил, что это десктопное приложение. Может быть, тогда использование WCF с привязкой именованного канала поможет вам? Это скроет хоть часть беспорядка и вполне подходит для десктопа. - person jlew; 29.11.2011

arrow_upward
0
arrow_downward 

Mailslots
Memory Mapped files
Named Pipes
LPC

Все в Windows

person Preet Sangha    schedule 29.11.2011

arrow_upward
0
arrow_downward

Это не мое окончательное решение, но одно решение, которое появилось, это 0MQ, которое предлагает надежный режим pub/sub и имеет относительно низкие требования к конфигурации и инфраструктуре. Недостатком является то, что это относительно низкий уровень (API .NET является оболочкой для собственного кода C), поэтому мне нужно будет реализовать всю сериализацию и так далее.

Я отпишусь, когда у меня будет время поэкспериментировать и прийти к выводу.

person open-collar    schedule 29.11.2011
comment
Вы можете попробовать реализовать транспорт 0MQ для NServiceBus, таким образом вы получите все тонкости NSB, отказавшись от MSMQ. - person jlew; 02.12.2011