TcpClient.GetStream (). Read () против TcpClient.Client.Receive ()

Question

.NET позволяет два очень похожих способа «чтения» из сети (при условии TCP-соединения):

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

Глядя на исходный код NetworkStream - кажется, что это дополнительная оболочка над базовым сокетом, которая в конечном итоге вызывает методы Socket.

Вопрос: в чем преимущество использования «косвенного» варианта NetworkStream (# 1) вместо использования прямой оболочки, предоставляемой реализацией Socket?

Спасибо, Борис.

Answer 1

На самом деле есть довольно очевидное преимущество использования первого параметра (TcpStream, а не Socket). Преимущество заключается в том, что потоковый API более гибок, когда для одной и той же программы требуются разные базовые реализации.

Например, код, который иногда может использовать SSL, а иногда может не использовать его, может переключаться между SslStream и TcpStream без изменений в вызывающем коде. Это гораздо труднее сделать, используя только простой Socket API.

Answer 2

Ничего, правда. Просто иногда удобнее использовать Stream.

Answer 3

Для меня успешная операция Socket.Receive с полученными нулевыми байтами говорит вам, что соединение закрыто.