IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE IOCTL (nfpdev.h)
El cliente envía la solicitud de IOCTL_NFP_GET_NEXT_SUBSCRIBED_MESSAGE al identificador de suscripción repetidamente para recibir mensajes suscritos a medida que llegan. Normalmente, este IOCTL se almacenará en el identificador de suscripción hasta que llegue un mensaje que coincida con el tipo suscrito.
Código principal
Búfer de entrada
None
Búfer de salida
Se requiere un búfer válido para devolver los datos del mensaje cuando llega. La primera DWORD de este búfer está reservada para una sugerencia al cliente para el siguiente tamaño del búfer que se va a devolver. Este búfer suele ser inicialmente de 255 bytes, pero el controlador puede solicitar que el cliente envíe un búfer más grande proporcionando solo la sugerencia y completando el IOCTL con STATUS_BUFFER_OVERFLOW.
Bloque de estado
Irp-IoStatus.Status> se establece en STATUS_SUCCESS si la solicitud se realiza correctamente.
De lo contrario, estado de la condición de error adecuada como código NTSTATUS.
Para obtener más información, vea Valores NTSTATUS.
Comentarios
- El cliente debe enviar otro IOCTL cada vez que se complete el lápiz. El controlador DEBE usar los bloqueos adecuados para garantizar que el número de finalizaciones correctas de este IOCTL equivale al número de recepciones de mensajes correctas para el tipo de suscripción.
-
A continuación se muestran las acciones necesarias al usar este IOCTL:
- Si este IOCTL se recibe en un identificador que no se abrió previamente en el espacio de nombres de dispositivo "Subs\", el controlador DEBE completarlo con STATUS_INVALID_DEVICE_STATE.
- El controlador debe mantener una cola de mensajes recibidos que coincidan con el tipo de suscripción dentro del identificador de archivo de suscripción.
-
Cuando se recibe este IOCTL en el controlador:
- Si la cola "Recibido" está vacía, el controlador DEBE escribir el IOCTL para su finalización posterior.
- Si la cola "Recibida" no está vacía, el controlador DEBE quitar de la cola un búfer de mensajes, copiar el búfer de mensajes en el búfer de salida del IOCTL y completar el IOCTL con STATUS_SUCCESS inmediatamente.
- Si se recibe un mensaje que coincide con el tipo y no hay ningún IOCTL actualmente en lápiz, el controlador DEBE agregar el búfer de mensajes a la cola "Recibida".
- Si se recibe un mensaje que coincide con el tipo y hay un IOCTL en lápiz disponible (la cola "Recibida" está vacía), el controlador DEBE copiar el búfer de mensajes en el búfer de salida del IOCTL y completar el IRP en lápiz con STATUS_SUCCESS. La cola "Recibida" DEBE seguir estando vacía después de la finalización del IRP en lápiz.
- Si el controlador completa este IOCTL con STATUS_SUCCESS, el primer DWORD [4 bytes] del búfer de salida DEBE contener una sugerencia para el tamaño del siguiente búfer de cliente y el campo Información de IOCTL DEBE contener el tamaño de este mensaje más sizeof(DWORD) (4 bytes).
- Si el IOCTL contiene un búfer de entrada, el controlador DEBE completar el IOCTL con STATUS_INVALID_PARAMETER.
- Si un mensaje recibido tiene una carga útil de longitud cero, el controlador DEBE omitir el mensaje. Se trata de una optimización del rendimiento porque Windows quitará los mensajes con cargas de longitud cero.
- Si un mensaje recibido es demasiado grande para copiarse en el búfer de este IOCTL, el controlador DEBE copiar el tamaño de búfer necesario en los primeros 4 bytes del búfer de salida, establezca el campo "Información" de IOCTL en sizeof(DWORD) ("4") y complete el IOCTL con STATUS_BUFFER_OVERFLOW. El búfer de mensajes debe dejarse en la cola "Recibido".
- Si se recibe este IOCTL mientras otro está actualmente en el identificador de suscripción, el segundo (o posterior) debe completarse con STATUS_INVALID_DEVICE_STATE.
- El controlador DEBE admitir CancelIo del IOCTL en lápiz.
Requisitos
| Requisito | Value |
|---|---|
| Cliente mínimo compatible | Windows 8 |
| Encabezado | nfpdev.h |
Consulte también
Guía de diseño general de comunicación de campo cercano (NFC)