2009-04-27 11 views
6

HttpListener le da la secuencia de respuesta, pero llamar "flush" no significa nada (y de fuentes está claro, porque en realidad no está haciendo nada). La exploración dentro de la API HTTP muestra que esto es una limitación de HttpListener.Cómo vaciar el flujo de respuesta de HttpListener?

¿Alguien sabe exactamente cómo descargar la secuencia de respuesta de HttpListener (puede ser con reflexión o P/Invocaciones adicionales)?

Actualización: No puede transmitir http nada si no tiene una opción de descarga o capacidad para definir el tamaño del búfer.

Respuesta

2

La descarga solo funciona en la mayor parte del espacio de nombres de System.Net cuando Transfer-Encoding está configurado en Chuncked, de lo contrario, se devuelve toda la solicitud y Flush realmente no hace nada. Al menos esto es lo que he experimentado al trabajar con HttpWebResponse.

+0

La pregunta no es POR QUÉ no está funcionando ... Pero imagine la transmisión http donde es importante enviar algo lo antes posible. Los datos fragmentados no son una opción aquí en absoluto. HttpListener realmente envía algo ANTES de que hayas terminado de solicitarlo, pero está usando un buffer no configurable bastante grande. – Mash

+0

Y, por cierto, ASP.NET se vacía bien cuando lo estás preguntando ... ASP.NET requiere algunos hacks para obtener contenido de InputStream antes de que se haya recuperado el cuerpo de POST completo, pero OutputStream funciona bien. – Mash

+1

HTTP no es realmente un protocolo de transmisión. Está destinado a transmitir texto a través de Internet, de ahí el nombre protocolo de transmisión de hipertexto. Si quieres transmisión, sugeriría un socket. O algo un poco mejor en la transmisión de contenido en paquetes lo suficientemente pequeños como para que pueda controlar. –

0

No he intentado esto todavía, pero ¿qué hay de escribir un servidor TCP separado para transmitir las respuestas? A continuación, reenvíe la solicitud del HttpListener al servidor tcp "interno". Al usar este redireccionamiento, es posible que pueda transmitir los datos de vuelta según lo necesite.

En cuanto a enjuagarlo, lo único que veo es simular un desecho, sin desecharlo. Si puede hackear el objeto HttpResponseStream, decirle que deseche, desarmar el indicador m_Closed, etc., es posible que pueda vaciar los datos de transmisión.

+0

¿Escribir un servidor TCP separado? Es mejor escribir todo con TcpListener (que es más rápido que .NET Sockets), pero es mucho más lento que HttpListener. Comprobaré las fuentes de eliminación, pero no es el camino correcto. Si vaciar o no en http.sys se define con el paquete de datos en sí. – Mash