추가 서버 데이터가 없는 처리기 구현 및 활성화

추가 서버 데이터를 가져오지 않는 경우에는, 처리기의 인스턴스를 만들기 위해 서버가 반드시 IStdMarshalInfo을 구현해야 하지만, IMarshal은 구현하지 않아야 합니다. IStdMarshalInfo 대상 프로세스에 사용할 개체 처리기의 CLSID를 검색하는 GetClassForHandler한 가지 메서드가 있습니다. COM은 CoMarshalInterface를 호출하고 클라이언트 쪽에서 처리기를 활성화할 때 이를 호출합니다.

다음으로 서버 및 처리기 구현 모두 CoGetStdMarshalEx 함수를 호출해야 합니다. 이 함수는 양쪽에 표준 마샬러를 만듭니다(클라이언트 쪽의 프록시 관리자와 서버 쪽의 스텁 관리자라고 함).

서버는 CoGetStdMarshalEx호출하여 플래그 SMEXF_SERVER 전달합니다. 그러면 서버 쪽 표준 마샬러(스텁 관리자)가 만들어집니다. 서버 쪽 구조는 다음 그림에 나와 있습니다.

서버 쪽 구조를 보여 주는 다이어그램

Server-Side 구조체

처리기는 CoGetStdMarshalEx호출한 후 플래그 SMEXF_HANDLER를 전달합니다. 이렇게 하면 클라이언트 쪽 표준 마샬러(프록시 관리자)가 생성되고, 클라이언트 쪽의 핸들러와 통합됩니다. 둘 다의 수명은 처리기가 CoGetStdMarshalEx호출할 때 시스템에서 구현하는 제어 ID 개체(IUnknown구현)에 의해 관리됩니다. 클라이언트 쪽 구조는 다음 그림에 나와 있습니다.

클라이언트 쪽 구조를 보여 주는 DIagram입니다.

Client-Side 구조체

앞의 그림과 같이 처리기는 실제로 프록시 매니저와 식별자/제어 대상 불명 사이에 위치합니다. 이렇게 하면 노출된 인터페이스에 대한 처리기 제어를 제공하면서 개체의 수명을 제어할 수 있습니다. ID와 프록시 관리자 사이의 파선은 두 가지가 내부 프라이빗 인터페이스를 통해 긴밀한 통합을 공유한다는 것을 나타냅니다.

COM은 클라이언트에 CoUnmarshalInterface 호출하면 처리기 인스턴스를 만들어 ID로 집계합니다. 처리기는 생성 시 수신한 제어하는 알 수 없는 것을 전달하여(CoGetStdMarshalEx호출을 통해) 표준 마샬러를 만듭니다. 처리기는 IMarshal을 구현하지 않고, 단순히 표준 마샬러로부터 IMarshal을 반환합니다. 처리기가 iMarshal 구현하더라도 unmarshal 중에 호출되지 않습니다.

두 스레드가 동시에 동일한 개체를 처음으로 마샬링 해제하면 두 개의 처리기가 일시적으로 생성될 수 있습니다. 그 후 하나가 릴리스됩니다.

경량 Client-Side 처리기