Bagikan melalui

Menerbitkan pesan NFP

  • Artikel

Publikasi direpresentasikan sebagai handel terbuka unik dalam driver. Publikasi aktif harus memiliki jenis dan buffer data. Jenis diatur dengan membuka nama file di namespace layanan "Pubs". Buffer data diatur dengan mengirim IOCTL_NFP_SET_PAYLOAD.

Panggilan balik pada percobaan transmisi diberikan melalui IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE yang telah selesai.

Publikasi dapat dinonaktifkan sementara melalui IOCTL_NFP_DISABLE.

Publikasi dapat diaktifkan kembali melalui IOCTL_NFP_ENABLE.

Handles

Klien yang ingin menerbitkan pesan akan terlebih dahulu membuka handel baru ke driver. Menangani dari publikasi, langganan, dan sebagainya sebelumnya, tidak dapat digunakan kembali. Jika tidak lagi diperlukan, mereka akan ditutup oleh klien yang berperilaku baik.

Klien akan membuka handel file di "Pubs/<Protocol>.<SubTipe>" namespace perangkat relatif. Berikut ini adalah contoh lengkapnya.

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

Setelah membuka handel, klien kemudian harus mengatur payload pesan yang akan diterbitkan dengan IOCTL_NFP_SET_PAYLOAD.

Tidak ada fasilitas untuk membaca kembali nama file yang ditentukan (jenis publikasi).

Nama File

Dalam handler CreateFile driver, SymbolicLink Antarmuka Perangkat akan dilucuti dan hanya Nama File relatif perangkat yang akan tetap ada. Nama File ini akan menjadi buffer string UTF-16LE peka huruf besar/kecil yang menunjukkan jenis publikasi (atau langganan). Ukuran maksimum buffer ini adalah 502 karakter termasuk terminator NULL. Driver harus mengurai jalur ini menjadi tiga komponen konstituen: "Pubs\", protokol, dan subjenis.

Tindakan yang Diperlukan

  • Driver HARUS mengurai komponen protokol (sebelum '.' pertama). Setiap protokol yang tidak dikenal HARUS diselesaikan dengan STATUS_OBJECT_PATH_NOT_FOUND
  • Jika string tidak dihentikan NULL dalam panjang buffer, driver HARUS menyelesaikan IOCTL dengan STATUS_INVALID_PARAMETER.
  • Jika protokol memerlukan subjenis dan komponen subjenis buffer string kurang dari satu (1) karakter atau lebih dari 250 karakter, driver HARUS menyelesaikan IOCTL dengan STATUS_INVALID_PARAMETER.
  • Jika komponen protokol buffer string lebih panjang dari 250 karakter, driver HARUS menyelesaikan IOCTL dengan STATUS_INVALID_PARAMETER.
  • Driver HARUS menginterpretasikan NULL pertama sebagai akhir string.
  • Driver MUNGKIN mengenali jenis "Pairing:Bluetooth" untuk publikasi. Driver MUNGKIN mengenali jenis ini untuk mempertahankan kompatibilitas. (Perhatikan penggunaan titik dua daripada penggunaan titik.)
  • Driver HARUS mengenali jenis "WindowsUri".
  • Driver HARUS mengenali jenis "DeviceArrived" hanya untuk langganan.
  • Driver HARUS mengenali jenis "DeviceDeparted" hanya untuk langganan.
  • Driver HARUS mengenali jenis "WindowsMime" hanya untuk langganan.
  • Driver HARUS mengenali jenis "WindowsMime.".
  • Jika protokol hanya boleh dikenali untuk langganan, dan IOCTL menentukan "Pubs\", driver HARUS menyelesaikan IOCTL dengan STATUS_OBJECT_PATH_NOT_FOUND.
  • Jika protokol hanya boleh dikenali untuk publikasi, dan IOCTL menentukan "Subs\", driver HARUS menyelesaikan IOCTL dengan STATUS_OBJECT_PATH_NOT_FOUND.
  • Dua handel terbuka ke jenis yang sama HARUS mewakili dua entitas yang berbeda.
  • Beberapa protokol (namespace) dicadangkan. Kecuali ditentukan secara eksplisit dalam dokumen ini, driver TIDAK BOLEH mengenali protokol apa pun yang dimulai dengan:
    • "Windows"
    • "Perangkat"
    • "Pemasangan"
    • "NDEF"
    • "NFC"
    • "Iso14443Dep"
    • "Iso14443TypeA"
    • "Iso14443TypeB"
    • "Iso15693Vicinity"
    • "MifareClassic"
    • "MifareUltralight"
    • "FeliCa"

Batalkan penerbitan

Ketika klien tidak lagi ingin pesan diterbitkan, klien akan menutup handel publikasi. Ini menunjukkan pesan tidak boleh lagi dikirimkan. Jika proses klien berakhir, sistem akan menutup semua handel file yang terbuka atas nama klien.

Tindakan yang Diperlukan

  • Ketika handel ditutup (IRP_MJ_CLOSE), driver:
    • HARUS mengklaim kembali semua memori yang digunakan oleh publikasi (data jenis dan pesan) kecuali untuk buffer untuk transmisi yang sedang berlangsung dari publikasi ini.
    • TIDAK BOLEH mengirimkan pesan jika perangkat menjadi proksimasi di masa mendatang.
    • TIDAK BOLEH mengganggu transmisi publikasi yang sedang berlangsung.
  • Driver MAY mengabaikan IRP_MJ_CLEANUP.

Driver harus berasumsi bahwa jika klien menerbitkan pesan dua kali, itu karena klien ingin pesan dikirimkan dua kali ketika perangkat berada di dekatnya.

Tindakan yang Diperlukan

Driver HARUS menerima dan mengirimkan pesan duplikat yang diterbitkan, bahkan jika diterbitkan oleh klien yang sama.

Tindakan yang Diperlukan

Driver HARUS menghapus semua pesan (dan mengklaim kembali sumber daya tersebut) dari antrean "Diterima" jika klien belum mengirim penggantian IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE dalam waktu 10 - 20 detik dari penyelesaian IOCTL sebelumnya.

Klien Yang Tidak Responsif atau Berlagak Tidak Baik

Jika klien gagal mengirim permintaan IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE yang diperlukan untuk jangka waktu sepuluh hingga dua puluh detik [10-20 detik], driver harus berasumsi bahwa klien hilang. Dalam keadaan normal, klien harus me-refresh permintaan mereka dengan baik dalam satu detik [1s]. Jika ini terjadi, driver harus mengatur penghitung "CompleteEventImmediately" ke nol dan tidak boleh meningkatkan penghitung sampai klien bangun dan mengirim IRP yang diperlukan.

Tindakan yang Diperlukan

Driver harus mengatur penghitung "CompleteEventImmediately" ke nol dan tidak boleh menaikkan penghitung jika klien belum mengirim penggantian IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE dalam waktu 10 - 20 detik dari penyelesaian IOCTL sebelumnya.