2011-01-02 7 views
8

Acabo de tropezar con el HTTP Server API de Microsoft. La introducción indica:Uso de HttpApi con puertos de finalización de E/S

La API del servidor HTTP permite que las aplicaciones se comuniquen a través de HTTP sin usar el servidor de información de Internet de Microsoft (IIS). Las aplicaciones pueden registrarse para recibir solicitudes HTTP para URL particulares, recibir solicitudes HTTP y enviar respuestas HTTP. La API del servidor HTTP incluye soporte SSL para que las aplicaciones puedan intercambiar datos a través de conexiones HTTP seguras sin IIS. También está diseñado para funcionar con puertos de terminación de E/S.

Encontrando esto genial, eché un largo vistazo a la lista de funciones para ambas versiones de la API. Ahora, la única otra parte de la documentación que menciona los puertos de terminación de E/S es la función HttpReceiveHttpRequest(). El último parámetro es un OVERLAPPED estructura opcional con la siguiente descripción:

Para las llamadas asíncronas, establecer pOverlapped para que apunte a una estructura OVERLAPPED; para llamadas sincrónicas, configúrelo en NULL. Una llamada síncrona bloquea hasta que una solicitud ha llegado a la cola especificada y parte o la totalidad ha sido recuperada, mientras que una llamada asíncrona devuelve inmediatamente ERROR_IO_PENDING y la aplicación que llama utiliza GetOverlappedResult()o puertos de terminación de E/S para determinar cuándo se realiza la operación terminado. Para obtener más información sobre el uso de estructuras OVERLAPPED para la sincronización, consulte Synchronization and Overlapped Input and Output.

No hay más información, y todas las estructuras son opacas y ocultan deliberadamente la información de conexión. También observe que el tema Sincronización y Superposición de entrada y salida no menciona la API HTTP.

¿Alguien tiene alguna idea sobre cómo conectar la cola de la API HTTP a un puerto de E/S de finalización?

+0

¿Tiene algún motivo para creer que no pasaría simplemente el controlador a la cola como primer parámetro de CreateIoCompletionPort? – Gabe

+2

No. No tengo ninguna razón para creer que eso sea lo correcto tampoco. –

Respuesta

3

El uso de los puertos de finalización Io es trivialmente simple en teoría, pero en la práctica abomnible: P

el uso "normal" es: CreateIOCompletionPort

  1. llamada para crear un mango de puerto de finalización IO.
  2. Cree un grupo de subprocesos y haga que cada subproceso en bucle, en una llamada a GetOverlappedResult. GetOverlappedResult se devolverá cuando se complete una operación solapada asociada con el puerto, con estructuras que indiquen qué identificador y operación se completaron.
  3. A medida que su programa se ejecuta y crea objetos que desea manejar de forma asincrónica, asocia cada identificador con el manejador IO CompletionPort llamando nuevamente a CreateIOCompletionPort.

Ahora, cada vez que la aplicación emite una operación asincrónica en el mango (que se señaliza mediante el paso en un struct OVERLAPPED) la notificación de la operación se ha completado será indicado por uno de los hilos eso espera en GetOverlappedResult volver.

La implicación clara es que HANDLE devuelto por HttpCreateRequestQueue se puede asociar con un puerto de finalización de IO y las operaciones asincrónicas posteriores darán lugar a que GetOverlappedResult devuelva el resultado de la operación.

+0

Sí, tengo un servidor basado en el puerto de terminación de E/S existente. Sin embargo, no comparto exactamente la idea de que la implicación sea "clara". Lo probaré para ver cómo va eso. –

Cuestiones relacionadas