Поделиться через

Публикация сообщений NFP

Публикация представлена как уникальный открытый дескриптор в драйвере. Активные публикации должны иметь как тип, так и буфер данных. Тип задается путем открытия имени файла в пространстве имен Pubs. Буфер данных задается путем отправки IOCTL_NFP_SET_PAYLOAD.

Обратный вызов при попытке передачи предоставляется через завершенную IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE.

Публикацию можно временно деактивировать с помощью IOCTL_NFP_DISABLE.

Публикацию можно повторно включить с помощью IOCTL_NFP_ENABLE.

Ручки

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

Клиент откроет дескриптор файла в разделе "Pubs/<Protocol>.<подтипе>" пространство имен относительно устройства. Ниже приведен полный пример.

\\?\root#ContosoProx#0000#{FB3842CD-9E2A-4F83-8FCC-4B0761139AE9}\Pubs\Windows.windows.com/SD
<---------------Device Interface Symbolic Link-----------------> <------File Name---------->
    <--------------------><------------------------------------> <--> <-----> <------------>
          DeviceID          NearFieldProximity Interface Class     *  Protocol   SubType

После открытия дескриптора клиент должен задать полезные данные сообщения для публикации с помощью IOCTL_NFP_SET_PAYLOAD.

Нет возможности считывать указанное имя файла (тип публикации).

Имя файла

В обработчике CreateFile драйвера интерфейс устройства Символьная ссылка будет удалена, и останется только относительное имя файла устройства. Имя файла будет буфером строки UTF-16LE, чувствительным к регистру с нулевым завершением, который указывает тип публикации (или подписки). Максимальный размер этого буфера составляет 502 символа, включая терминатор NULL. Драйвер должен проанализировать этот путь на три составные компоненты: Pubs\, protocol и subtype.

Обязательные действия

  • Драйвер ДОЛЖЕН проанализировать компонент протокола (перед первым "."). Любой нераспознанный протокол ДОЛЖЕН завершаться с STATUS_OBJECT_PATH_NOT_FOUND
  • Если строка не завершается значением NULL в пределах длины буфера, драйвер должен завершить IOCTL с STATUS_INVALID_PARAMETER.
  • Если протокол требует подтипа и длина компонента подтипа буфера строки составляет менее одного символа или превышает 250 символов, драйвер ОБЯЗАН завершить IOCTL с STATUS_INVALID_PARAMETER.
  • Если компонент протокола буфера строки длиннее 250 символов, драйвер ДОЛЖЕН завершить IOCTL с STATUS_INVALID_PARAMETER.
  • Драйвер ДОЛЖЕН интерпретировать первый NULL как конец строки.
  • Драйвер может распознать тип "Pairing:Bluetooth" для публикаций. Драйвер МОЖЕТ распознать этот тип, чтобы сохранить совместимость. (Обратите внимание на использование двоеточия, а не на использование периода.)
  • Драйвер ДОЛЖЕН распознать тип WindowsUri.
  • Драйвер ДОЛЖЕН распознать только тип DeviceArrived для подписок.
  • Драйвер ДОЛЖЕН распознать только тип DeviceDeparted для подписок.
  • Драйвер должен распознать только тип WindowsMime для подписок.
  • Драйвер ДОЛЖЕН распознать тип WindowsMime.
  • Если протокол должен быть распознан только для подписок, а IOCTL указывает "Pubs\", драйвер ДОЛЖЕН завершить IOCTL с STATUS_OBJECT_PATH_NOT_FOUND.
  • Если протокол должен быть распознан только для публикаций, а IOCTL указывает "Subs\", драйвер ДОЛЖЕН завершить IOCTL с STATUS_OBJECT_PATH_NOT_FOUND.
  • Два открытых дескриптора для одного типа ДОЛЖНЫ представлять две отдельные сущности.
  • Некоторые протоколы (пространства имен) зарезервированы. Если в этом документе явно не указано, драйвер не должен распознавать все протоколы, начинающиеся с:
    • "Windows"
    • "Устройство"
    • Сопряжение
    • "NDEF"
    • "NFC"
    • "Iso14443Dep"
    • "Iso14443TypeA"
    • Iso14443TypeB
    • "Iso15693Vicinity"
    • "MifareClassic"
    • "MifareUltralight"
    • "ФелиКа"

Отменить публикацию

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

Обязательные действия

  • При закрытии ручки (IRP_MJ_CLOSE), драйвер:
    • НЕОБХОДИМО освободить всю память, используемую публикацией (как типом, так и данными сообщения), за исключением буферов для текущих передач этой публикации.
    • НЕ СЛЕДУЕТ передавать сообщение, если устройство в будущем окажется поблизости.
    • НЕ ДОЛЖНО прерываться любая начатая передача публикации.
  • Драйвер МОЖЕТ игнорировать IRP_MJ_CLEANUP.

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

Обязательные действия

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

Обязательные действия

Драйвер обязан удалить все сообщения (и освободить эти ресурсы) из очереди «Получено», если клиент не отправил замену IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE в течение 10 – 20 секунд после завершения предыдущего IOCTL.

Неответственное или неправильное поведение клиентов

Если клиенту не удается отправить необходимый запрос IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE в течение десяти–двадцати секунд [10–20sec], драйвер должен предположить, что клиент ушел. В обычных условиях клиенты должны обновлять свои запросы в течение одной секунды [1s]. Если это происходит, драйвер должен задать счетчик "CompleteEventImmediately" равным нулю и не должен увеличивать счетчик до тех пор, пока клиент не проснется и не отправит необходимый IRP.

Обязательные действия

Драйвер должен установить счетчик "CompleteEventImmediately" в ноль и не должен увеличивать его, если клиент не отправил замену IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE в течение 10 – 20 секунд после завершения предыдущего IOCTL.

  • Last updated on