Partager via

Abonnements aux messages NFP

  • Article

Un abonnement est représenté sous la forme d’un handle ouvert unique au sein du pilote. Un abonnement est activé en ouvrant un handle dans l’espace de noms d’appareil « Subs\ ». Le type de l’abonnement est défini comme étant tout ce qui suit le préfixe « Subs\ ».

Un rappel à la réception des messages est donné via un IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE terminé.

Un abonnement peut être temporairement désactivé via un IOCTL_NFP_DISABLE.

Un abonnement peut être réactivé via un IOCTL_NFP_ENABLE.

Poignées

Un client qui souhaite s’abonner à un type de message ouvre d’abord un nouveau handle au 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é.

Lors de l’ouverture du handle, un client définit le type de l’abonnement au message. Il s’agit du même mécanisme que celui utilisé avec la publication, sauf que le type est précédé de « Subs\ » au lieu de « Pubs\ ».

Il n’existe aucune possibilité de lire le 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 « Appairage :Bluetooth » pour les abonnements.
  • 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.
  • 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 »
  • Deux handles ouverts du même type DOIVENT représenter deux entités distinctes.
  • Si CreateFile réussit, le handle est désormais un « handle d’abonnement » et NE DOIT PAS être remplacé par un autre type de handle.
  • Une fois ce IOCTL réussi, et avant la fermeture du handle, chaque fois qu’un message est reçu via la technologie de proximité qui correspond au type de cet abonnement, les données de ce message DOIVENT être attachées au handle de fichier pour la remise au client.

Se désabonner

Le client ferme le handle d’abonnement afin de cesser de recevoir des messages. 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é, le pilote DOIT récupérer toute la mémoire utilisée par l’abonnement :

  • Le pilote DOIT récupérer les données de chaîne de type.
  • La file d’attente reçue DOIT être vidée et récupérée.
  • Tout IOCTL suspendu DOIT être terminé avec STATUS_CANCELLED.

Homologues malveillants

Si un appareil d’homologue malveillant tente une attaque par déni de service (DOS) via la technologie de proximité, il est possible qu’un client ne puisse pas vider la file d’attente « Reçu » assez rapidement pour empêcher une utilisation excessive de la mémoire par le pilote.

Mesures à prendre

Le pilote NE DOIT PAS mettre en file d’attente ou remettre un message donné au client si ce message est reçu alors que 50 messages se trouvent actuellement dans la file d’attente « Reçu » (les messages les plus récents sont supprimés).

Clients qui ne répondent pas ou se comportent mal

Si un client cesse de vider la file d’attente « Reçu » en ne parvenant pas à envoyer la demande de IOCTL_NFP_GET_NEXT_SUBSCRIBED_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_SUBSCRIBED_MESSAGE de remplacement dans un délai de 10 à 20 secondes après l’achèvement précédent du IOCTL.

Messages mal formés

Le client est susceptible de supprimer ou d’ignorer toutes les erreurs (à l’exception des STATUS_BUFFER_OVERFLOW) retournées par IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE. Par conséquent, le pilote ne doit pas les terminer avec des conditions d’erreur simplement parce qu’un message mal formé a été reçu.

Mesures à prendre

  • Le pilote NE DOIT PAS remettre au client des messages dont la taille est supérieure à la taille maximale autorisée.

  • Le pilote NE DOIT PAS remettre de messages de longueur nulle au client.

  • Le pilote NE DOIT PAS remettre des messages partiels aux abonnés.

  • Le pilote NE DOIT PAS remettre des messages au client qui ont échoué à un CRC fort.

    Note La certification forum NFC garantit cela pour les fournisseurs NFP compatibles NFC.

  • Le conducteur DOIT utiliser un transport très fiable et/ou une tentative de retransmission de messages qui échouent à un CRC fort.

    Note La certification forum NFC garantit cela pour les fournisseurs NFP compatibles NFC.

Abonnements dupliqués

Le pilote doit supposer que si le client s’abonne deux fois à un type de message, c’est parce que le client souhaite recevoir le message deux fois lorsque le message est reçu.

Mesures à prendre

Le pilote DOIT accepter et signaler les abonnements en double, même s’il est souscrit par le même client.

Informations de référence sur l’API NFC (Near Field Communications)