共用方式為

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） 個字元或超過 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”
  • 相同類型的兩個開啟句柄必須代表兩個不同的實體。
  • 如果 CreateFile 成功，句柄現在是「訂用帳戶句柄」，且「不可」變更為任何其他類型的句柄。
  • 此 IOCTL 成功且在控制代碼關閉之前，每次透過符合此訂閱類型的鄰近技術收到訊息時，該訊息的數據都必須附加到檔案控制代碼，以傳遞給用戶端。

取消訂閱

客戶端會關閉訂閱處理程式來停止接收訊息。 如果客戶端進程終止，系統會代表用戶端關閉所有開啟的檔案句柄。

必要動作

當句柄關閉時，驅動程式必須回收訂用帳戶所使用的所有記憶體：

  • 驅動程式必須回收類型字串數據。
  • 接收到的佇列必須清除並回收。
  • 任何掛起的 IOCTL 必須以 STATUS_CANCELLED 完成。

惡意對等

如果惡意對等裝置嘗試透過鄰近技術進行阻斷服務 （DOS） 攻擊，則用戶端可能無法快速清空「已接收」佇列，以防止驅動程式過度使用記憶體。

必要動作

當「已接收」佇列中已有 50 則訊息時，如果收到新的訊息，驅動程式不得將該訊息排入佇列或傳遞給用戶端（最多只能保留最新 50 則訊息）。

無回應或運作異常的客戶端

如果用戶端在 10 到 20 秒 [10-20 秒] 期間內無法傳送所需的 IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE 要求，而停止清空「已接收」佇列，則驅動程式應該假設用戶端已消失。 在正常情況下，用戶應該在一秒 [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 參考

  • Last updated on