Condividi tramite

Pubblicazione di messaggi NFP

Una pubblicazione viene rappresentata come handle aperto univoco all'interno del driver. Le pubblicazioni attive devono avere sia un tipo che un buffer di dati. Il tipo viene impostato aprendo un nome file nello spazio dei nomi "Pub". Il buffer di dati viene impostato inviando IOCTL_NFP_SET_PAYLOAD.

Viene fornito un callback sulla trasmissione tentata tramite un IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE completato.

Una pubblicazione può essere disabilitata temporaneamente tramite un IOCTL_NFP_DISABLE.

Una pubblicazione può essere riabilitata tramite un IOCTL_NFP_ENABLE.

Selettori

Un client che vuole pubblicare un messaggio aprirà prima un nuovo handle al driver. Gli handle delle pubblicazioni, delle sottoscrizioni precedenti e così via non possono essere riutilizzati. Se non sono più necessari, verranno chiusi da un client ben comportamento.

Il client aprirà un handle di file in "Pub/<Protocollo>.<SottoTipo>" spazio dei nomi relativo al dispositivo. Di seguito è riportato un esempio 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

Dopo aver aperto l'handle, un client deve quindi impostare il payload del messaggio da pubblicare con l'IOCTL_NFP_SET_PAYLOAD.

Non è possibile leggere il nome del file specificato (tipo di pubblicazione).

File Name

Nel gestore CreateFile di un driver, l'interfaccia dispositivo SimbolicaLink verrà rimossa e rimarrà solo il nome file relativo al dispositivo. Questo nome file sarà un buffer stringa UTF-16LE con distinzione tra maiuscole e minuscole null che indica il tipo di pubblicazione (o sottoscrizione). La dimensione massima di questo buffer è di 502 caratteri, incluso il terminatore NULL. Il driver deve analizzare questo percorso in tre componenti costitutivi: "Pub\", protocollo e sottotipo.

Azioni richieste

  • Il driver DEVE analizzare il componente del protocollo (prima del primo '.'). Qualsiasi protocollo non riconosciuto DEVE essere completato con STATUS_OBJECT_PATH_NOT_FOUND
  • Se la stringa non viene terminata null all'interno della lunghezza del buffer, il driver DEVE completare L'IOCTL con STATUS_INVALID_PARAMETER.
  • Se il protocollo richiede un sottotipo e il componente di sottotipo del buffer stringa è minore di un carattere (1) o più di 250 caratteri, il driver DEVE completare l'IOCTL con STATUS_INVALID_PARAMETER.
  • Se il componente del protocollo del buffer stringa è più lungo di 250 caratteri, il driver DEVE completare IOCTL con STATUS_INVALID_PARAMETER.
  • Il driver DEVE interpretare il primo VALORE NULL come fine della stringa.
  • Il driver PUÒ riconoscere il tipo "Pairing:Bluetooth" per le pubblicazioni. Il driver PUÒ riconoscere questo tipo per mantenere la compatibilità. Si noti l'uso di due punti anziché l'uso di un punto.
  • Il driver DEVE riconoscere il tipo "WindowsUri".
  • Il driver DEVE riconoscere il tipo "DeviceArrived" solo per le sottoscrizioni.
  • Il driver DEVE riconoscere il tipo "DeviceDeparted" solo per le sottoscrizioni.
  • Il driver DEVE riconoscere il tipo "WindowsMime" solo per le sottoscrizioni.
  • Il driver DEVE riconoscere il tipo "WindowsMime".
  • Se il protocollo deve essere riconosciuto solo per le sottoscrizioni e IOCTL specifica "Pubs\", il driver DEVE completare IOCTL con STATUS_OBJECT_PATH_NOT_FOUND.
  • Se il protocollo deve essere riconosciuto solo per le pubblicazioni e L'IOCTL specifica "Subs\", il driver DEVE completare L'IOCTL con STATUS_OBJECT_PATH_NOT_FOUND.
  • Due handle aperti allo stesso tipo DEVONO rappresentare due entità distinte.
  • Alcuni protocolli (spazi dei nomi) sono riservati. A meno che non sia specificato in modo esplicito in questo documento, il driver NON DEVE riconoscere i protocolli che iniziano con:
    • "Windows"
    • "Dispositivo"
    • "Associazione"
    • "NDEF"
    • "NFC"
    • "Iso14443Dep"
    • "Iso14443TypeA"
    • "Iso14443TypeB"
    • "Iso15693Vicinity"
    • "MifareClassic"
    • "MifareUltralight"
    • "FeliCa"

Annulla pubblicazione

Quando un client non vuole più pubblicare un messaggio, chiuderà l'handle di pubblicazione. Questo indica che il messaggio non deve più essere trasmesso. Se un processo client termina, il sistema chiuderà tutti gli handle di file aperti per conto del client.

Azioni richieste

  • Quando l'handle è chiuso (IRP_MJ_CLOSE), il driver:
    • DEVE recuperare tutta la memoria usata dalla pubblicazione (sia di tipo che di dati del messaggio) tranne per i buffer per le trasmissioni in corso di questa pubblicazione.
    • NON trasmettere il messaggio se un dispositivo diventa proximate in futuro.
    • NON interrompere alcuna trasmissione in corso della pubblicazione.
  • Il driver PUÒ ignorare IRP_MJ_CLEANUP.

Il driver deve presumere che se il client pubblica un messaggio due volte, è perché il client vuole che il messaggio trasmesso due volte quando un dispositivo è in prossimità.

Azioni richieste

Il driver DEVE accettare e trasmettere messaggi pubblicati duplicati, anche se pubblicati dallo stesso client.

Azioni richieste

Il driver DEVE rimuovere tutti i messaggi (e recuperare queste risorse) dalla coda "Ricevuta" se il client non ha inviato una sostituzione IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE entro 10 - 20 secondi del completamento di IOCTL precedente.

Client non rispondenti o non rispondenti

Se un client non riesce a inviare la richiesta di IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE necessaria per un periodo di dieci-venti secondi [10-20sec], il driver deve presumere che il client sia andato via. In circostanze normali, i client devono aggiornare le richieste ben entro un secondo [1]. In questo caso, il driver deve impostare il contatore "CompleteEventImmediately" su zero e non deve aumentare il contatore finché il client non viene riattivato e invia l'IRP richiesto.

Azioni richieste

Il driver deve impostare il contatore "CompleteEventImmediately" su zero e non deve aumentare il contatore se il client non ha inviato una sostituzione IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE entro 10 - 20 secondi del completamento precedente di IOCTL.