Нахождение или построение межпроцессного широковещательного канала связи - PullRequest
6 голосов
/ 15 февраля 2011

Итак, у нас есть несколько необычная потребность в нашем продукте. У нас есть множество процессов, запущенных на локальном хосте, и нам необходимо создать средство связи между ними. Сложность в том, что ...

  1. Нет 'сервера' или главного процесса
  2. Сообщения будут транслироваться на все прослушивающие узлы
  3. Узлы - это все процессы Windows, но могут быть C ++ или C #
  4. Узлы будут работать как в 32-битном, так и в 64-битном режиме одновременно
  5. Любой узел может подключиться / выйти из разговора в любое время
  6. Аварийное завершение процесса не должно отрицательно влиять на другие узлы
  7. Процесс, реагирующий медленно, также не должен отрицательно влиять на другие узлы
  8. Узлу не нужно «слушать», чтобы транслировать сообщение

Еще несколько важных деталей ...

«Сообщения», которые нам нужно отправить, по своей природе тривиальны. Достаточно указать имя типа сообщения и один строковый аргумент.

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

Мой первый вопрос: существует ли существующая библиотека с открытым исходным кодом? Или что-то, что можно использовать для выполнения этого без особых усилий. На данный момент я ничего не смог найти: (

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

Обновление

  • Должен ли он быть надежным и гарантированным? Да, и нет ... Допустим, что если я слушаю и отвечаю в разумные сроки, я всегда должен получать сообщение.

  • Каковы типичные размеры сообщений? менее 100 байтов, включая идентификатор сообщения и аргумент (ы). Это маленькие.

  • О какой скорости сообщений мы говорим? Допускается низкая пропускная способность, 10 в секунду будет много, среднее использование будет около 1 в минуту.

  • Какое количество процессов задействовано? Я бы хотел, чтобы он обрабатывал от 0 до 50, в среднем от 5 до 10.

Ответы [ 4 ]

1 голос
/ 15 февраля 2011

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

  • Отображенные в память файлы
  • События
  • Mutex
  • Семафор

Это может быть построено таким образом, чтобы не требовался «главный» процесс, поскольку все они могут быть созданы как именованные объекты, которые затем управляются ОС и не уничтожаются до тех пор, пока их не использует последний клиент. Основная идея заключается в том, что первый запускаемый процесс создает нужные вам объекты, а затем все остальные процессы подключаются к ним. Если первый процесс завершает работу, объекты остаются до тех пор, пока хотя бы один процесс поддерживает их.

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

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

Но, следуя этому маршруту, вы сможете обмениваться информацией без установления соединения. Не требуется, чтобы всегда выполнялся «серверный» процесс.

Для реализации я бы предложил реализовать его на C ++ и позволить программам на C # вызывать его через P / Invoke. Или, возможно, в C #, и пусть приложения C ++ вызывают его через COM-взаимодействие. Это предполагает, конечно, что ваши приложения C ++ являются нативными, а не C ++ / CLI.

1 голос
/ 15 февраля 2011

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

2cents ...

0 голосов
/ 28 декабря 2014

То, что вы ищете, это почтовые слоты!

См. CreateMailslot: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365147(v=vs.85).aspx

0 голосов
/ 15 февраля 2011

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

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

...