[Из песочницы] Простой Inter-Process Communication на C#

В начале работы junior разработчиком мне пришлось столкнуться с таким малопонятным для меня на то время понятием, как Inter-Process Communication. Это была полная дикость для начинающего программиста, который и в рамках логики одного приложения ориентировался то с большим трудом. Стоит упомянуть, что проект написан на Delphi, а сам механизм IPC реализован с помощью File Mapping и Windows Messages.

Что удивительно, узнал я том, как вся эта система работает изнутри, спустя едва ли не год, когда пришлось маленько с ней повозиться. И только тогда я окончательно осознал, насколько высококлассной была её реализация, а API – удобен. Кому интересна реализация чего-то похожего на вышеупомянутую систему под С# – прошу под кат.



Поскольку в свободное время я изучаю .NET Framework, то меня заинтересовало, насколько легко/удобно реализовано IPC на .NET. К собственному разочарованию понял, что функционал с коробки значительно уступает в удобстве и простоте кустарной делфийской системе. Тут можно развести хороший такой холивар, опираясь на то что .NET ориентирован на абстрагирование от канала передачи данных и позволяет одинаково хорошо шарить объекты как по сети, так и между процессами. Но поскольку тема статьи – именно IPC, то попрошу этого не делать.

Небольшое введение. Я не сумел до конца осознать всех хитростей IPC на .NET, но, покурив мануалы ознакомившись с тематическими статьями, понял, что реально использовать следующие варианты:

1. COM,

2. File Mapping,

3. IPC Channels.

Так как реализация с использованием COM или File Mapping будет мало чем отличатся от аналогов на других языках, выбор однозначно пал на встроенный механизм IPC для .NET.

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

Сервер:

IpcChannel serverChannel = new IpcChannel("MyServerChannel");
ChannelServices.RegisterChannel(serverChannel);
RemotingConfiguration.RegisterWellKnownServiceType(
  typeof(IPCChannelRemoting.MyRemoteObject),
  "SharedObj",
  WellKnownObjectMode.SingleCall);

Клиент:

IpcChannel clientChanel = new IpcChannel("myClient");
ChannelServices.RegisterChannel(clientChanel); 
ISharedObj obj = (Remoteable.ISharedAssemblyInterface)Activator.GetObject(
  typeof(Remoteable.ISharedAssemblyInterface),
  "ipc://MyServerChannel/SharedObj ");

Но что, если обмен данными должен использоваться повсеместно в приложении? В таком случае придется дублировать выше описаний код повсюду и оговорить правила создания URI для shared объектов. А если необходимо не просто запрашивать данные с другого процесса, но и подписываться на получение некоего сигнала/сообщения? Можно сделать Thread/Timer который лупит в цикле проверки или использовать WaitForSingleObject/EventWaitHandle. В общем, тут уже не обойтись без собственноручно созданной архитектуры.

По предыдущему опыту разработки приложения, которое широко использует IPC механизмы, очень удобно использовать следующий подход:

– есть три основных сущности: отправитель, получатель и сообщение;

– у каждого получателя и отправителя есть свои уникальные ID, на которые и идет отправка сообщений. Они могут быть привязаны к PID приложения, handle’y окна или любому общеизвестному идентификатору, о котором известно обеим сторонам;

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

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

– созданию объектов отправителя и сообщения,

– отправления сообщения с помощью отправителя,

– его обработки в процессе получателя.

using (BaseIPCDispatcher dispatcher = new BaseIPCDispatcher(slaveReceaverGUID)) {
  TestAsyncComplexMessage testMessage = new TestAsyncComplexMessage (ReceaverID, null);
  dispatcher.Dispatch(testMessage);
}

Подписка на получение сообщения в другом, ну или том же процессе:

…
Receiver.OnReceaveIPCMessage += OnReceaveMessage;
…
private void OnReceaveMessage(object sender, ReceaveMessageEventArgs e) {
  TestAsyncComplexMessage testAsyncMessage = e.Message as TestAsyncComplexMessage;
  if (testAsyncMessage != null) {
    // process message
  }
}

Имхо, получилось немного более очевидно, гибко и читабельно. Код покрыт функциональными тестами с использованием Master/Slave архитектуры.

Кто желает ознакомиться – результат лежит на GitHub

github.com/perevernihata/SimpleIPCCommSystem

З.Ы. Я понимаю, что, возможно, я по незнанию изобрел свой велосипед с квадратными колесами, – но так ведь это чертовски интересно делать! Конструктивная критика приветствуется.

* (Serializable для асинхронных сообщений).

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html