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

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

  • Статья

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

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

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

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

Маркеры

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

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

\\?\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\", протокол и подтип.

Необходимые действия

  • Драйвер ДОЛЖЕН проанализировать компонент протокола (перед первым "."). Любой нераспознанный протокол ДОЛЖЕН комплектуться STATUS_OBJECT_PATH_NOT_FOUND
  • Если строка не завершается значением NULL в пределах длины буфера, драйвер должен завершить IOCTL с STATUS_INVALID_PARAMETER.
  • Если для протокола требуется подтип, а компонент подтипа буфера строки меньше одного (1) символа или длиннее 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–20 секунд], драйвер должен предположить, что клиент исчез. В обычных обстоятельствах клиенты должны обновлять свои запросы в течение одной секунды [1s]. В этом случае драйвер должен задать для счетчика CompleteEventImmediately нулевое значение и не увеличивать счетчик, пока клиент не проснется и не отправит необходимый IRP.

Необходимые действия

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