Domanda

Utilizzo di un StreamWriter per scrivere su un NetworkStream e un StreamReader per leggere la risposta. L'app sta inviando comandi e sta leggendo le risposte a un server di notizie.

Codice semplificato (gestione errori sans, ecc.):

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();

Il codice si blocca su quest'ultima riga, presumibilmente in attesa che il flusso di rete invii una risposta.

Posso evitare di sospendere l'app impostando un loop di timeout usando serverReader.Peek () , ma lo farò sempre; Non ricevo mai una risposta.

Se telnet al server e porto direttamente e inserisco i comandi, ottengo una risposta immediata.

Se chiamo serverWriter.Flush () esplicitamente, invece di utilizzare la proprietà AutoFlush , continuo a bloccare e non ricevo mai una risposta.

Qualche idea sul perché non ottengo una risposta al server usando questo approccio?

Grazie!

Risolto:

Il codice precedente funziona per me, quindi sono tornato indietro e ho costruito quel codice sul codice che non funzionava.

Nel codice che si blocca, stavo ancora usando il ciclo di timeout con serverReader.Peek (). Peek () restituisce sempre -1, anche se ci sono dati nel buffer da leggere !! Sostituire il ciclo Peek () con una chiamata di blocco a ReadLine () risolve il mio problema.

Ho inserito il ciclo di timeout in origine perché l'app è multi-thread e non volevo bloccare. Dovrò rivisitare questo problema e vedere come posso risolvere i tempi del thread senza usare Peek ().

Grazie a tutti, buone risposte!

È stato utile?

Soluzione 3

Il codice sopra funziona per me, quindi sono tornato indietro e ho costruito quel codice sul codice che non funzionava.

Nel codice che si blocca, stavo ancora usando il ciclo di timeout con serverReader.Peek (). Peek () restituisce sempre -1, anche se ci sono dati nel buffer da leggere !! Sostituire il ciclo Peek () con una chiamata di blocco a ReadLine () risolve il mio problema.

Ho inserito il ciclo di timeout in origine perché l'app è multi-thread e non volevo bloccare. Dovrò rivisitare questo problema e vedere come posso risolvere i tempi del thread senza usare Peek ().

Grazie a tutti, buone risposte!

Altri suggerimenti

Dubito che sia il StreamWriter il problema ... ma c'è un modo semplice per scoprirlo. Scarica WireShark e vedi cosa sta succedendo in realtà sulla rete. Questo è di gran lunga il modo più semplice per scoprire cosa sta succedendo.

Prova " nome utente utente authinfo \ r \ n " ;. La RFC afferma che le righe di comando NNTP devono essere terminate da un CR-LF.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top