Partager via


IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE IOCTL (nfpdev.h)

Le client envoie la demande de IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE à l’abonnement à plusieurs reprises afin de recevoir des messages abonnés dès qu’ils arrivent. En règle générale, ce IOCTL est suspendu dans le handle d’abonnement jusqu’à ce qu’un message correspondant au type abonné arrive réellement.

Code principal

IRP_MJ_DEVICE_CONTROL

Mémoire tampon d’entrée

Aucun

Mémoire tampon de sortie

Une mémoire tampon valide est requise pour retourner les données de message lorsqu’elles arrivent. La première DWORD de cette mémoire tampon est réservée à un indicateur au client pour la taille suivante de la mémoire tampon à retourner. Cette mémoire tampon sera généralement de 255 octets, mais le pilote peut demander au client d’envoyer une mémoire tampon plus importante en fournissant uniquement l’indicateur et en terminant la durée de vie du CIO avec STATUS_BUFFER_OVERFLOW.

Bloc d’état

Irp->IoStatus.Status est défini sur STATUS_SUCCESS si la demande réussit.

Sinon, état à la condition d’erreur appropriée en tant que code NTSTATUS.

Pour plus d’informations, consultez valeurs NTSTATUS.

Remarques

  • Le client doit envoyer un autre IOCTL chaque fois que l’un pendré est terminé. Le pilote DOIT utiliser des verrous appropriés pour garantir que le nombre d’achèvements réussis de ce IOCTL équivaut au nombre de réceptions de messages réussies pour le type d’abonnement.
  • Les actions suivantes sont requises lors de l’utilisation de ce IOCTL :
    • Si ce IOCTL est reçu sur un handle qui n’a pas été ouvert précédemment dans l’espace de noms d’appareil « Subs\ », le pilote DOIT le terminer avec STATUS_INVALID_DEVICE_STATE.
    • Le pilote doit conserver une file d’attente « Reçue » de messages reçus qui correspondent au type d’abonnement dans le handle de fichier d’abonnement.
    • Lorsque ce IOCTL est reçu dans le pilote :
      • Si la file d’attente « Reçu » est vide, le pilote DOIT mettre en attente le IOCTL pour la fin ultérieure.
      • Si la file d’attente « Reçu » n’est pas vide, le pilote DOIT mettre en file d’attente une mémoire tampon de message, copier la mémoire tampon du message dans la mémoire tampon de sortie du IOCTL et terminer la durée de vie du CIO avec STATUS_SUCCESS immédiatement.
    • Si un message correspondant au type est reçu et qu’aucun IOCTL n’est actuellement suspendu, le pilote DOIT ajouter la mémoire tampon de message à la file d’attente « Reçu ».
    • Si un message correspondant au type est reçu et qu’il existe un IOCTL pendu disponible (la file d’attente « Reçu » est vide), le pilote DOIT copier la mémoire tampon de message dans la mémoire tampon de sortie du IOCTL et terminer l’IRP pendu avec STATUS_SUCCESS. La file d’attente « Reçu » doit continuer à être vide après l’achèvement de l’IRP pendu.
    • Si le pilote termine ce IOCTL avec STATUS_SUCCESS, le premier DWORD [4 octets] de la mémoire tampon de sortie DOIT contenir un indicateur pour la taille de la mémoire tampon cliente suivante et le champ Informations du IOCTL DOIT contenir la taille de ce message plus taille de(DWORD) (4 octets).
    • Si le IOCTL contient une mémoire tampon d’entrée, le pilote DOIT terminer le IOCTL avec STATUS_INVALID_PARAMETER.
    • Si un message reçu a une charge utile de longueur nulle, le pilote DOIT ignorer le message. Il s’agit d’une optimisation des performances, car Windows VA supprimer des messages avec des charges utiles de longueur nulle.
    • Si un message reçu est trop volumineux pour être copié dans la mémoire tampon de ce IOCTL, le pilote DOIT copier la taille de mémoire tampon requise dans les 4 premiers octets de la mémoire tampon de sortie, définir le champ « Informations » du CIOTL sur sizeof(DWORD) (« 4 ») et terminer la durée de vie du CIO avec STATUS_BUFFER_OVERFLOW. La mémoire tampon de message doit être laissée dans la file d’attente « Reçue ».
    • Si ce IOCTL est reçu alors qu’un autre est actuellement suspendu dans le handle d’abonnement, le deuxième (ou version ultérieure) doit être terminé avec STATUS_INVALID_DEVICE_STATE.
    • Le pilote DOIT prendre en charge CancelIo du IOCTL pendé.

Exigences

Exigence Valeur
client minimum pris en charge Windows 8
d’en-tête nfpdev.h

Voir aussi

guide de conception global de communication en champ proche (NFC)

guide de conception de proximité de champ proche (modèle de fournisseur NFP, exigences du pilote)