Condividi tramite

Sottoscrizioni dei messaggi NFP

  • Articolo

Una sottoscrizione viene rappresentata come handle aperto univoco all'interno del driver. Una sottoscrizione viene resa attiva aprendo un handle nello spazio dei nomi dei dispositivi "Subs\". Il tipo della sottoscrizione è definito come tutto il seguente del prefisso "Subs\".

Viene assegnato un callback alla ricezione dei messaggi tramite un IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE completato.

Una sottoscrizione può essere disabilitata temporaneamente tramite un IOCTL_NFP_DISABLE.

Una sottoscrizione può essere riabilitata tramite un IOCTL_NFP_ENABLE.

Selettori

Un client che vuole sottoscrivere un tipo di 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.

Nell'apertura dell'handle, un client imposta il tipo di sottoscrizione del messaggio. Si tratta dello stesso meccanismo usato con la pubblicazione, ad eccezione del fatto che il tipo è preceduto da "Subs\" anziché "Pub\".

Non esiste alcuna struttura per leggere il tipo.

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 sottoscrizioni.
  • 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.
  • 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"
  • Due handle aperti allo stesso tipo DEVONO rappresentare due entità distinte.
  • Se CreateFile ha esito positivo, l'handle è ora un "handle della sottoscrizione" e NON DEVE essere modificato in qualsiasi altro tipo di handle.
  • Dopo che questo IOCTL ha esito positivo e prima che l'handle venga chiuso, ogni volta che un messaggio viene ricevuto tramite la tecnologia di prossimità che corrisponde al tipo di questa sottoscrizione, i dati del messaggio devono essere collegati all'handle di file per il recapito al client.

Annullare la sottoscrizione

Il client chiuderà l'handle della sottoscrizione per interrompere la ricezione dei messaggi. Se un processo client termina, il sistema chiuderà tutti gli handle di file aperti per conto del client.

Azioni richieste

Quando l'handle viene chiuso, il driver DEVE recuperare tutta la memoria usata dalla sottoscrizione:

  • Il driver DEVE recuperare i dati della stringa di tipo.
  • La coda ricevuta DEVE essere eliminata e recuperata.
  • Qualsiasi IOCTL penna deve essere completato con STATUS_CANCELLED.

Peer dannosi

Se un dispositivo peer dannoso tenta un attacco DOS (Denial of Service) tramite la tecnologia di prossimità, è possibile che un client non possa svuotare la coda "Ricevuta" abbastanza velocemente per impedire l'utilizzo eccessivo della memoria dal driver.

Azioni richieste

Il driver NON deve accodare o recapitare un determinato messaggio al client se tale messaggio viene ricevuto quando 50 messaggi sono attualmente presenti nella coda "Ricevuta" (i messaggi più recenti vengono eliminati).

Client non rispondenti o non rispondenti

Se un client smette di svuotare la coda "Ricevuta" non inviando la richiesta di IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE richiesta necessaria per un periodo di dieci-venti secondi [10-20sec], il driver deve presupporre che il client sia andato. 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_SUBSCRIBED_MESSAGE entro 10 - 20 secondi del completamento precedente di IOCTL.

Messaggi non formattati

Il client è probabilmente in grado di eliminare o ignorare tutti gli errori (ad eccezione di STATUS_BUFFER_OVERFLOW) restituiti da IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE. Pertanto, il driver non dovrebbe completare queste condizioni di errore semplicemente perché è stato ricevuto un messaggio non valido.

Azioni richieste

  • Il driver NON DEVE recapitare messaggi superiori alle dimensioni massime consentite del messaggio al client.

  • Il driver NON DEVE recapitare messaggi a lunghezza zero al client.

  • Il driver NON DEVE recapitare messaggi parziali ai sottoscrittori.

  • Il driver NON DEVE recapitare messaggi al client che non ha avuto esito positivo.

    Nota La certificazione del forum NFC garantisce questa funzionalità per i provider NFP abilitati per NFC.

  • Il driver DEVE usare un trasporto fortemente affidabile e/o tentativo di ritrasmissione dei messaggi che hanno esito negativo su un CRC sicuro.

    Nota La certificazione del forum NFC garantisce questa funzionalità per i provider NFP abilitati per NFC.

Sottoscrizioni duplicate

Il driver deve presupporre che se il client sottoscrive due volte un tipo di messaggio, è perché il client vuole ricevere il messaggio due volte quando il messaggio viene ricevuto.

Azioni richieste

Il driver DEVE accettare e segnalare sottoscrizioni duplicate, anche se sottoscritto dallo stesso client.

Informazioni di riferimento sulle API NFC (Near Field Communications)