NFP 메시지 구독

  • 아티클

구독은 드라이버 내에서 고유한 열린 핸들로 표시됩니다. 구독은 "Subs\" 디바이스 네임스페이스에 대한 핸들을 열어 활성화됩니다. 구독 유형은 "Subs\" 접두사 다음의 모든 항목으로 정의됩니다.

완료된 IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE 통해 메시지 수신에 대한 콜백이 제공됩니다.

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

IOCTL_NFP_ENABLE 통해 구독을 다시 사용하도록 설정할 수 있습니다.

핸들

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

핸들을 열 때 클라이언트는 메시지 구독의 유형을 설정합니다. 형식에 "Pubs\" 대신 "Subs\"가 접두사로 추가된다는 점을 제외하고 게시에 사용되는 것과 동일한 메커니즘입니다.

형식을 다시 읽을 수 있는 기능이 없습니다.

필요한 작업

  • 드라이버는 프로토콜 구성 요소(첫 번째 '.' 이전)를 구문 분석해야 합니다. 인식할 수 없는 프로토콜은 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을 완료해야 합니다.
  • 일부 프로토콜(네임스페이스)은 예약되어 있습니다. 이 문서에서 명시적으로 지정하지 않는 한 드라이버는 다음으로 시작하는 프로토콜을 인식할 수 없습니다.
    • "Windows"
    • "디바이스"
    • "페어링"
    • "NDEF"
  • 동일한 형식의 열린 핸들 2개는 두 개의 고유 엔터티를 나타내야 합니다.
  • CreateFile이 성공하면 핸들은 이제 "구독 핸들"이 되며 다른 유형의 핸들로 변경해서는 안 됩니다.
  • 이 IOCTL이 성공하고 핸들을 닫기 전에 이 구독의 유형과 일치하는 근접 기술을 통해 메시지를 받을 때마다 해당 메시지의 데이터를 클라이언트에 배달하기 위해 파일 핸들에 연결해야 합니다.

구독 취소

클라이언트는 메시지 수신을 중지하기 위해 구독 핸들을 닫습니다. 클라이언트 프로세스가 종료되면 시스템은 클라이언트를 대신하여 열려 있는 모든 파일 핸들을 닫습니다.

필요한 작업

핸들이 닫힌 경우 드라이버는 구독에서 사용하는 모든 메모리를 회수해야 합니다.

  • 드라이버는 형식 문자열 데이터를 회수해야 합니다.
  • 수신된 큐를 제거하고 회수해야 합니다.
  • 보류 중인 IOCTL은 STATUS_CANCELLED 완료해야 합니다.

악의적인 피어

악의적인 피어 디바이스가 근접 기술을 통해 DOS(서비스 거부) 공격을 시도하는 경우 클라이언트가 드라이버의 과도한 메모리 사용을 방지하기 위해 "수신됨" 큐를 빠르게 드레이닝할 수 없을 수 있습니다.

필요한 작업

현재 50개 메시지가 "수신됨" 큐에 있을 때(최신 메시지가 삭제됨) 메시지가 수신되면 드라이버는 클라이언트에 지정된 메시지를 큐에 대기하거나 배달하지 않아야 합니다.

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

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

필요한 작업

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

잘못된 형식의 메시지

클라이언트는 IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE 반환된 모든 오류(STATUS_BUFFER_OVERFLOW 제외)를 삭제하거나 무시할 수 있습니다. 따라서 드라이버가 잘못된 형식의 메시지를 수신했기 때문에 오류 조건으로 완료하면 안 됩니다.

필요한 작업

  • 드라이버는 허용되는 최대 메시지 크기보다 큰 메시지를 클라이언트에 전달해서는 안됩니다.

  • 드라이버는 클라이언트에 길이가 0인 메시지를 전달해서는 안 됩니다.

  • 드라이버는 구독자에게 부분 메시지를 전달해서는 안 됩니다.

  • 드라이버는 강력한 CRC에 실패한 메시지를 클라이언트에 전달해서는 안됩니다.

    참고 NFC 포럼 인증은 NFC 지원 NFP 공급자에 대해 이를 보장합니다.

  • 드라이버는 강력한 CRC에 실패한 메시지의 강력한 전송 및/또는 재전송을 사용해야 합니다.

    참고 NFC 포럼 인증은 NFC 지원 NFP 공급자에 대해 이를 보장합니다.

중복 구독

드라이버는 클라이언트가 메시지 형식을 두 번 구독하는 경우 클라이언트가 메시지를 받을 때 메시지를 두 번 받기를 원하기 때문이라고 가정해야 합니다.

필요한 작업

드라이버는 동일한 클라이언트에서 구독한 경우에도 중복 구독을 수락하고 보고해야 합니다.

NFC(근거리 통신) API 참조