Qual è il modo corretto di leggere da NetworkStream in .NET

Question

Ho avuto difficoltà con questo e non riesco a trovare una ragione per cui il mio codice non riesca a leggere correttamente da un server TCP che ho anche scritto. Sto usando la classe TcpClient e il suo metodo GetStream() ma qualcosa non funziona come previsto. O i blocchi di operazione indefinitamente (l'ultima operazione di lettura non ha scaduto come previsto), oi dati vengono ritagliati (per qualche ragione un'operazione di lettura restituisce 0 ed esce dal ciclo, forse il server non risponde abbastanza velocemente). Si tratta di tre tentativi di attuazione di questa funzione:

// this will break from the loop without getting the entire 4804 bytes from the server 
string SendCmd(string cmd, string ip, int port) 
{ 
    var client = new TcpClient(ip, port); 
    var data = Encoding.GetEncoding(1252).GetBytes(cmd); 
    var stm = client.GetStream(); 
    stm.Write(data, 0, data.Length); 
    byte[] resp = new byte[2048]; 
    var memStream = new MemoryStream(); 
    int bytes = stm.Read(resp, 0, resp.Length); 
    while (bytes > 0) 
    { 
     memStream.Write(resp, 0, bytes); 
     bytes = 0; 
     if (stm.DataAvailable) 
      bytes = stm.Read(resp, 0, resp.Length); 
    } 
    return Encoding.GetEncoding(1252).GetString(memStream.ToArray()); 
} 

// this will block forever. It reads everything but freezes when data is exhausted 
string SendCmd(string cmd, string ip, int port) 
{ 
    var client = new TcpClient(ip, port); 
    var data = Encoding.GetEncoding(1252).GetBytes(cmd); 
    var stm = client.GetStream(); 
    stm.Write(data, 0, data.Length); 
    byte[] resp = new byte[2048]; 
    var memStream = new MemoryStream(); 
    int bytes = stm.Read(resp, 0, resp.Length); 
    while (bytes > 0) 
    { 
     memStream.Write(resp, 0, bytes); 
     bytes = stm.Read(resp, 0, resp.Length); 
    } 
    return Encoding.GetEncoding(1252).GetString(memStream.ToArray()); 
} 

// inserting a sleep inside the loop will make everything work perfectly 
string SendCmd(string cmd, string ip, int port) 
{ 
    var client = new TcpClient(ip, port); 
    var data = Encoding.GetEncoding(1252).GetBytes(cmd); 
    var stm = client.GetStream(); 
    stm.Write(data, 0, data.Length); 
    byte[] resp = new byte[2048]; 
    var memStream = new MemoryStream(); 
    int bytes = stm.Read(resp, 0, resp.Length); 
    while (bytes > 0) 
    { 
     memStream.Write(resp, 0, bytes); 
     Thread.Sleep(20); 
     bytes = 0; 
     if (stm.DataAvailable) 
      bytes = stm.Read(resp, 0, resp.Length); 
    } 
    return Encoding.GetEncoding(1252).GetString(memStream.ToArray()); 
} 

L'ultimo "funziona", ma sembra certamente brutto a mettere un sonno hard-coded all'interno del ciclo si considera che le prese già supportano leggere timeout! Devo impostare alcune proprietà (i) sullo TcpClient del NetworkStream? Il problema risiede nel server? Il server non chiude le connessioni, è compito del client farlo. Quanto sopra è anche in esecuzione all'interno del contesto del thread UI (programma di test), forse ha qualcosa a che fare con questo ...

Qualcuno sa come utilizzare correttamente NetworkStream.Read per leggere i dati fino a quando non sono disponibili più dati? Immagino che ciò che desidero sia qualcosa di simile alle vecchie proprietà di timeout Win32 di Win32 ... ReadTimeout, ecc. Prova a leggere finché non viene raggiunto il timeout, quindi restituisce 0 ... Ma a volte sembra che restituisca 0 quando i dati dovrebbe essere disponibile (o sulla strada .. può leggere return 0 se è disponibile?) e quindi blocca indefinitamente sull'ultima lettura quando i dati non sono disponibili ...

Sì, sono in perdita!

Answer 1

Impostazione sottostante presa ReceiveTimeout proprietà ha fatto il trucco. Puoi accedervi in ​​questo modo: yourTcpClient.Client.ReceiveTimeout. È possibile leggere il docs per ulteriori informazioni.

Ora il codice "si addormenta" solo quando è necessario che alcuni dati arrivino nel socket o genera un'eccezione se nessun dato arriva, all'inizio di un'operazione di lettura, per più di 20 ms. Posso modificare questo timeout se necessario. Ora non sto pagando il prezzo di 20ms in ogni iterazione, lo sto pagando solo all'ultima operazione di lettura. Dal momento che ho il contenuto-lunghezza del messaggio nei primi byte letti dal server posso usarlo per ottimizzare ancora di più e non provare a leggere, se tutti i dati previsti è stato già ricevuto.

Trovo usando ReceiveTimeout molto più facile di attuazione lettura asincrono ... Ecco il codice di lavoro:

string SendCmd(string cmd, string ip, int port) 
{ 
    var client = new TcpClient(ip, port); 
    var data = Encoding.GetEncoding(1252).GetBytes(cmd); 
    var stm = client.GetStream(); 
    stm.Write(data, 0, data.Length); 
    byte[] resp = new byte[2048]; 
    var memStream = new MemoryStream(); 
    var bytes = 0; 
    client.Client.ReceiveTimeout = 20; 
    do 
    { 
     try 
     { 
      bytes = stm.Read(resp, 0, resp.Length); 
      memStream.Write(resp, 0, bytes); 
     } 
     catch (IOException ex) 
     { 
      // if the ReceiveTimeout is reached an IOException will be raised... 
      // with an InnerException of type SocketException and ErrorCode 10060 
      var socketExept = ex.InnerException as SocketException; 
      if (socketExept == null || socketExept.ErrorCode != 10060) 
       // if it's not the "expected" exception, let's not hide the error 
       throw ex; 
      // if it is the receive timeout, then reading ended 
      bytes = 0; 
     } 
    } while (bytes > 0); 
    return Encoding.GetEncoding(1252).GetString(memStream.ToArray()); 
} 

Answer 2

Secondo le vostre esigenze, Thread.Sleep è perfettamente adatto per l'uso perché non si è sicuri quando i dati saranno disponibili, quindi potrebbe essere necessario attendere che i dati diventino disponibili. Ho leggermente modificato la logica della tua funzione, questo potrebbe aiutarti un po 'oltre.

string SendCmd(string cmd, string ip, int port) 
{ 
    var client = new TcpClient(ip, port); 
    var data = Encoding.GetEncoding(1252).GetBytes(cmd); 
    var stm = client.GetStream(); 
    stm.Write(data, 0, data.Length); 
    byte[] resp = new byte[2048]; 
    var memStream = new MemoryStream(); 

    int bytes = 0; 

    do 
    { 
     bytes = 0; 
     while (!stm.DataAvailable) 
      Thread.Sleep(20); // some delay 
     bytes = stm.Read(resp, 0, resp.Length); 
     memStream.Write(resp, 0, bytes); 
    } 
    while (bytes > 0); 

    return Encoding.GetEncoding(1252).GetString(memStream.ToArray()); 
} 

Spero che questo aiuti!

Answer 3

Il codice di rete è notoriamente difficile da scrivere, testare e eseguire il debug.

Spesso un sacco di cose da considerare come:

• che cosa intende utilizzare per i dati che vengono scambiati (Intel x86/x64 si basa su little-endian) "Endian" - sistemi che usa big-endian può ancora leggere i dati che sono in little-endian (e viceversa), ma devono riorganizzare i dati. Quando si documenta il "protocollo" basta chiarire quale si sta utilizzando.

• ci sono delle "Impostazioni" che sono stati impostati sulle prese che possono influenzare il modo le si comporta "stream" (ad esempio SO_LINGER) - potrebbe essere necessario accendere certuni o disattivare se il codice è molto sensibile

• come fa la congestione nel mondo reale che provoca ritardi nel flusso di influenzare la lettura/scrittura logica

Se il "messaggio" vengono scambiati tra un client e un server (in entrambe le direzioni) può variare in termini di dimensioni quindi spesso è necessario utilizzare una strategia per far sì che quel "messaggio" venga scambiato in modo affidabile (ovvero Protocol).

Qui ci sono diversi modi per gestire lo scambio:

• hanno la dimensione del messaggio codificato in un colpo di testa che precede i dati - questo potrebbe essere semplicemente un "numero" nel primo 2/4/8 byte inviati (in base alla dimensione massima del messaggio) o potrebbe essere un'intestazione più esotica

• utilizzare un indicatore speciale "fine messaggio" (sentinella), con i dati reali codificati/fuggiti se esiste la possibilità di dati reali essere confuso con una "fine del marcatore"

• utilizzare un timeout .... i.e. un certo periodo di ricezione di nessun byte significa che non ci sono più dati per il messaggio - tuttavia, questo può essere soggetto a errori con timeout brevi, che possono essere facilmente colpiti su flussi congestionati.

• hanno un "comando" e un canale "dati" su "connessioni" separate .... questo è l'approccio utilizzato dal protocollo FTP (il vantaggio è la chiara separazione dei dati dai comandi ... a scapito di un 2 ° collegamento)

Ogni approccio ha i suoi pro e contro per "correttezza".

Il seguente codice utilizza il metodo "timeout", come che sembra essere quello che si desidera.

Vedi http://msdn.microsoft.com/en-us/library/bk6w7hs8.aspx. È possibile ottenere l'accesso al NetworkStream sul TCPClient in modo da poter cambiare il ReadTimeout.

string SendCmd(string cmd, string ip, int port) 
{ 
    var client = new TcpClient(ip, port); 
    var data = Encoding.GetEncoding(1252).GetBytes(cmd); 
    var stm = client.GetStream(); 
    // Set a 250 millisecond timeout for reading (instead of Infinite the default) 
    stm.ReadTimeout = 250; 
    stm.Write(data, 0, data.Length); 
    byte[] resp = new byte[2048]; 
    var memStream = new MemoryStream(); 
    int bytesread = stm.Read(resp, 0, resp.Length); 
    while (bytesread > 0) 
    { 
     memStream.Write(resp, 0, bytesread); 
     bytesread = stm.Read(resp, 0, resp.Length); 
    } 
    return Encoding.GetEncoding(1252).GetString(memStream.ToArray()); 
} 

Come nota per le altre varianti di questo codice di rete scrittura ... quando si fa un Read in cui si vuole evitare un "blocco", è possibile controllare il flag DataAvailable e poi leggere solo ciò che è nel buffer controllando la proprietà .Length es stm.Read(resp, 0, stm.Length);