TcpClient.GetStream() Read() vs. TcpClient.Client.Receive()

Question

.NET permette due modi molto simili di "leggere" dalla rete (supponendo connessione TCP):

1. TcpClient.GetStream().Read() 
2. TcpClient.Client.Receive() 

Osservando al codice sorgente di NetworkStream - sembra che sia un involucro aggiuntivo rispetto al socket sottostante, che alla fine chiama i metodi Socket.

Domanda: qual è il vantaggio dell'uso della variazione "indiretta" di NetworkStream (n. 1), anziché utilizzare il wrapper diretto fornito dall'implementazione di Socket?

Grazie, Boris.

Answer 1

Esiste, in effetti, un chiaro vantaggio dell'utilizzo della prima opzione (TcpStream e non Socket). Il vantaggio è che l'API del flusso è più flessibile quando sono necessarie diverse implementazioni sottostanti per lo stesso programma.

Ad esempio, un codice che a volte può utilizzare SSL e talvolta non può utilizzarlo, può passare da SslStream a TcpStream senza modifiche al codice chiamante. Questo è qualcosa che è molto più difficile da realizzare usando solo l'API Socket.

Answer 2

Niente, davvero. È solo che a volte è più comodo usare un flusso.

Answer 3

Per me, l'operazione Socket.Receive riuscita con zero byte ricevuti indica che la connessione è chiusa.