StreamWriter no se irá al NetworkStream

Question

Usando un StreamWriter para escribir en un NetworkStream , y un StreamReader para leer la respuesta. La aplicación está enviando comandos y leyendo respuestas a un servidor de noticias.

Código simplificado (sin manejo de errores, etc.):

tcpClient = new TcpClient();
tcpClient.Connect(Name, Port);

networkStream = tcpClient.GetStream();
serverReader = new StreamReader(networkStream, Encoding.Default);
serverWriter = new StreamWriter(networkStream, Encoding.ASCII) {
                     AutoFlush = true
                   };

// reads the server's response to the connect:  "200 news.newsserver.com"
// commenting out these lines doesn't solve the problem
while (serverReader.Peek() > -1) {
    serverReader.ReadLine();
}

serverWriter.WriteLine("authinfo user username");

// expect response "381 more authentication required", but code just blocks
string response = serverReader.ReadLine();

El código se bloquea en esa última línea, probablemente esperando que la secuencia de la red envíe una respuesta.

Puedo evitar colgar la aplicación configurando un bucle de tiempo de espera utilizando serverReader.Peek () , pero siempre lo haré. Nunca recibo una respuesta.

Si hago telnet al servidor y al puerto directamente y entro los comandos, obtengo una respuesta inmediata.

Si llamo a serverWriter.Flush () de forma explícita, en lugar de usar la propiedad AutoFlush , todavía bloqueo y nunca obtengo una respuesta.

¿Alguna idea de por qué no obtengo una respuesta al servidor utilizando este enfoque?

¡Gracias!

Resuelto:

El código anterior funciona para mí, así que volví y construí ese código para el código que no funcionaría.

En el código que se bloquea, todavía estaba usando el bucle de tiempo de espera con serverReader.Peek (). Peek () siempre devuelve -1, ¡aunque hay datos en el búfer para leer! Reemplazar el bucle Peek () con una llamada de bloqueo a ReadLine () resuelve mi problema.

Puse el bucle de tiempo de espera originalmente porque la aplicación tiene varios subprocesos y no quería bloquear. Tendré que revisar este problema y ver cómo puedo resolver el tiempo de subprocesos sin usar Peek ().

¡Gracias a todos, buenas respuestas!

Answer 1

El código anterior funciona para mí, por lo que volví y construí ese código con el código que no funcionaría.

En el código que se bloquea, todavía estaba usando el bucle de tiempo de espera con serverReader.Peek (). Peek () siempre devuelve -1, ¡aunque hay datos en el búfer para leer! Reemplazar el bucle Peek () con una llamada de bloqueo a ReadLine () resuelve mi problema.

Puse el bucle de tiempo de espera originalmente porque la aplicación tiene varios subprocesos y no quería bloquear. Tendré que revisar este problema y ver cómo puedo resolver el tiempo de subprocesos sin usar Peek ().

¡Gracias a todos, buenas respuestas!

Answer 2

Dudo que el StreamWriter sea el problema ... pero hay una forma sencilla de averiguarlo. Descargue WireShark y vea lo que en realidad está entrando y saliendo en la red. Esa es, de lejos, la forma más sencilla de descubrir qué está pasando.

Answer 3

Intente " nombre de usuario del usuario authinfo \ r \ n " ;. El RFC dice que las líneas de comando NNTP deben ser terminadas por un CR-LF.