Форма IPC, которая подходит для моей ситуации - PullRequest
2 голосов
/ 17 февраля 2012

Мне нужно уведомить 1-много клиентов для выполнения задачи (перезагрузить). Сервер может работать или не работать в любой момент времени. (По этой причине у меня возникли трудности с определением, кто является клиентом, а кто - сервером.)

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

Я пытался использовать NamedPipeServerStream и запускать несколько экземпляров на «клиентах» (помните, что отношения странные, так что терпите меня). К сожалению, я могу создать только один сервер Pipe для любого заданного имени сервера. Так что это не сработало. Я мог бы заставить клиентов постоянно проверять наличие сервера, но если я собираюсь начать опрос, я мог бы также опросить БД напрямую.

Моя ситуация примерно такая же, как у наблюдателя. Мне не нужно динамически подписываться / отписываться. Я хочу, чтобы сервер выдал уведомление всем работающим клиентам для выполнения задачи.

Как мне этого добиться? Пожалуйста, имейте в виду, что я должен сделать это с IPC. Сервер / клиенты работают под разными процессами и всегда на одном компьютере.

Ответы [ 3 ]

3 голосов
/ 17 февраля 2012

Чтобы решить проблему опроса, вы можете создать именованное ManualResetEvent, которое будет прослушивать клиентские процессы. Клиенты раскручивают поток, затем ждут события, когда сервер запускается, он сигнализирует о событии и позволяет всем клиентам запускать свой код прослушивания, который может открыть именованный канал, как вы делаете в настоящее время. Посмотрите на страницу EventWaitHandle.GetAccessControl MSDN, чтобы увидеть пример того, как сделать именованное ManualResetEvent.

Для вашей проблемы I can only create one Pipe server for any given server name., если работает несколько серверов, как клиенты должны знать, к какому серверу подключаться? Вы сказали, что это были отношения 1 к * клиенту. Если вы собираетесь запускать несколько серверов, вам понадобится указать клиенту, какой сервер он должен слушать.

1 голос
/ 17 февраля 2012

Поскольку вы указали, что все процессы гарантированно будут работать на одной и той же машине, я, вероятно, рассмотрю использование окна с именем event . Ваш клиент (ы) и сервер могут вызвать OpenEvent , если событие не было создано, вызвать CreateEvent . Это даст вам некоторый контроль (с помощью pulseevent, set / reset и т. Д.) Над тем, сколько клиентов выпущено за событие, а также позволит вам открыть клиент без уже существующего сервера.

Как Скотт предлагает, чтобы легко сделать это в c #, используйте .net с именем EventWaitHandle, вызывая конструктор, который принимает строку (например, this ). Который создаст общесистемный объект синхронизации для вас. Этот конкретный конструктор также сообщит вам, если вы первый запросили событие (вы его создали) или оно уже существовало.

0 голосов
/ 17 февраля 2012

Использование именованной совместно используемой памяти было бы одним из способов осуществления связи «один ко многим». Сервер может создать общую память, и один или несколько клиентов могут открыть ее и прочитать. Пример (на С) показан здесь . Кроме того, пример .NET показан здесь .

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

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

...