Assinaturas de mensagem NFP
Uma assinatura é representada como um identificador aberto exclusivo dentro do driver. Uma assinatura é ativada abrindo um identificador no namespace do dispositivo "Subs\". O tipo da assinatura é definido como sendo tudo após o prefixo "Subs\".
Um retorno de chamada na recepção da mensagem é dado por meio de um IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE concluído.
Uma assinatura pode ser temporariamente desabilitada por meio de um IOCTL_NFP_DISABLE.
Uma assinatura pode ser reabilitada por meio de um IOCTL_NFP_ENABLE.
Alças
Um cliente que deseja assinar um tipo de 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.
Ao abrir o identificador, um cliente define o tipo da assinatura da mensagem. Esse é o mesmo mecanismo usado com a publicação, exceto que o tipo é prefixado com "Subs\" em vez de "Pubs\".
Não há nenhum recurso para ler o tipo de volta.
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 assinaturas.
- 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.
- 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"
- Dois identificadores abertos para o mesmo tipo DEVEM representar duas entidades distintas.
- Se CreateFile for bem-sucedido, o identificador agora será um "identificador de assinatura" e NÃO DEVERÁ ser alterado para qualquer outro tipo de identificador.
- Depois que esse IOCTL for bem-sucedido e antes que o identificador seja fechado, sempre que uma mensagem for recebida por meio da tecnologia de proximidade que corresponda ao tipo dessa assinatura, os dados dessa mensagem DEVERão ser anexados ao identificador de arquivo para entrega ao cliente.
Cancelar assinatura
O cliente fechará o identificador de assinatura para parar de receber mensagens. 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, o driver DEVE recuperar toda a memória usada pela assinatura:
- O driver DEVE recuperar os dados de cadeia de caracteres de tipo.
- A fila recebida DEVE ser limpa e recuperada.
- Qualquer IOCTL pendente DEVE ser concluído com STATUS_CANCELLED.
Pares mal-intencionados
Se um dispositivo par mal-intencionado tentar um ataque de DOS (negação de serviço) por meio da tecnologia de proximidade, é possível que um cliente não consiga drenar a fila "Recebida" com rapidez suficiente para evitar o uso excessivo de memória pelo driver.
Ações necessárias
O driver NÃO DEVERÁ enfileirar ou entregar uma determinada mensagem ao cliente se essa mensagem for recebida quando 50 mensagens estiverem atualmente na fila "Recebido" (as mensagens mais recentes serão descartadas).
Clientes sem resposta ou com comportamento inadequado
Se um cliente parar de esvaziar a fila "Recebida" ao não enviar a solicitação de IOCTL_NFP_GET_NEXT_SUBSCRIBED_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 um IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE de substituição dentro de 10 a 20 segundos após a conclusão do IOCTL anterior.
Mensagens malformadas
É provável que o cliente descarte ou ignore todos os erros (exceto STATUS_BUFFER_OVERFLOW) retornados de IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE. Portanto, o driver não deve concluí-los com condições de erro apenas porque uma mensagem malformada foi recebida.
Ações necessárias
O driver NÃO DEVE entregar mensagens maiores que o tamanho máximo permitido da mensagem para o cliente.
O driver NÃO DEVE entregar mensagens de comprimento zero ao cliente.
O driver NÃO DEVE entregar mensagens parciais aos assinantes.
O driver NÃO DEVE entregar mensagens ao cliente que falharam em um CRC forte.
Nota A Certificação NFC Forum garante isso para provedores NFP habilitados para NFC.
O driver DEVE usar um transporte fortemente confiável e/ou tentar retransmissão de mensagens que falham em um CRC forte.
Nota A Certificação NFC Forum garante isso para provedores NFP habilitados para NFC.
Assinaturas duplicadas
O driver deve assumir que, se o cliente assina um tipo de mensagem duas vezes, é porque o cliente deseja receber a mensagem duas vezes quando a mensagem é recebida.
Ações necessárias
O driver DEVE aceitar e relatar assinaturas duplicadas, mesmo se assinado pelo mesmo cliente.