알림 필터링 및 통신 스타일

아티클
06/15/2023

이 섹션에서는 스풀러 프로세스와 인쇄 프로세서, 드라이버 및 모니터와 같은 인쇄 구성 요소 간의 인터페이스에 대해 설명합니다.

알림 필터링

PrintAsyncNotifyUserFilter 열거형 형식은 두 가지 경우에 사용됩니다. 이 중 첫 번째에서 스풀러 내에서 실행되는 인쇄 구성 요소는 CreatePrintAsyncNotifyChannel 함수를 호출하여 알림 채널을 만듭니다. 호출자는 PrintAsyncNotifyUserFilter 열거형 형식의 열거자 하나를 전달하여 알림을 받을 수 있는 수신 대기 클라이언트를 지정합니다. 두 번째 상황에서 수신 대기 클라이언트는 RegisterForPrintAsyncNotifications 함수를 호출하여 알림을 등록합니다. 호출자는 PrintAsyncNotifyUserFilter 열거자 중 하나를 전달하여 수신해야 하는 알림을 나타냅니다.

typedef enum
{
  kPerUser,
  kAllUsers
} PrintAsyncNotifyUserFilter;

다음 그림에서 kPerUser 열거자는 CreatePrintAsyncNotifyChannel 함수 호출에 사용됩니다. 따라서 등록한 사용자와 동일한 사용자 계정에서 실행되는 수신기만 알림을 받을 수 있습니다.

사용자별 수신기 필터링을 보여 주는 다이어그램

다음 그림에서 kAllUsers 열거자는 CreatePrintAsyncNotifyChannel 함수 호출에 사용됩니다. 따라서 프린터 또는 서버에 관심이 있는 모든 수신기는 알림을 받을 수 있습니다. 관리자만 이 함수에 대한 호출에서 kAllUsers 설정을 사용할 수 있습니다.

모든 수신기에 대한 알림을 보여 주는 다이어그램

다음 그림에서는 RegisterForPrintAsyncNotifications 함수를 호출하고 호출에서 kPerUser 열거자를 전달하여 사용자 1과 사용자 2가 모두 알림에 등록한 상황을 보여 줍니다. 보낸 세 가지 알림 중 수신기 사용자 1은 세션 0 또는 세션 1의 사용자 1에서 알림을 받습니다. 수신기 사용자 2는 세션 2의 사용자 2에서 알림을 받습니다.

알림의 사용자별 필터링을 보여 주는 다이어그램

이전 그림에 표시된 수신 대기 클라이언트가 RegisterForPrintAsyncNotifications를 호출했지만 이번에는 호출에서 kAllUsers 열거자를 전달하는 경우 모든 세션의 모든 수신기가 세 가지 알림을 받았을 것입니다. 관리자만 이 함수에 대한 호출에서 kAllUsers 열거자를 사용할 수 있습니다.

관리자

관리자는 지정된 인쇄 개체에 대한 PRINTER_ACCESS_ADMINISTER 권한을 가진 사용자입니다. 관리자는 누구에게나 알림을 보낼 수 있으며 누구에게서나 알림을 받을 수 있습니다. 알림 필터는 계속 적용됩니다.

다음 그림에서 Joe는 kPerUser를 사용하여 채널에 알림을 보냅니다. 채널이 이 열거자를 기준으로 필터링되는 경우 알림은 사용자 1, 즉 세션 1에 속하는 세션으로만 전송되어야 합니다. 그러나 관리자가 수신 대기하고 이 유형의 알림을 수신 대기하고 있으므로 알림도 세션 2로 전송됩니다. 알림 유형이 동일하지 않으므로 세션 3의 관리자가 알림을 받지 않습니다.

사용자별 및 알림 유형 필터링을 보여 주는 다이어그램

통신 유형 지정

통신 유형을 지정하면 인쇄 구성 요소는 수신기 클라이언트에서 응답이 필요한지 여부와 여러 클라이언트에서 알림을 다시 보낼 때 스풀러가 대/소문자를 처리하는 방식을 나타냅니다.

typedef enum
{
  kBidirectional = 1,
  kUnidirectional,
} PrintAsyncNotifyConversationStyle

단방향 및 양방향이라는 두 가지 유형의 통신이 있습니다. 단방향 통신에서 수신 대기 클라이언트는 스풀러 알림에 응답하지 않습니다. 이 경우 수신 대기 클라이언트는 NULLIPrintAsyncNotifyChannel 인터페이스 포인터를 받기 때문에 알림을 다시 보낼 수 없습니다. 양방향 통신에서 클라이언트는 알림을 받으면 응답을 보내고 인쇄 구성 요소를 사용하여 대화 상자를 진행합니다. UI 알림 사례입니다.

여러 세션이 UI 알림을 받는 상황은 주석을 받을 자격이 있습니다. 이 경우 스풀러는 채널을 열고 필터와 일치하는 모든 수신기에 알리고 첫 번째 알림을 보냅니다. 첫 번째 수신기가 응답하면 스풀러는 다른 채널을 닫고 대화 상자는 첫 번째 클라이언트에서 계속됩니다.

관리자(예: )가 등록된 수신 대기 클라이언트가 응답하기 전에 로그온하는 경우 관리자는 수신 대기 클라이언트와 동일한 UI 알림을 받습니다.

첫 번째 사용자(예: 관리자)가 응답을 보내면 스풀러는 다른 클라이언트와의 연결을 "닫힘"으로 표시합니다. 다른 수신 대기 클라이언트가 결국 응답하면 "채널 닫힘" 메시지가 수신됩니다.

알림 유형

알림 유형은 스풀러가 수신기 클라이언트를 필터링하는 데 수락하고 사용하는 GUID입니다. (헤더 파일 Prnasnot.h의 PrintAsyncNotificationType 형식 정의를 참조하세요.) 스풀러 비동기 알림 메커니즘의 모든 클라이언트는 자체 알림 유형을 정의할 수 있습니다. 스풀러는 전송되는 알림 유형의 의미를 인식하지 못하더라도 알림 유형에 따라 수신기 클라이언트를 필터링합니다.

각 알림에는 알림 데이터 형식이 연결되어 있어야 합니다. 이 유형은 알림 데이터 스키마를 식별합니다.

알림 데이터 형식 외에도 채널과 연결된 형식, 알림 채널 유형이 있습니다. 알림 보낸 사람 및 수신 대기 클라이언트는 다양한 용도로 알림 채널 유형을 사용합니다.

채널의 보낸 사람 쪽에서 인쇄 구성 요소가 채널을 열면 해당 채널을 통해 보낼 알림 유형을 지정할 수 있습니다. 해당 채널을 통과하는 모든 알림은 알림 채널 유형과 동일한 유형이어야 합니다.

스풀러가 적절한 수신 대기 클라이언트에 보내는 방법을 "알고" 있도록 보낸 사람은 항상 형식을 알림과 연결해야 합니다. 수신 대기 클라이언트는 자체 스키마에 따라 데이터의 유효성을 검사해야 합니다. 알림 유형은 이 스키마를 식별합니다.

채널의 수신기 쪽에서 수신 대기 클라이언트는 등록할 때 특정 알림 데이터 형식을 지정하여 한 가지 유형의 알림을 받도록 요청할 수 있습니다.

스풀러는 서비스 또는 애플리케이션이 사망했다는 것을 수신 대기 클라이언트에 알리는 데 사용되는 특수 알림 유형을 정의합니다.

const GUID NOTIFICATION_RELEASE;

수신 대기 클라이언트는 IPrintAsyncNotifyCallback::ChannelClosed 메서드가 호출될 때만 이러한 유형의 메시지를 받을 수 있습니다.

알림 등록 핸들

클라이언트가 알림을 등록하면 서버 쪽 스풀러는 보안 컨텍스트와 같은 애플리케이션에 대한 정보가 포함된 내부 테이블을 유지 관리합니다. 알림 등록 핸들은 클라이언트가 수신하는 불투명 구조입니다.

클라이언트는 이 핸들을 사용하여서만 알림 수신을 등록 취소할 수 있습니다.

다음을 통해 공유

알림 필터링 및 통신 스타일