Фильтрация уведомлений и стили общения

В этом разделе описывается интерфейс между процессом очереди очереди и компонентами печати, такими как процессор печати, драйвер и монитор.

Фильтрация уведомлений

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

typedef enum
{
  kPerUser,
  kAllUsers
} PrintAsyncNotifyUserFilter;

На рисунке ниже перечислитель kPerUser используется в вызове функции CreatePrintAsyncNotifyChannel . В результате получать уведомления могут только прослушиватели, работающие в той же учетной записи пользователя, что и пользователь, выполнивший регистрацию.

На следующем рисунке перечислитель kAllUsers используется в вызове функции CreatePrintAsyncNotifyChannel . В результате все прослушиватели, заинтересованные в принтере или сервере, могут получать уведомления. Обратите внимание, что только администраторам разрешено использовать параметр kAllUsers в вызовах этой функции.

На следующем рисунке показана ситуация, в которой пользователь 1 и пользователь 2 зарегистрировались для уведомлений путем вызова функции RegisterForPrintAsyncNotifications , передав перечислитель kPerUser в вызове. Из трех отправленных уведомлений прослушиватель Пользователь 1 получает уведомления от пользователя 1 в сеансе 0 или сеансе 1. Прослушиватель Пользователь 2 получает уведомления от пользователя 2 в сеансе 2.

Если бы прослушивающие клиенты, показанные на предыдущем рисунке, вызвали RegisterForPrintAsyncNotifications, но на этот раз передали перечислитель kAllUsers в вызове, все прослушиватели во всех сеансах получили бы три уведомления. Обратите внимание, что только администраторам разрешено использовать перечислитель kAllUsers в вызовах этой функции.

Администраторы

Администратор — это пользователь с PRINTER_ACCESS_ADMINISTER правами для указанного объекта печати. Администратор может отправлять уведомления любому пользователю и получать уведомления от любого пользователя. Обратите внимание, что фильтр уведомлений по-прежнему применяется.

На следующем рисунке Джо отправляет уведомление на канал с kPerUser. При фильтрации канала на основе этого перечислителя уведомление должно отправляться только сеансам, принадлежащим пользователю 1, а именно сеансу 1. Однако уведомление также отправляется в сеанс 2, так как администратор прослушивает его и прослушивает уведомления этого типа. Обратите внимание, что администратор в сеансе 3 не получает уведомление, так как типы уведомлений отличаются.

Указание типа связи

Указывая тип связи, компонент печати указывает, ожидается ли ответ от клиента прослушивателя, а также способ обработки очереди очереди при отправке уведомлений от нескольких клиентов.

typedef enum
{
  kBidirectional = 1,
  kUnidirectional,
} PrintAsyncNotifyConversationStyle

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

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

Если администратор (например) входит в систему до ответа зарегистрированного прослушивающего клиента, администратор получает то же уведомление пользовательского интерфейса, что и прослушивающий клиент.

Когда первый пользователь (например, администратор) отправляет ответ, диспетчер очереди помечает подключения с другими клиентами как "закрытые". Когда другой прослушивающий клиент в конечном итоге отвечает, он получает сообщение "канал закрыт".

Типы уведомлений

Тип уведомления — это GUID, который диспетчер очереди очереди принимает и использует для фильтрации клиентов прослушивателя. (См. определение типа PrintAsyncNotificationType в файле заголовка Prnasnot.h.) Любой клиент механизма асинхронного уведомления очереди очереди может определить собственный тип уведомления. Несмотря на то, что диспетчер очереди не знает о значении типа отправляемого уведомления, он по-прежнему фильтрует клиентов прослушивателя по типу уведомления.

С каждым уведомлением должен быть связан тип данных уведомления. Этот тип идентифицирует схему данных уведомления.

Помимо типа данных уведомления существует тип, связанный с каналом, тип канала уведомлений. Отправитель уведомлений и прослушивающий клиент используют тип канала уведомлений для разных целей.

На стороне отправителя канала, когда компонент печати открывает канал, он может указать тип уведомлений, которые он намерен отправлять через этот канал. Все уведомления, проходящие через этот канал, должны иметь тот же тип, что и канал уведомлений.

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

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

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

const GUID NOTIFICATION_RELEASE;

Прослушивающий клиент может получать сообщения этого типа только при вызове метода IPrintAsyncNotifyCallback::ChannelClosed .

Дескриптор регистрации уведомлений

Когда клиент регистрируется для получения уведомлений, сервер очереди ведет внутреннюю таблицу со сведениями о приложении, такими как контекст безопасности. Дескриптор регистрации уведомлений — это непрозрачная структура, которую получает клиент.

Клиент может отменить регистрацию для получения уведомлений только с помощью этого дескриптора.