Compartir a través de

Publicación de mensajes NFP

  • Artículo

Una publicación se representa como un identificador abierto único dentro del controlador. Las publicaciones activas deben tener un tipo y un búfer de datos. El tipo se establece abriendo un nombre de archivo en el espacio de nombres "Pubs". El búfer de datos se establece enviando IOCTL_NFP_SET_PAYLOAD.

Una devolución de llamada al intentar la transmisión se da a través de un IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE completado.

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

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

Asas

Un cliente que quiera publicar un 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.

El cliente abrirá un identificador de archivo en "Pubs/<Protocol>".<SubTipo>" espacio de nombres relativo al dispositivo. El siguiente ejemplo es un ejemplo completo.

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

Después de abrir el identificador, un cliente debe establecer la carga del mensaje que se va a publicar con el IOCTL_NFP_SET_PAYLOAD.

No hay ninguna utilidad para leer el nombre de archivo especificado (el tipo de publicación).

Nombre de archivo

En el controlador CreateFile de un controlador, la interfaz de dispositivo SymbolicLink se quitará y solo permanecerá el nombre de archivo relativo al dispositivo. Este nombre de archivo será un búfer de cadena UTF-16LE con distinción entre mayúsculas y minúsculas que indica el tipo de publicación (o suscripción). El tamaño máximo de este búfer es de 502 caracteres, incluido el terminador NULL. El controlador debe analizar esta ruta de acceso en tres componentes constituyentes: "Pubs\", protocolo y subtipo.

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 publicaciones. El controlador PUEDE reconocer este tipo para conservar la compatibilidad. (Tenga en cuenta el uso de dos puntos en lugar del uso de un punto).
  • 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.
  • Dos identificadores abiertos al mismo tipo DEBEN representar dos entidades distintas.
  • 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"
    • "NFC"
    • "Iso14443Dep"
    • "Iso14443TypeA"
    • "Iso14443TypeB"
    • "Iso15693Vicinity"
    • "MifareClassic"
    • "MifareUltralight"
    • "FeliCa"

Cancelar publicación

Cuando un cliente ya no desea publicar un mensaje, cerrará el identificador de publicación. Esto indica que el mensaje ya no debe transmitirse. 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 (IRP_MJ_CLOSE), el controlador:
    • DEBE reclamar toda la memoria usada por la publicación (datos de tipo y mensaje), excepto los búferes para las transmisiones en curso de esta publicación.
    • NO DEBE transmitir el mensaje si un dispositivo se convierte en proxy en el futuro.
    • NO DEBE interrumpir ninguna transmisión en curso de la publicación.
  • El controlador PUEDE omitir IRP_MJ_CLEANUP.

El controlador debe suponer que si el cliente publica un mensaje dos veces, se debe a que el cliente quiere que el mensaje se transmita dos veces cuando un dispositivo esté cerca.

Acciones necesarias

El controlador DEBE aceptar y transmitir mensajes publicados duplicados, incluso si el mismo cliente lo publica.

Acciones necesarias

El controlador DEBE quitar todos los mensajes (y reclamar esos recursos) de la cola "Recibido" 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.

Clientes que no responden o tienen un comportamiento incorrecto

Si un cliente no puede enviar la solicitud de IOCTL_NFP_GET_NEXT_TRANSMITTED_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 una IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE de reemplazo en un plazo de 10 a 20 segundos de la finalización anterior de IOCTL.