NFP-Nachrichtenabonnements

  • Artikel

Ein Abonnement wird als eindeutiges geöffnetes Handle innerhalb des Treibers dargestellt. Ein Abonnement wird aktiviert, indem ein Handle im Gerätenamespace "Subs\" geöffnet wird. Der Typ des Abonnements ist definiert, um alles nach dem Präfix "Subs\" zu sein.

Ein Rückruf beim Nachrichtenempfang erfolgt über eine abgeschlossene IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE.

Ein Abonnement kann über eine IOCTL_NFP_DISABLE vorübergehend deaktiviert werden.

Ein Abonnement kann über eine IOCTL_NFP_ENABLE erneut aktiviert werden.

Ziehpunkte

Ein Client, der einen Nachrichtentyp abonnieren möchte, öffnet zunächst ein neues Handle für den Treiber. Handles aus früheren Veröffentlichungen, Abonnements usw. können nicht wiederverwendet werden. Wenn sie nicht mehr benötigt werden, werden sie von einem gut erzogenen Client geschlossen.

Beim Öffnen des Handle legt ein Client den Typ des Nachrichtenabonnements fest. Dies ist der gleiche Mechanismus wie bei der Veröffentlichung, mit dem Unterschied, dass dem Typ "Subs\" anstelle von "Pubs\" vorangestellt ist.

Es gibt keine Möglichkeit, den Typ zurückzulesen.

Erforderliche Aktionen

  • Der Treiber MUSS die Protokollkomponente analysieren (vor dem ersten "."). Jedes nicht erkannte Protokoll muss mit STATUS_OBJECT_PATH_NOT_FOUND
  • Wenn die Zeichenfolge innerhalb der Pufferlänge nicht NULL beendet ist, MUSS der Treiber die IOCTL mit STATUS_INVALID_PARAMETER abschließen.
  • Wenn das Protokoll einen Untertyp erfordert und die Subtypkomponente des Zeichenfolgenpuffers kleiner als ein (1) Zeichen oder länger als 250 Zeichen ist, muss der Treiber die IOCTL mit STATUS_INVALID_PARAMETER abschließen.
  • Wenn die Protokollkomponente des Zeichenfolgenpuffers länger als 250 Zeichen ist, muss der Treiber die IOCTL mit STATUS_INVALID_PARAMETER abschließen.
  • Der Treiber MUSS den ersten NULL-Wert als Ende der Zeichenfolge interpretieren.
  • Der Treiber kann den Typ "Pairing:Bluetooth" für Abonnements erkennen.
  • Der Treiber MUSS den Typ "WindowsUri" erkennen.
  • Der Treiber MUSS den Typ "DeviceArrived" nur für Abonnements erkennen.
  • Der Treiber MUSS den Typ "DeviceDeparted" nur für Abonnements erkennen.
  • Der Treiber MUSS den Typ "WindowsMime" nur für Abonnements erkennen.
  • Der Treiber MUSS den Typ "WindowsMime" erkennen.
  • Wenn das Protokoll nur für Abonnements erkannt werden soll und das IOCTL "Pubs\" angibt, MUSS der Treiber die IOCTL mit STATUS_OBJECT_PATH_NOT_FOUND abschließen.
  • Wenn das Protokoll nur für Veröffentlichungen erkannt werden soll und die IOCTL "Subs\" angibt, muss der Treiber die IOCTL mit STATUS_OBJECT_PATH_NOT_FOUND abschließen.
  • Einige Protokolle (Namespaces) sind reserviert. Sofern nicht explizit in diesem Dokument angegeben, DARF der Treiber keine Protokolle erkennen, die mit beginnen:
    • "Windows"
    • "Gerät"
    • "Kopplung"
    • "NDEF"
  • Zwei geöffnete Handles für denselben Typ MÜSSEN zwei unterschiedliche Entitäten darstellen.
  • Wenn CreateFile erfolgreich ist, ist das Handle jetzt ein "Abonnementhandle" und DARF NICHT in einen anderen Typ von Handle geändert werden.
  • Nachdem diese IOCTL erfolgreich war und das Handle geschlossen wird, müssen jedes Mal, wenn eine Nachricht über die Näherungstechnologie empfangen wird, die dem Typ dieses Abonnements entspricht, die Daten dieser Nachricht an das Dateihandle zur Übermittlung an den Client angefügt werden.

Abbestellen

Der Client schließt das Abonnementhandle, um den Empfang von Nachrichten zu beenden. Wenn ein Clientprozess beendet wird, schließt das System alle geöffneten Dateihandles im Auftrag des Clients.

Erforderliche Aktionen

Wenn das Handle geschlossen wird, MUSS der Treiber den gesamten vom Abonnement verwendeten Arbeitsspeicher wieder freigeben:

  • Der Treiber MUSS die Typzeichenfolgendaten zurückfordern.
  • Die empfangene Warteschlange MUSS gelöscht und wieder beansprucht werden.
  • Alle geschriebenen IOCTL müssen mit STATUS_CANCELLED ausgefüllt werden.

Schädliche Peers

Wenn ein böswilliges Peergerät einen Denial-of-Service-Angriff (DOS) über die Näherungstechnologie versucht, ist es möglich, dass ein Client die "Empfangene" Warteschlange nicht schnell genug entladen kann, um eine übermäßige Arbeitsspeichernutzung durch den Treiber zu verhindern.

Erforderliche Aktionen

Der Treiber DARF KEINE Warteschlange in die Warteschlange stellen oder eine bestimmte Nachricht an den Client übermitteln, wenn diese Nachricht empfangen wird, wenn sich derzeit 50 Nachrichten in der Warteschlange "Empfangen" befinden (die neuesten Nachrichten werden gelöscht).

Nicht reagierende oder fehlerhafte Clients

Wenn ein Client die Warteschlange "Empfangen" nicht mehr leert, indem er die erforderliche IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE Anforderung für einen Zeitraum von zehn bis zwanzig Sekunden [10-20 Sek.] nicht mehr sendet, sollte der Treiber davon ausgehen, dass der Client nicht mehr vorhanden ist. Unter normalen Umständen sollten Clients ihre Anforderungen innerhalb einer Sekunde aktualisieren [1s]. In diesem Fall muss der Treiber den Zähler "CompleteEventImmediately" auf Null festlegen und darf den Zähler erst erhöhen, wenn der Client aufwacht und die erforderliche IRP sendet.

Erforderliche Aktionen

Der Treiber muss den Zähler "CompleteEventImmediately" auf Null festlegen und darf den Zähler nicht erhöhen, wenn der Client innerhalb von 10 bis 20 Sekunden nach dem vorherigen IOCTL-Abschluss keine Ersatz-IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE gesendet hat.

Falsch formatierte Nachrichten

Der Client wird wahrscheinlich alle fehler (außer STATUS_BUFFER_OVERFLOW) löschen oder ignorieren, die von IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE zurückgegeben werden. Daher sollte der Treiber diese nicht mit Fehlerbedingungen abschließen, nur weil eine falsch formatierte Nachricht empfangen wurde.

Erforderliche Aktionen

  • Der Treiber DARF KEINE Nachrichten übermitteln, die größer als die maximal zulässige Nachrichtengröße an den Client sind.

  • Der Treiber SOLLTE KEINE Nachrichten der Länge null an den Client senden.

  • Der Treiber DARF KEINE Teilnachrichten an Abonnenten übermitteln.

  • Der Treiber DARF KEINE Nachrichten an den Client senden, bei denen ein starker CRC fehlgeschlagen ist.

    Hinweis Die NFC Forum-Zertifizierung garantiert dies für NFC-fähige NFP-Anbieter.

  • Der Treiber MUSS eine stark zuverlässige Übertragung und/oder erneute Übertragung von Nachrichten verwenden, bei denen ein starker CRC fehlschlägt.

    Hinweis Die NFC Forum-Zertifizierung garantiert dies für NFC-fähige NFP-Anbieter.

Doppelte Abonnements

Der Treiber sollte davon ausgehen, dass, wenn der Client einen Nachrichtentyp zweimal abonniert, dies darauf zurückzuführen ist, dass der Client die Nachricht zweimal empfangen möchte, wenn die Nachricht empfangen wird.

Erforderliche Aktionen

Der Treiber MUSS doppelte Abonnements akzeptieren und melden, auch wenn sie vom gleichen Client abonniert wurden.

Near Field Communications (NFC)-API-Referenz