Partilhar via

Publicando mensagens NFP

  • Artigo

Uma publicação é representada como um identificador aberto exclusivo dentro do driver. As publicações ativas devem ter um tipo e um buffer de dados. O tipo é definido abrindo um nome de arquivo no namespace "Pubs". O buffer de dados é definido enviando IOCTL_NFP_SET_PAYLOAD.

Um retorno de chamada na tentativa de transmissão é dado por meio de um IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE concluído.

Uma publicação pode ser temporariamente desabilitada por meio de um IOCTL_NFP_DISABLE.

Uma publicação pode ser habilitada novamente por meio de um IOCTL_NFP_ENABLE.

Alças

Um cliente que deseja publicar uma mensagem abrirá primeiro um novo identificador para o driver. Identificadores de publicações anteriores, assinaturas e assim por diante, não podem ser reutilizados. Se eles não forem mais necessários, eles serão fechados por um cliente bem comportado.

O cliente abrirá um identificador de arquivo no "Pubs/<Protocol>.<SubType>" namespace relativo ao dispositivo. O exemplo a seguir é um exemplo 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

Depois de abrir o identificador, um cliente deve definir o conteúdo da mensagem a ser publicada com o IOCTL_NFP_SET_PAYLOAD.

Não há nenhum recurso para ler o nome de arquivo especificado (o tipo de publicação).

Nome do Arquivo

No manipulador CreateFile de um driver, o SymbolicLink da Interface do Dispositivo será removido e somente o Nome de Arquivo relativo ao dispositivo permanecerá. Esse Nome de Arquivo será um buffer de cadeia de caracteres UTF-16LE que diferencia maiúsculas de minúsculas terminada em nulo que indica o tipo da publicação (ou assinatura). O tamanho máximo desse buffer é de 502 caracteres, incluindo o terminador NULL. O driver deve analisar esse caminho em três componentes constituintes: "Pubs\", protocolo e subtipo.

Ações necessárias

  • O driver DEVE analisar o componente de protocolo (antes do primeiro '.'). Qualquer protocolo não reconhecido DEVE ser concluído com STATUS_OBJECT_PATH_NOT_FOUND
  • Se a cadeia de caracteres não for terminada em NULL dentro do comprimento do buffer, o driver DEVERÁ concluir o IOCTL com STATUS_INVALID_PARAMETER.
  • Se o protocolo exigir um subtipo e o componente de subtipo do buffer de cadeia de caracteres for menor que um (1) caractere ou maior que 250 caracteres, o driver DEVERÁ concluir o IOCTL com STATUS_INVALID_PARAMETER.
  • Se o componente de protocolo do buffer de cadeia de caracteres tiver mais de 250 caracteres, o driver DEVERÁ concluir o IOCTL com STATUS_INVALID_PARAMETER.
  • O driver DEVE interpretar o primeiro NULL como o final da cadeia de caracteres.
  • O driver PODE reconhecer o tipo "Emparelhamento:Bluetooth" para publicações. O driver PODE reconhecer esse tipo para preservar a compatibilidade. (Observe o uso de dois-pontos em vez do uso de um ponto.)
  • O driver DEVE reconhecer o tipo "WindowsUri".
  • O driver DEVE reconhecer o tipo "DeviceArrived" somente para assinaturas.
  • O driver DEVE reconhecer o tipo "DeviceDeparted" somente para assinaturas.
  • O driver DEVE reconhecer o tipo "WindowsMime" somente para assinaturas.
  • O driver DEVE reconhecer o tipo "WindowsMime".
  • Se o protocolo só deve ser reconhecido para assinaturas e o IOCTL especifica "Pubs\", o driver DEVE concluir o IOCTL com STATUS_OBJECT_PATH_NOT_FOUND.
  • Se o protocolo só deve ser reconhecido para publicações e o IOCTL especifica "Subs\", o driver DEVE concluir o IOCTL com STATUS_OBJECT_PATH_NOT_FOUND.
  • Dois identificadores abertos para o mesmo tipo DEVEM representar duas entidades distintas.
  • Alguns protocolos (namespaces) são reservados. A menos que explicitamente especificado neste documento, o driver NÃO DEVE reconhecer nenhum protocolo que comece com:
    • “Windows”
    • "Dispositivo"
    • "Emparelhamento"
    • "NDEF"
    • "NFC"
    • "Iso14443Dep"
    • "Iso14443TypeA"
    • "Iso14443TypeB"
    • "Iso15693Vicinity"
    • "MifareClassic"
    • "MifareUltralight"
    • "FeliCa"

Cancelar Publicação

Quando um cliente não quiser mais publicar uma mensagem, ele fechará o identificador de publicação. Isso indica que a mensagem não deve mais ser transmitida. Se um processo de cliente for encerrado, o sistema fechará todos os identificadores de arquivo abertos em nome do cliente.

Ações necessárias

  • Quando o identificador é fechado (IRP_MJ_CLOSE), o driver:
    • DEVE recuperar toda a memória usada pela publicação (dados de tipo e mensagem), exceto para buffers para transmissões contínuas desta publicação.
    • NÃO DEVERÁ transmitir a mensagem se um dispositivo se tornar próximo no futuro.
    • NÃO DEVE interromper nenhuma transmissão em andamento da publicação.
  • O driver pode ignorar IRP_MJ_CLEANUP.

O driver deve assumir que, se o cliente publicar uma mensagem duas vezes, é porque o cliente deseja que a mensagem seja transmitida duas vezes quando um dispositivo estiver próximo.

Ações necessárias

O driver DEVE aceitar e transmitir mensagens publicadas duplicadas, mesmo que publicadas pelo mesmo cliente.

Ações necessárias

O driver DEVERÁ remover todas as mensagens (e recuperar esses recursos) da fila "Recebido" se o cliente não tiver enviado uma IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE de substituição dentro de 10 a 20 segundos após a conclusão do IOCTL anterior.

Clientes sem resposta ou com comportamento inadequado

Se um cliente não enviar a solicitação de IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE necessária por um período de dez a vinte segundos [10-20seg], o driver deverá assumir que o cliente desapareceu. Em circunstâncias normais, os clientes devem atualizar suas solicitações bem dentro de um segundo [1s]. Se isso ocorrer, o driver deverá definir o contador "CompleteEventImmediately" como zero e não deverá incrementar o contador até que o cliente seja ativado e envie o IRP necessário.

Ações necessárias

O driver deve definir o contador "CompleteEventImmediately" como zero e não deve incrementar o contador se o cliente não tiver enviado uma IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE de substituição dentro de 10 a 20 segundos após a conclusão do IOCTL anterior.