Межпроцессное взаимодействие на локальной машине в Windows с использованием COM

Question

Я изучал возможность межпроцессного взаимодействия в Windows с использованием COM и C++.

Я нашел this article on MSDN, предлагая список межпроцессных коммуникационных опций для Windows, а COM - один из них.
Но, к сожалению, параметр COM просто указан без особых деталей.

У кого-нибудь есть указатели на документ или другие ресурсы о том, как использовать COM для межпроцессного взаимодействия в Windows?

Меня не интересует связь с удаленными машинами (так: нет DCOM); Меня просто интересует межпроцессное общение на одном и том же локальном компьютере.

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

Так, например: существуют ли предопределенные COM-интерфейсы для реализации межпроцессного взаимодействия? Если да, то каковы они?

Было бы полезно иметь несколько руководств или более подробное руководство по этому вопросу.

Answer 1

Если у вас есть интерфейс COM, о котором обе стороны знают, то один процесс может зарегистрировать некоторый объект, реализующий это с помощью Running Object Table с использованием прозвища. Другой процесс может затем извлечь объект из этой таблицы interprocess с помощью идентификатора прозвища и запросить его для известного интерфейса. Теперь в клиентском процессе есть ссылка на что-то существующее в другом процессе, и вызовы будут объединены COM.

Есть много вещей, чтобы пойти не так, как будто, в частности, гарантируя, что ваши интерфейсы правильно сортируются. Маршаллинг часто не тестируется, пока вы не начнете использовать несколько процессов или вы используете .Net с вашими интерфейсами COM. Использование совместимых типов oleautomation и маркировка интерфейса в IDL с атрибутом [oleautomation] может помочь гарантировать, что будет работать сортировка библиотек, но также важно обратить внимание на другие атрибуты, используемые с массивами. Мы нашли это с интерфейсом IPropertyBag2 несколько лет назад. Studio 6 Описание Визуальный IDL выглядит в ocidl.idl:

HRESULT Read(
      [in] ULONG cProperties, 
      [in] PROPBAG2 * pPropBag, 
      [in] IErrorLog * pErrLog, 
      [out] VARIANT * pvarValue, 
      [out] HRESULT * phrError 
     ); 

и не Маршаллу более одного варианта из массива при условии. Новая версия выглядит следующим образом:

HRESULT Read(
      [in] ULONG cProperties, 
      [in, size_is(cProperties)] PROPBAG2 * pPropBag, 
      [in, unique] IErrorLog * pErrLog, 
      [out, size_is(cProperties)] VARIANT * pvarValue, 
      [in, out, unique, size_is(cProperties)] HRESULT * phrError 
     ); 

, правильно соотносит размер pvarValue массива с размером, заданным параметром cProperties. Принимая во внимание, что была зарегистрирована стандартная библиотека со вторым определением, этот интерфейс должен теперь корректно маршалироваться, но несколько лет назад эти недостающие параметры стоили нам нескольких клеток мозга, которые выяснили, почему настойчивость терпит неудачу.