IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE IOCTL (nfpdev.h)

Der Client sendet die IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE Anforderung wiederholt an das Abonnementhandle, um abonnierte Nachrichten beim Eingang zu empfangen. In der Regel wird diese IOCTL in das Abonnementhandle eingegeben, bis eine Nachricht mit dem abonnierten Typ tatsächlich eingeht.

Hauptcode

IRP_MJ_DEVICE_CONTROL

Eingabepuffer

Keine

Ausgabepuffer

Ein gültiger Puffer ist erforderlich, um die Nachrichtendaten beim Eingang zurückzugeben. Das erste DWORD dieses Puffers ist für einen Hinweis für den Client für die nächste Größe des zurückzugebenden Puffers reserviert. Dieser Puffer beträgt in der Regel zunächst 255 Bytes, aber der Treiber kann anfordern, dass der Client einen größeren Puffer sendet, indem er nur den Hinweis bereitstellt und die IOCTL mit STATUS_BUFFER_OVERFLOW.

Statusblock

Irp-IoStatus.Status> wird auf STATUS_SUCCESS festgelegt, wenn die Anforderung erfolgreich ist.

Andernfalls wird Status zur entsprechenden Fehlerbedingung als NTSTATUS-Code verwendet.

Weitere Informationen finden Sie unter NTSTATUS-Werte.

Hinweise

• Der Client sollte jedes Mal, wenn der Stift abgeschlossen ist, eine weitere IOCTL senden. Der Treiber MUSS geeignete Sperren verwenden, um sicherzustellen, dass die Anzahl der erfolgreichen Abschlusse dieser IOCTL der Anzahl der erfolgreichen Nachrichtenempfange für den Abonnementtyp entspricht.
• Bei Verwendung dieser IOCTL sind folgende Aktionen erforderlich:
  • Wenn diese IOCTL für ein Handle empfangen wird, das zuvor nicht im Gerätenamespace "Subs\" geöffnet wurde, MUSS der Treiber sie mit STATUS_INVALID_DEVICE_STATE abschließen.
  • Der Treiber muss eine "Empfangene" Warteschlange mit empfangenen Nachrichten verwalten, die dem Abonnementtyp innerhalb des Abonnementdateihandles entsprechen.
  • Wenn diese IOCTL im Treiber empfangen wird:
    • Wenn die Warteschlange "Empfangen" leer ist, MUSS der Treiber die IOCTL für den späteren Abschluss ausfüllen.
    • Wenn die Warteschlange "Received" nicht leer ist, MUSS der Treiber einen Nachrichtenpuffer aus der Warteschlange entfernen, den Nachrichtenpuffer in den Ausgabepuffer der IOCTL kopieren und die IOCTL mit STATUS_SUCCESS sofort abschließen.
  • Wenn eine Nachricht empfangen wird, die dem Typ entspricht und derzeit keine IOCTL geschrieben wird, MUSS der Treiber den Nachrichtenpuffer der Warteschlange "Received" hinzufügen.
  • Wenn eine Nachricht, die dem Typ entspricht, empfangen wird und eine mit Stift versehene IOCTL verfügbar ist (die Warteschlange "Received" ist leer), MUSS der Treiber den Nachrichtenpuffer in den Ausgabepuffer der IOCTL kopieren und den stifteten IRP mit STATUS_SUCCESS abschließen. Die Warteschlange "Empfangen" MUSS nach Abschluss des geschriebenen IRP weiterhin leer sein.
  • Wenn der Treiber diese IOCTL mit STATUS_SUCCESS abschließt, MUSS das erste DWORD [4 Byte] des Ausgabepuffers einen Hinweis für die Größe des nächsten Clientpuffers enthalten, und das Feld Information der IOCTL MUSS die Größe dieser Nachricht plus sizeof(DWORD) (4 Byte) enthalten.
  • Wenn die IOCTL einen Eingabepuffer enthält, MUSS der Treiber die IOCTL mit STATUS_INVALID_PARAMETER abschließen.
  • Wenn eine empfangene Nachricht über eine Nutzlast der Länge Null verfügt, SOLLTE der Treiber die Nachricht ignorieren. Dies ist eine Leistungsoptimierung, da Windows Meldungen mit 0 -Nutzlasten der Länge "Null" ablöscht.
  • Wenn eine empfangene Nachricht zu groß ist, um in den Puffer dieser IOCTL kopiert zu werden, MUSS der Treiber die erforderliche Puffergröße in die ersten 4 Bytes des Ausgabepuffers kopieren, das Feld "Information" der IOCTL auf sizeof(DWORD) ("4") festlegen und die IOCTL mit STATUS_BUFFER_OVERFLOW abschließen. Der Nachrichtenpuffer muss in der Warteschlange "Received" verbleiben.
  • Wenn diese IOCTL empfangen wird, während sich derzeit eine andere im Abonnementhandle befindet, MUSS die zweite (oder höher) mit STATUS_INVALID_DEVICE_STATE abgeschlossen werden.
  • Der Treiber MUSS CancelIo der per Stift versehenen IOCTL unterstützen.

Anforderungen

Weitere Informationen

Allgemeine Entwurfsanleitung für Near Field Communication (NFC)

Entwurfsleitfaden für Nahfeldnähe (Tippen und Tun, NFP-Anbietermodell, Treiberanforderungen)