Как сервер, который предоставляет функции COM через IDispatch, может различаться между различными клиентами, которые Invoke функционирует без передачи какого-либо параметра ID?
У меня есть служба Windows, которая предоставляет некоторые COM-функции для вызова через IDispatch Invoke. Существуют различные клиенты (приложения Windows), которые в любой момент могут вызвать любую из этих функций. Мне нужно внести изменение в Службу Windows, которое не требует каких-либо изменений в клиентах (я не могу их изменить). Мне нужно различать (например, идентификатор), какое приложение вызывает функцию. ПРИМЕЧАНИЕ. Мне не нужно знать точное клиентское приложение, достаточно просто различать клиентов в текущем сеансе.
Например: допустим, есть два клиента C1 и C2. Когда C1 вызывает функцию F1 в службе Windows (WS), WS знает, что каждый раз, когда (во время текущего сеанса) клиент X1 (заметьте, я сказал X1, потому что WS не нужно точно знать, что C1 вызвал F1, просто чтобы назначить идентификатор для C1, как PID ~ идентификатор процесса ~). Итак, теперь C3 вызывает F2, WS знает, что клиент X2 (который отличается от X1) вызвал F2. И затем снова C1 вызывает FX (любая функция COM, предоставляемая WS). WS может различить, что X1 вызвал FX, вместо этого клиент Xn (например, X2) вызвал FX.
Есть ли что-нибудь, что может помочь мне достичь этой ситуации без необходимости аргумента идентификации от клиентов?
Решение
Моей первой мыслью было бы просто сравнить клиентские IUnknown адреса на сервере. Если два вызова имеют одинаковый IUnknown, они используют один и тот же прокси и должны исходить от одного и того же клиента.
Вы также можете использовать CoGetCallerTID получить идентификатор клиента своего рода. Эта функция COM API возвращает идентификатор для квартиры вызывающего абонента. Обычно это идентификатор потока, запущенного в процессе вызывающих. Это не может быть гарантированно уникальным для всех вызывающих абонентов, поскольку для этого вам также потребуется идентификатор процесса.
Копаться в других функциях COM API может открыть некоторые другие возможности. CoGetObjectContext Похоже, это может быть полезно, если свойства доступны через IContext Интерфейс может быть определен. Документация не слишком ожидающая о них.
Другие решения
Там нет информации о звонящем, кроме, возможно,
…информация аутентификации, которую клиент использует для звонков на указанный прокси
Если вы заинтересованы в различении вызывающих, типичные решения — добавить параметр метода или создать отдельный объект для каждого вызывающего, чтобы они вызывали методы для своего конкретного экземпляра.