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 während der Ankunft zu empfangen. Normalerweise wird diese IOCTL im Abonnementhandle eingestiftet, bis eine Nachricht, die dem abonnierten Typ entspricht, tatsächlich eingeht.

Hauptcode

IRP_MJ_DEVICE_CONTROL

Eingabepuffer

Nichts

Ausgabepuffer

Ein gültiger Puffer ist erforderlich, um die Nachrichtendaten zurückzugeben, wenn er eingeht. Der erste DWORD- dieses Puffers ist für einen Hinweis an den Client reserviert, damit die nächste Größe des zurückzugebenden Puffers zurückgegeben wird. Dieser Puffer beträgt in der Regel anfangs 255 Byte, 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 abgeschlossen.

Statusblock

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

Andernfalls ist status to the appropriate error condition as a NTSTATUS code.

Weitere Informationen finden Sie unter NTSTATUS Values.

Bemerkungen

• 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 Fertigstellungen dieses IOCTL der Anzahl der erfolgreichen Nachrichtenempfange für den Abonnementtyp entspricht.
• Die folgenden Aktionen sind erforderlich, wenn Sie diese IOCTL verwenden:
  • Wenn diese IOCTL auf einem Handle empfangen wird, das zuvor nicht im Gerätenamespace "Subs\" geöffnet wurde, muss der Treiber es mit STATUS_INVALID_DEVICE_STATE abschließen.
  • Der Treiber muss eine Empfangene Warteschlange mit empfangenen Nachrichten verwalten, die dem Abonnementtyp innerhalb des Abonnementdateihandle 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 pendiert haben.
    • Wenn die Warteschlange "Empfangen" nicht leer ist, muss der Treiber einen Nachrichtenpuffer dequeue, kopieren Sie den Nachrichtenpuffer in den Ausgabepuffer der IOCTL, und schließen Sie die IOCTL mit STATUS_SUCCESS sofort ab.
  • Wenn eine Nachricht, die dem Typ entspricht, empfangen wird und derzeit keine IOCTL eingestiftet ist, muss der Treiber den Nachrichtenpuffer der Warteschlange "Empfangen" hinzufügen.
  • Wenn eine Nachricht, die dem Typ entspricht, empfangen wird und eine stiftete IOCTL verfügbar ist (die Warteschlange "Empfangen" 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 angestifteten IRP weiterhin leer sein.
  • Wenn der Treiber dieses IOCTL mit STATUS_SUCCESS abgeschlossen hat, muss der erste DWORD [4 Byte] des Ausgabepuffers einen Hinweis für die Größe des nächsten Clientpuffers enthalten, und das Feld "Informationen" des IOCTL muss die Größe dieser Nachricht plus Größe von(DWORD) (DWORD) (4 Byte) enthalten.
  • Wenn das IOCTL einen Eingabepuffer enthält, muss der Treiber das IOCTL mit STATUS_INVALID_PARAMETER abschließen.
  • Wenn eine empfangene Nachricht über eine leere Nutzlast verfügt, sollte der Treiber die Nachricht ignorieren. Dies ist eine Leistungsoptimierung, da Windows WILL-Nachrichten mit 0-Längennutzlasten ablegen.
  • Wenn eine empfangene Nachricht zu groß ist, um in den Puffer dieses IOCTL kopiert zu werden, muss der Treiber die erforderliche Puffergröße in die ersten 4 Bytes des Ausgabepuffers kopieren, das Feld "Information" des IOCTL auf Sizeof(DWORD) ("4") festlegen und das IOCTL mit STATUS_BUFFER_OVERFLOW abschließen. Der Nachrichtenpuffer muss in der Warteschlange "Empfangen" verbleiben.
  • Wenn diese IOCTL empfangen wird, während ein anderer im Abonnementhandle zurzeit eingestiftet wird, muss die zweite (oder höher) mit STATUS_INVALID_DEVICE_STATE abgeschlossen werden.
  • Der Treiber MUSS CancelIo des angestifteten IOCTL unterstützen.

Anforderungen

Anforderung	Wert
mindestens unterstützte Client-	Windows 8
Header-	nfpdev.h

Siehe auch

Gesamtentwurfsleitfaden für Die Nahfeldkommunikation (Near Field Communication, NFC)

Near Field Proximity Design Guide (Tap and Do, NFP-Anbietermodell, Treiberanforderungen)