Лучший подход в общении с процессами - PullRequest
2 голосов
/ 06 января 2011

Я собираюсь создать приложение, которое будет действовать как своего рода диспетчер задач.Из соображений стабильности я буду использовать не потоки, а процессы.Мне приходится иметь дело с несколькими сторонними библиотеками и / или COM-серверами, которые не всегда настолько стабильны и могут иногда вызывать серьезные сбои.Это может (конечно) не повлиять на диспетчер задач

Проблема с использованием процессов, как с ними общаться?Процесс должен возвращать статус того, что он делает каждые x секунд.

Я думал об использовании TCP через отдельный порт для процесса, но лучше ли это делать?

Ответы [ 5 ]

6 голосов
/ 06 января 2011

Именованные каналы, вероятно, будут более эффективными. Посмотрите на WCF:

Предоставление службы WCF через привязку именованных каналов

2 голосов
/ 06 января 2011

Вы можете использовать WCF (с привязкой NetNamedPipeBinding).

И, возможно, рассмотрите домены приложений для запуска ваших процессов.

1 голос
/ 06 января 2011

Использование труб было бы хорошим вариантом. Посмотрите на пространство имен System.IO.Pipes .

0 голосов
/ 06 января 2011

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

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

0 голосов
/ 06 января 2011

Я думаю, вам стоит взглянуть на Инструментарий:

http://msdn.microsoft.com/en-us/magazine/cc300488.aspx

Любой другой подход, такой как разговор по портам или WCF, добавляет слои, которые могут затруднить выявление первопричины проблем;это также ведется в сравнении производительности по инструментам.WMI построен на основе высокопроизводительного мониторинга.Кроме того, в оперативном плане это лучший подход, поскольку он играет роль инструментов администратора для мониторинга работоспособности процессов.

...