다음을 통해 공유

NFP 메시지 게시

  • 아티클

게시는 드라이버 내에서 고유한 열린 핸들로 표시됩니다. 활성 게시에는 형식과 데이터 버퍼가 모두 있어야 합니다. 형식은 "Pubs" 네임스페이스에서 파일 이름을 열어 설정합니다. 데이터 버퍼는 IOCTL_NFP_SET_PAYLOAD 전송하여 설정됩니다.

완료된 IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE 통해 전송 시도에 대한 콜백이 제공됩니다.

게시는 IOCTL_NFP_DISABLE 통해 일시적으로 사용하지 않도록 설정할 수 있습니다.

게시는 IOCTL_NFP_ENABLE 통해 다시 사용하도록 설정할 수 있습니다.

핸들

메시지를 게시하려는 클라이언트는 먼저 드라이버에 대한 새 핸들을 엽니다. 이전 게시, 구독 등의 핸들은 다시 사용할 수 없습니다. 더 이상 필요하지 않은 경우 잘 동작하는 클라이언트에 의해 닫힙니다.

클라이언트는 "Pubs/<Protocol>"에서 파일 핸들을 엽니다.<SubType>" 디바이스 상대 네임스페이스입니다. 다음은 전체 예제입니다.

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

핸들을 연 후 클라이언트는 IOCTL_NFP_SET_PAYLOAD 함께 게시할 메시지의 페이 로드를 설정해야 합니다.

지정된 파일 이름(게시 형식)을 다시 읽을 수 있는 기능이 없습니다.

파일 이름

드라이버의 CreateFile 처리기에서 Device Interface SymbolicLink 는 제거되고 디바이스 상대 파일 이름만 유지됩니다. 이 파일 이름은 게시(또는 구독)의 형식을 나타내는 null로 끝나는 대/소문자 구분 UTF-16LE 문자열 버퍼입니다. 이 버퍼의 최대 크기는 NULL 종결자를 포함하여 502자입니다. 드라이버는 이 경로를 "Pubs\", 프로토콜 및 하위 형식의 세 가지 구성 요소로 구문 분석해야 합니다.

필요한 작업

  • 드라이버는 프로토콜 구성 요소(첫 번째 '.'이전)를 구문 분석해야 합니다. 인식할 수 없는 프로토콜은 STATUS_OBJECT_PATH_NOT_FOUND 완료해야 합니다.
  • 문자열이 버퍼 길이 내에서 NULL로 종료되지 않은 경우 드라이버는 STATUS_INVALID_PARAMETER 사용하여 IOCTL을 완료해야 합니다.
  • 프로토콜에 하위 형식이 필요하고 문자열 버퍼의 하위 형식 구성 요소가 1자 미만이거나 250자보다 긴 경우 드라이버는 STATUS_INVALID_PARAMETER 사용하여 IOCTL을 완료해야 합니다.
  • 문자열 버퍼의 프로토콜 구성 요소가 250자보다 긴 경우 드라이버는 STATUS_INVALID_PARAMETER 사용하여 IOCTL을 완료해야 합니다.
  • 드라이버는 첫 번째 NULL을 문자열의 끝으로 해석해야 합니다.
  • 드라이버는 게시에 대한 "페어링:Bluetooth" 유형을 인식할 수 있습니다. 드라이버는 호환성을 유지하기 위해 이 형식을 인식할 수 있습니다. (마침표가 아닌 콜론을 사용합니다.)
  • 드라이버는 "WindowsUri" 형식을 인식해야 합니다.
  • 드라이버는 구독에 대해서만 "DeviceArrived" 유형을 인식해야 합니다.
  • 드라이버는 구독에 대해서만 "DeviceDeparted" 유형을 인식해야 합니다.
  • 드라이버는 구독에 대해서만 "WindowsMime" 형식을 인식해야 합니다.
  • 드라이버는 "WindowsMime" 형식을 인식해야 합니다.
  • 프로토콜이 구독에 대해서만 인식되어야 하고 IOCTL이 "Pubs\"를 지정하는 경우 드라이버는 STATUS_OBJECT_PATH_NOT_FOUND 사용하여 IOCTL을 완료해야 합니다.
  • 프로토콜이 게시에 대해서만 인식되어야 하고 IOCTL이 "Subs\"를 지정하는 경우 드라이버는 STATUS_OBJECT_PATH_NOT_FOUND IOCTL을 완료해야 합니다.
  • 동일한 형식의 열린 핸들 2개는 두 개의 고유 엔터티를 나타내야 합니다.
  • 일부 프로토콜(네임스페이스)은 예약되어 있습니다. 이 문서에서 명시적으로 지정하지 않는 한 드라이버는 다음으로 시작하는 프로토콜을 인식하지 않아야 합니다.
    • "Windows"
    • "디바이스"
    • "페어링"
    • "NDEF"
    • "NFC"
    • "Iso14443Dep"
    • "Iso14443TypeA"
    • "Iso14443TypeB"
    • "Iso15693Vicinity"
    • "MifareClassic"
    • "MifareUltralight"
    • "FeliCa"

게시 취소

클라이언트가 더 이상 메시지를 게시하지 않으려면 게시 핸들을 닫습니다. 이는 메시지가 더 이상 전송되지 않음을 나타냅니다. 클라이언트 프로세스가 종료되면 시스템은 클라이언트를 대신하여 열려 있는 모든 파일 핸들을 닫습니다.

필요한 작업

  • 핸들이 닫힌 경우(IRP_MJ_CLOSE) 드라이버:
    • 이 게시의 지속적인 전송에 대한 버퍼를 제외하고 게시에서 사용하는 모든 메모리(형식 및 메시지 데이터 모두)를 회수해야 합니다.
    • 나중에 디바이스가 근접하게 되면 메시지를 전송하지 않아야 합니다.
    • 발행물의 진행 중인 전송을 중단해서는 안됩니다.
  • 드라이버는 IRP_MJ_CLEANUP 무시할 수 있습니다.

드라이버는 클라이언트가 메시지를 두 번 게시하는 경우 클라이언트가 디바이스가 근접할 때 메시지를 두 번 전송하기를 원하기 때문이라고 가정해야 합니다.

필요한 작업

드라이버는 동일한 클라이언트에서 게시한 경우에도 중복된 게시된 메시지를 수락하고 전송해야 합니다.

필요한 작업

클라이언트가 이전 IOCTL 완료 후 10~20초 이내에 대체 IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE 보내지 않은 경우 드라이버는 "수신됨" 큐에서 모든 메시지를 제거하고 해당 리소스를 회수해야 합니다.

응답하지 않거나 잘못된 클라이언트

클라이언트가 10~20초[10-20초]의 기간 동안 필요한 IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE 요청을 보내지 못하는 경우 드라이버는 클라이언트가 사라졌다고 가정해야 합니다. 정상적인 상황에서 클라이언트는 1초[1초] 이내에 요청을 새로 고쳐야 합니다. 이 경우 드라이버는 "CompleteEventImmediately" 카운터를 0으로 설정해야 하며 클라이언트가 절전 모드를 해제하고 필요한 IRP를 보낼 때까지 카운터를 증가시키지 않아야 합니다.

필요한 작업

드라이버는 "CompleteEventImmediately" 카운터를 0으로 설정해야 하며, 클라이언트가 이전 IOCTL 완료 후 10~20초 이내에 교체 IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE 보내지 않은 경우 카운터를 증가시키지 않아야 합니다.