.NET IPC без посредника службы

Почему бы не разместить сервер и клиент с обеих сторон, и тот, кто придет первым, станет сервером? И если сервер выпадает, клиент, который все еще активен, меняет роли.

Есть много способов обработки IPC (.net или нет), и через туннель TCP / HTTP это один из способов ... но может быть очень плохим выбором (в зависимости от обстоятельств и среды).

Общая память и именованные каналы - это два способа (и да, они могут быть реализованы в .Net), которые могут быть для вас лучшими решениями. В .Net Framework есть также класс IPC ... но лично мне они не нравятся из-за некоторых проблем с доменом приложений ...

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

Если вы выберете маршрут удаленного взаимодействия, вы можете использовать IpcChannel вместо каналов TCP или HTTP для единой системной связи с использованием именованных каналов. http://msdn.microsoft.com/en-us/library/4b3scst2.aspx. Проблема с этим решением заключается в том, что вам нужно будет найти решение типа реестра (либо в общей памяти, либо в другом постоянном хранилище), с помощью которого процессы могут регистрировать свои конечные точки. Таким образом, когда вы их ищете, вы можете найти способ запросить все конечные точки, которые работают в системе, и найти то, что ищете. Преимущества использования удаленного взаимодействия заключаются в том, что сериализация и вызов методов довольно просты. Кроме того, если вы решите перейти на несколько компьютеров в сети, вы можете просто щелкнуть переключателем, чтобы вместо этого использовать сетевые каналы. Минусы в том, что удаленное взаимодействие может раздражать, если вы четко не отделите «удаленные» вызовы от «локальных» вызовов.

Я мало что знаю о WCF, но, возможно, на это тоже стоит обратить внимание. Spider sense говорит, что у него, вероятно, есть более элегантное решение этой проблемы ... может быть.

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

Еще одна вещь, которую стоит изучить в модели публикации-подписки для событий (Pub / Sub). Этот метод помогает, когда у вас есть прослушиватель, который запускается до того, как источник события становится доступным, но вы не хотите ждать, чтобы зарегистрироваться для события. «Серверный» процесс будет обрабатывать реестр событий, чтобы связать издателей и подписчиков.

Я согласен с Гаро.

Использование службы pub / sub было бы отличным решением. Это, очевидно, означает, что эта служба должна быть запущена раньше любой из двух других.

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

-Скотт

Я потратил 2 дня, изучая все варианты, доступные для IPC, в поисках надежного, простого и быстрого способа сделать полнодуплексный IPC. IPCLibrary, который я нашел на Codeplex.com, пока работает отлично из всех опций, которые я пробовал. Всего 7 строк кода. : D Если кто-то наткнется на это, пытаясь найти полнодуплексный IPC, сэкономьте массу времени и попробуйте эту библиотеку. Возьмите исходный код, скомпилируйте data.dll и следуйте приведенным примерам.

HTH, Circ