StreamWriter ne videra pas dans NetworkStream

Question

Utilisation d'un StreamWriter pour écrire dans un NetworkStream et d'un StreamReader pour lire la réponse. L'application envoie des commandes et lit les réponses à un serveur de news.

Code simplifié (traitement sans erreur, 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();

Le code se bloque sur cette dernière ligne, attendant probablement que le flux de réseau envoie une réponse.

Je peux éviter de suspendre l'application en définissant une boucle de délai d'expiration à l'aide de serverReader.Peek () , mais le délai d'expiration est toujours dépassé. Je ne reçois jamais de réponse.

Si je fais un telnet sur le serveur et le port directement et que je saisis les commandes, je reçois une réponse immédiate.

Si j'appelle explicitement serverWriter.Flush () au lieu d'utiliser la propriété AutoFlush , je bloque toujours et ne reçoit jamais de réponse.

Des idées pour lesquelles je ne reçois pas de réponse au serveur en utilisant cette approche?

Merci!

résolu:

Le code ci-dessus fonctionne pour moi. Je suis donc revenu en arrière et j'ai basé ce code sur un code qui ne fonctionnerait pas.

Dans le code qui se bloque, j'utilisais toujours la boucle de délai d'attente avec serverReader.Peek (). Peek () retourne toujours -1, même s'il y a des données dans le tampon à lire !! Remplacer la boucle Peek () par un appel bloquant à ReadLine () résout mon problème.

J'ai mis la boucle de délai d'expiration à l'origine car l'application est multi-thread et je ne voulais pas bloquer. Je devrai revenir sur ce problème et voir comment résoudre le minutage des threads sans utiliser Peek ().

Merci à tous, bonnes réponses!

Answer 1

Le code ci-dessus fonctionne pour moi. Je suis donc revenu sur ce code pour en faire un code qui ne fonctionnerait pas.

Dans le code qui se bloque, j'utilisais toujours la boucle de délai d'attente avec serverReader.Peek (). Peek () retourne toujours -1, même s'il y a des données dans le tampon à lire !! Remplacer la boucle Peek () par un appel bloquant à ReadLine () résout mon problème.

J'ai mis la boucle de délai d'expiration à l'origine car l'application est multi-thread et je ne voulais pas bloquer. Je devrai revenir sur ce problème et voir comment résoudre le minutage des threads sans utiliser Peek ().

Merci à tous, bonnes réponses!

Answer 2

Je doute que le problème réside dans StreamWriter ... mais il existe un moyen simple de le savoir. Téléchargez WireShark et voyez ce que réellement va et vient sur le réseau. C'est de loin le moyen le plus simple de savoir ce qui se passe.

Answer 3

Essayez "& us; authinfo user username \ r \ n". Le RFC indique que les lignes de commande NNTP doivent être terminées par un CR-LF.