通过

NFP 消息订阅

  • 项目

订阅在驱动程序中表示为唯一的打开句柄。 通过打开“Subs\”设备命名空间中的句柄，使订阅处于活动状态。 订阅的类型定义为“Subs\”前缀后面的所有内容。

通过完成的 IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE提供对消息接收的回调。

可以通过 IOCTL_NFP_DISABLE暂时禁用订阅。

可以通过 IOCTL_NFP_ENABLE重新启用订阅。

句柄数

想要订阅消息类型的客户端将首先打开驱动程序的新句柄。 不能重复使用以前的发布、订阅等的句柄。 如果不再需要它们，它们将由行为良好的客户端关闭。

在打开句柄时，客户端会设置消息订阅的类型。 这与用于发布的机制相同，只不过类型以“Subs\”而不是“Pubs\”作为前缀。

没有回读类型的工具。

必需的措施

  • 驱动程序必须在第一个“.”之前分析协议组件 (。) 。 任何无法识别的协议都必须完成STATUS_OBJECT_PATH_NOT_FOUND
  • 如果字符串在缓冲区长度内不以 NULL 结尾，则驱动程序必须使用STATUS_INVALID_PARAMETER完成 IOCTL。
  • 如果协议需要子类型，并且字符串缓冲区的子类型组件小于 1 (1) 字符或长度超过 250 个字符，则驱动程序必须使用STATUS_INVALID_PARAMETER完成 IOCTL。
  • 如果字符串缓冲区的协议组件长度超过 250 个字符，驱动程序必须使用STATUS_INVALID_PARAMETER完成 IOCTL。
  • 驱动程序必须将第一个 NULL 解释为字符串的末尾。
  • 驱动程序可以识别订阅的“配对：蓝牙”类型。
  • 驱动程序必须识别“WindowsUri”类型。
  • 驱动程序必须仅识别订阅的“DeviceArrived”类型。
  • 驱动程序必须仅识别订阅的“DeviceDeparted”类型。
  • 驱动程序必须仅识别订阅的“WindowsMime”类型。
  • 驱动程序必须识别“WindowsMime.”类型。
  • 如果只应为订阅识别协议，并且 IOCTL 指定了“Pubs\”，则驱动程序必须使用STATUS_OBJECT_PATH_NOT_FOUND完成 IOCTL。
  • 如果只应为发布识别协议，并且 IOCTL 指定了“Subs\”，则驱动程序必须使用STATUS_OBJECT_PATH_NOT_FOUND完成 IOCTL。
  • 某些协议 (命名空间) 保留。 除非本文档中明确指定，否则驱动程序不得识别以下列开头的任何协议：
    • “Windows”
    • “设备”
    • “配对”
    • “NDEF”
  • 同一类型的两个打开句柄 MUST 表示两个不同的实体。
  • 如果 CreateFile 成功，则句柄现在是“订阅句柄”，并且不得更改为任何其他类型的句柄。
  • 此 IOCTL 成功后，在关闭句柄之前，每次通过匹配此订阅类型的邻近技术收到消息时，必须将该消息的数据附加到文件句柄才能传递到客户端。

取消订阅

客户端将关闭订阅句柄以停止接收消息。 如果客户端进程终止，系统将代表客户端关闭所有打开的文件句柄。

必需的措施

当句柄关闭时，驱动程序必须回收订阅使用的所有内存：

  • 驱动程序必须回收类型字符串数据。
  • 必须清除和回收接收的队列。
  • 必须使用STATUS_CANCELLED完成任何吊坠的 IOCTL。

恶意对等方

如果恶意对等设备通过邻近感应技术尝试拒绝服务 (DOS) 攻击，则客户端可能无法以足够快的速度排出“已接收”队列，以防止驱动程序过度使用内存。

必需的措施

如果在当前有 50 条消息当前位于“已接收”队列中时收到给定消息，则驱动程序不得将给定消息排入队列或将给定消息传送给客户端， (最新消息) 。

客户端无响应或行为不当

如果客户端在 10 到 20 秒 [10-20 秒] 的时间内未能发送所需的 IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE 请求而停止清空“Received”队列，则驱动程序应假定客户端已消失。 在正常情况下，客户端应在一秒 [1s] 内刷新其请求。 如果发生这种情况，驱动程序必须将“CompleteEventImmediately”计数器设置为零，并且不得在客户端唤醒并发送所需的 IRP 之前递增计数器。

必需的措施

驱动程序必须将“CompleteEventImmediately”计数器设置为零，如果客户端在之前的 IOCTL 完成时间 10 到 20 秒内未发送替换 IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE ，则不得递增计数器。

格式不正确的消息

客户端可能会删除或忽略 (除从 IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE返回STATUS_BUFFER_OVERFLOW) 之外的所有错误。 因此，驱动程序不应仅仅因为收到格式不正确的消息而使用错误条件完成这些操作。

必需的措施

  • 驱动程序不得将大于最大允许消息大小的消息传送到客户端。

  • 驱动程序“不应当”向客户端传递长度为零的消息。

  • 驱动程序不得将部分消息传递给订阅者。

  • 驱动程序不得将消息传送给未能通过强 CRC 的客户端。

    注意 NFC 论坛认证为支持 NFC 的 NFP 提供商保证这一点。

  • 驱动程序必须使用非常可靠的传输和/或尝试重新传输无法通过强 CRC 的消息。

    注意 NFC 论坛认证为支持 NFC 的 NFP 提供商保证这一点。

重复订阅

驱动程序应假定，如果客户端订阅消息类型两次，这是因为客户端希望在收到消息时接收消息两次。

必需的措施

驱动程序必须接受并报告重复的订阅，即使由同一客户端订阅。

近场通信 (NFC) API 参考