Veröffentlichen von NFP-Nachrichten

  • Artikel

Eine Publikation wird als eindeutiges geöffnetes Handle innerhalb des Treibers dargestellt. Aktive Publikationen müssen sowohl über einen Typ als auch über einen Datenpuffer verfügen. Der Typ wird durch Öffnen eines Dateinamens im Namespace "Pubs" festgelegt. Der Datenpuffer wird durch Senden von IOCTL_NFP_SET_PAYLOAD festgelegt.

Ein Rückruf bei der versuchten Übertragung erfolgt über eine abgeschlossene IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE.

Eine Veröffentlichung kann über eine IOCTL_NFP_DISABLE vorübergehend deaktiviert werden.

Eine Publikation kann über eine IOCTL_NFP_ENABLE erneut aktiviert werden.

Ziehpunkte

Ein Client, der eine Nachricht veröffentlichen 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.

Der Client öffnet ein Dateihandle in "Pubs/<Protokoll>.<SubType>" geräterelativer Namespace. Im folgenden finden Sie ein vollständiges Beispiel.

\\?\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

Nach dem Öffnen des Handles sollte ein Client die Nutzlast der Nachricht festlegen, die mit dem IOCTL_NFP_SET_PAYLOAD veröffentlicht werden soll.

Es gibt keine Möglichkeit, den angegebenen Dateinamen (den Veröffentlichungstyp) zurückzulesen.

Dateiname

Im CreateFile-Handler eines Treibers wird die Device Interface SymbolicLink entfernt, und nur der geräterelative Dateiname bleibt erhalten. Bei diesem Dateinamen handelt es sich um einen UTF-16LE-Zeichenfolgenpuffer mit NULL-Beendigung, der den Typ der Veröffentlichung (oder des Abonnements) angibt. Die maximale Größe dieses Puffers beträgt 502 Zeichen, einschließlich des NULL-Abschlusszeichens. Der Treiber muss diesen Pfad in drei Komponenten analysieren: "Pubs\", das Protokoll und den Untertyp.

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 Veröffentlichungen erkennen. Der Treiber kann diesen Typ erkennen, um die Kompatibilität zu erhalten. (Beachten Sie die Verwendung eines Doppelpunkts anstelle der Verwendung eines Punkts.)
  • 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.
  • Zwei geöffnete Handles für denselben Typ MÜSSEN zwei unterschiedliche Entitäten darstellen.
  • 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"
    • "NFC"
    • "Iso14443Dep"
    • "Iso14443TypeA"
    • "Iso14443TypeB"
    • "Iso15693Vicinity"
    • "MifareClassic"
    • "MifareUltralight"
    • "FeliCa"

Veröffentlichung aufheben

Wenn ein Client keine Nachricht mehr veröffentlichen möchte, wird das Veröffentlichungshandle geschlossen. Dies gibt an, dass die Nachricht nicht mehr übertragen werden soll. Wenn ein Clientprozess beendet wird, schließt das System alle geöffneten Dateihandles im Auftrag des Clients.

Erforderliche Aktionen

  • Wenn der Handle geschlossen ist (IRP_MJ_CLOSE), führt der Treiber Folgendes aus:
    • MUSS den gesamten von der Veröffentlichung verwendeten Arbeitsspeicher (sowohl Typ- als auch Nachrichtendaten) mit Ausnahme von Puffern für laufende Übertragungen dieser Veröffentlichung zurückfordern.
    • DARF die Nachricht NICHT übertragen, wenn ein Gerät in Zukunft in die Nähe tritt.
    • DARF keine laufende Übertragung der Veröffentlichung unterbrechen.
  • Der Treiber kann IRP_MJ_CLEANUP ignorieren.

Der Treiber sollte davon ausgehen, dass der Client eine Nachricht zweimal veröffentlicht, weil der Client die Nachricht zweimal übertragen möchte, wenn sich ein Gerät in der Nähe befindet.

Erforderliche Aktionen

Der Treiber MUSS doppelte veröffentlichte Nachrichten akzeptieren und übertragen, auch wenn sie vom gleichen Client veröffentlicht werden.

Erforderliche Aktionen

Der Treiber MUSS alle Nachrichten (und diese Ressourcen) aus der Warteschlange "Empfangen" entfernen, wenn der Client innerhalb von 10 bis 20 Sekunden nach dem vorherigen IOCTL-Abschluss keine Ersatz-IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE gesendet hat.

Nicht reagierende oder fehlerhafte Clients

Wenn ein Client die erforderliche IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE Anforderung für einen Zeitraum von zehn bis zwanzig Sekunden [10-20 Sek.] nicht 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_TRANSMITTED_MESSAGE gesendet hat.