Compartir a través de

Suscripciones de mensajes de NFP

  • Artículo

Una suscripción se representa como un identificador abierto único dentro del controlador. Para activar una suscripción, abra un identificador en el espacio de nombres de dispositivo "Subs\". El tipo de la suscripción se define para que sea todo lo que sigue al prefijo "Subs\".

Una devolución de llamada en la recepción de mensajes se da a través de un IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE completado.

Una suscripción se puede deshabilitar temporalmente a través de un IOCTL_NFP_DISABLE.

Una suscripción se puede volver a habilitar a través de un IOCTL_NFP_ENABLE.

Asas

Un cliente que quiera suscribirse a un tipo de mensaje abrirá primero un nuevo identificador para el controlador. No se pueden reutilizar los identificadores de publicaciones anteriores, suscripciones, etc. Si ya no son necesarios, se cerrarán mediante un cliente bien comportado.

Al abrir el identificador, un cliente establece el tipo de la suscripción de mensaje. Este es el mismo mecanismo que se usa con la publicación, excepto que el tipo tiene el prefijo "Subs\" en lugar de "Pubs\".

No hay ninguna facilidad para leer el tipo.

Acciones necesarias

  • El controlador DEBE analizar el componente de protocolo (antes del primer "."). Cualquier protocolo no reconocido DEBE completarse con STATUS_OBJECT_PATH_NOT_FOUND
  • Si la cadena no termina en NULL dentro de la longitud del búfer, el controlador DEBE completar el IOCTL con STATUS_INVALID_PARAMETER.
  • Si el protocolo requiere un subtipo y el componente de subtipo del búfer de cadena es menor que un (1) carácter o más de 250 caracteres, el controlador DEBE completar el IOCTL con STATUS_INVALID_PARAMETER.
  • Si el componente de protocolo del búfer de cadena tiene más de 250 caracteres, el controlador DEBE completar el IOCTL con STATUS_INVALID_PARAMETER.
  • El controlador DEBE interpretar el primer VALOR NULL como final de la cadena.
  • El controlador PUEDE reconocer el tipo "Emparejamiento:Bluetooth" para las suscripciones.
  • El controlador DEBE reconocer el tipo "WindowsUri".
  • El controlador DEBE reconocer el tipo "DeviceArrived" solo para las suscripciones.
  • El controlador DEBE reconocer el tipo "DeviceDeparted" solo para las suscripciones.
  • El controlador DEBE reconocer el tipo "WindowsMime" solo para las suscripciones.
  • El controlador DEBE reconocer el tipo "WindowsMime".
  • Si el protocolo solo se debe reconocer para las suscripciones y el IOCTL especifica "Pubs\", el controlador DEBE completar el IOCTL con STATUS_OBJECT_PATH_NOT_FOUND.
  • Si el protocolo solo debe reconocerse para publicaciones y el IOCTL especifica "Subs\", el controlador DEBE completar el IOCTL con STATUS_OBJECT_PATH_NOT_FOUND.
  • Algunos protocolos (espacios de nombres) están reservados. A menos que se especifique explícitamente en este documento, el controlador NO DEBE reconocer ningún protocolo que comience por:
    • "Windows"
    • "Dispositivo"
    • "Emparejamiento"
    • "NDEF"
  • Dos identificadores abiertos al mismo tipo DEBEN representar dos entidades distintas.
  • Si CreateFile se realiza correctamente, el identificador ahora es un "identificador de suscripción" y NO DEBE cambiarse a ningún otro tipo de identificador.
  • Una vez que este IOCTL se realiza correctamente y antes de cerrar el identificador, cada vez que se recibe un mensaje a través de la tecnología de proximidad que coincide con el tipo de esta suscripción, los datos del mensaje deben adjuntarse al identificador de archivo para la entrega al cliente.

Cancelar suscripción

El cliente cerrará el identificador de suscripción para dejar de recibir mensajes. Si finaliza un proceso de cliente, el sistema cerrará todos los identificadores de archivo abiertos en nombre del cliente.

Acciones necesarias

Cuando se cierra el identificador, el controlador DEBE reclamar toda la memoria usada por la suscripción:

  • El controlador DEBE reclamar los datos de cadena de tipo.
  • La cola recibida debe purgarse y reclamarse.
  • Cualquier IOCTL con lápiz debe completarse con STATUS_CANCELLED.

Elementos del mismo nivel malintencion

Si un dispositivo del mismo nivel malintencionado intenta un ataque por denegación de servicio (DOS) a través de la tecnología de proximidad, es posible que un cliente no pueda purgar la cola "Recibida" lo suficientemente rápido como para evitar un uso excesivo de memoria por parte del controlador.

Acciones necesarias

El controlador NO DEBE poner en cola ni entregar un mensaje determinado al cliente si ese mensaje se recibe cuando 50 mensajes están actualmente en la cola "Recibido" (se quitan los mensajes más recientes).

Clientes que no responden o tienen un comportamiento incorrecto

Si un cliente deja de purgar la cola "Recibida" al no enviar la solicitud de IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE necesaria durante un período de diez a veinte segundos [10-20sec], el controlador debe suponer que el cliente ha desaparecido. En circunstancias normales, los clientes deben actualizar bien sus solicitudes dentro de un segundo [1s]. Si esto ocurre, el controlador debe establecer el contador "CompleteEventImmediately" en cero y no debe incrementar el contador hasta que el cliente se reactiva y envía el IRP necesario.

Acciones necesarias

El controlador debe establecer el contador "CompleteEventImmediately" en cero y no debe incrementar el contador si el cliente no ha enviado un reemplazo IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE en un plazo de 10 a 20 segundos de la finalización anterior de IOCTL.

Mensajes con formato incorrecto

Es probable que el cliente quite o omita todos los errores (excepto STATUS_BUFFER_OVERFLOW) devueltos de IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE. Por lo tanto, el controlador no debe completarlos con condiciones de error simplemente porque se recibió un mensaje con formato incorrecto.

Acciones necesarias

  • El controlador NO DEBE entregar mensajes mayores que el tamaño máximo permitido del mensaje al cliente.

  • El controlador NO DEBE entregar mensajes de longitud cero al cliente.

  • El controlador NO DEBE entregar mensajes parciales a los suscriptores.

  • El controlador NO DEBE entregar mensajes al cliente que han producido un error en un CRC fuerte.

    Nota La certificación del foro NFC garantiza esto para los proveedores NFP habilitados para NFC.

  • El controlador DEBE utilizar un transporte fuertemente confiable o intentar la retransmisión de mensajes que fallan en un CRC fuerte.

    Nota La certificación del foro NFC garantiza esto para los proveedores NFP habilitados para NFC.

Suscripciones duplicadas

El controlador debe suponer que si el cliente se suscribe a un tipo de mensaje dos veces, es porque el cliente quiere recibir el mensaje dos veces cuando se recibe el mensaje.

Acciones necesarias

El controlador DEBE aceptar y notificar suscripciones duplicadas, incluso si está suscrito por el mismo cliente.

Referencia de api de comunicaciones de campo cercano (NFC)