Partager via

Publication de messages NFP

  • Article

Une publication est représentée sous la forme d’un handle ouvert unique au sein du pilote. Les publications actives doivent avoir à la fois un type et une mémoire tampon de données. Le type est défini en ouvrant un nom de fichier dans l’espace de noms « Pubs ». La mémoire tampon de données est définie en envoyant des IOCTL_NFP_SET_PAYLOAD.

Un rappel lors d’une tentative de transmission est donné via un IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE terminé.

Une publication peut être temporairement désactivée via un IOCTL_NFP_DISABLE.

Une publication peut être réactivé via une IOCTL_NFP_ENABLE.

Poignées

Un client qui souhaite publier un message ouvre d’abord un nouveau handle pour le pilote. Les handles provenant de publications antérieures, d’abonnements, etc. ne peuvent pas être réutilisés. S’ils ne sont plus nécessaires, ils seront fermés par un client bien comporté.

Le client ouvre un handle de fichier dans « Pubs/<Protocol> .<Espace de noms relatif à l’appareil SubType>. L’exemple ci-dessous est complet.

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

Après avoir ouvert le handle, un client doit définir la charge utile du message à publier avec le IOCTL_NFP_SET_PAYLOAD.

Il n’existe aucune possibilité de lire le nom de fichier spécifié (type de publication).

Nom de fichier

Dans le gestionnaire CreateFile d’un pilote, le lien symbolique de l’interface de l’appareil est supprimé et seul le nom de fichier relatif à l’appareil reste. Ce nom de fichier est une mémoire tampon de chaîne UTF-16LE qui respecte la casse et qui indique le type de la composition (ou de l’abonnement). La taille maximale de cette mémoire tampon est de 502 caractères, y compris la terminaison NULL. Le pilote doit analyser ce chemin d’accès en trois composants constitutifs : « Pubs\ », protocole et sous-type.

Mesures à prendre

  • Le pilote DOIT analyser le composant de protocole (avant le premier « . »). Tout protocole non reconnu DOIT être complété par STATUS_OBJECT_PATH_NOT_FOUND
  • Si la chaîne n’est pas terminée par null dans la longueur de la mémoire tampon, le pilote DOIT remplir le IOCTL avec STATUS_INVALID_PARAMETER.
  • Si le protocole nécessite un sous-type et que le composant de sous-type de la mémoire tampon de chaîne a moins d’un (1) caractère ou plus de 250 caractères, le pilote DOIT terminer le IOCTL avec STATUS_INVALID_PARAMETER.
  • Si le composant de protocole de la mémoire tampon de chaîne est plus long que 250 caractères, le pilote DOIT terminer le IOCTL avec STATUS_INVALID_PARAMETER.
  • Le pilote DOIT interpréter la première valeur NULL comme la fin de la chaîne.
  • Le pilote peut reconnaître le type « Pairing :Bluetooth » pour les publications. Le pilote PEUT reconnaître ce type afin de préserver la compatibilité. (Notez l’utilisation d’un signe deux-points plutôt que l’utilisation d’un point.)
  • Le pilote DOIT reconnaître le type « WindowsUri ».
  • Le pilote DOIT reconnaître le type « DeviceArrived » pour les abonnements uniquement.
  • Le pilote DOIT reconnaître le type « DeviceDeparted » pour les abonnements uniquement.
  • Le pilote DOIT reconnaître le type « WindowsMime » pour les abonnements uniquement.
  • Le pilote DOIT reconnaître le type « WindowsMime ».
  • Si le protocole doit être reconnu uniquement pour les abonnements et que le iocTL spécifie « Pubs\ », le pilote DOIT remplir le iocTL avec STATUS_OBJECT_PATH_NOT_FOUND.
  • Si le protocole doit être reconnu uniquement pour les publications et que le IOCTL spécifie « Subs\ », le pilote DOIT remplir le IOCTL avec STATUS_OBJECT_PATH_NOT_FOUND.
  • Deux handles ouverts du même type DOIVENT représenter deux entités distinctes.
  • Certains protocoles (espaces de noms) sont réservés. Sauf indication explicite dans ce document, le pilote NE DOIT pas reconnaître les protocoles commençant par :
    • « Windows »
    • « Appareil »
    • « Appairage »
    • « NDEF »
    • « NFC »
    • « Iso14443Dep »
    • « Iso14443TypeA »
    • « Iso14443TypeB »
    • « Iso15693Vicinity »
    • « MifareClassic »
    • « MifareUltralight »
    • « FeliCa »

Dépublier

Lorsqu’un client ne souhaite plus qu’un message soit publié, il ferme le handle de publication. Cela indique que le message ne doit plus être transmis. Si un processus client se termine, le système ferme tous les handles de fichiers ouverts au nom du client.

Mesures à prendre

  • Lorsque le handle est fermé (IRP_MJ_CLOSE), le pilote :
    • DOIT récupérer toute la mémoire utilisée par la composition (à la fois les données de type et de message), à l’exception des mémoires tampons pour les transmissions continues de cette publication.
    • NE DOIT PAS transmettre le message si un appareil devient proche à l’avenir.
    • NE DOIT PAS interrompre toute transmission en cours de la publication.
  • Le pilote peut ignorer IRP_MJ_CLEANUP.

Le pilote doit supposer que si le client publie un message deux fois, c’est parce que le client souhaite que le message soit transmis deux fois lorsqu’un appareil est à proximité.

Mesures à prendre

Le pilote DOIT accepter et transmettre des messages publiés en double, même s’ils sont publiés par le même client.

Mesures à prendre

Le pilote DOIT supprimer tous les messages (et récupérer ces ressources) de la file d’attente « Reçu » si le client n’a pas envoyé d’IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE de remplacement dans les 10 à 20 secondes suivant l’achèvement précédent de IOCTL.

Clients qui ne répondent pas ou se comportent mal

Si un client ne parvient pas à envoyer la demande de IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE requise pendant une période de dix à vingt secondes [10-20 s], le pilote doit supposer que le client a disparu. Dans des circonstances normales, les clients doivent actualiser leurs demandes bien en une seconde [1s]. Si cela se produit, le pilote doit définir le compteur « CompleteEventImmediately » sur zéro et ne doit pas incrémenter le compteur tant que le client ne se réveille pas et envoie l’IRP requis.

Mesures à prendre

Le pilote doit définir le compteur « CompleteEventImmediately » sur zéro et ne doit pas incrémenter le compteur si le client n’a pas envoyé de IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE de remplacement dans un délai de 10 à 20 secondes après la fin de l’instruction IOCTL précédente.