TcpClient.GetStream().Read()与TcpClient.Client.Receive() [英] TcpClient.GetStream().Read() vs. TcpClient.Client.Receive()

查看:58
本文介绍了TcpClient.GetStream().Read()与TcpClient.Client.Receive()的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

.NET允许两种非常相似的方式从网络读取"(假设使用TCP连接):

.NET allows two very similar ways to "read" from the network (assuming TCP connection):

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

通过查看NetworkStream源代码-似乎它是对基础套接字的额外包装,最终调用了Socket方法.

By looking at NetworkStream source code - it seems that it's an extra wrapper over the underlying socket, which eventually calls Socket methods.

问题:使用间接" NetworkStream变体(#1)代替使用Socket实现提供的直接包装有什么好处?

Question: what's the benefit of using "indirect" NetworkStream variation (#1), instead of using direct wrapper provided by Socket implementation?

谢谢你,鲍里斯.

推荐答案

实际上,使用第一个选项(TcpStream而不是Socket)具有明显的好处.好处是,当同一程序需要不同的基础实现时,流API更加灵活.

There is, in fact, a pretty clear benefit of using the first option (TcpStream and not Socket). The benefit is that stream API is more flexible when different underlying implementations are needed at for the same program.

例如,有时可能使用SSL而有时可能不使用SSL的代码可以在SslStream和TcpStream之间切换,而无需更改调用代码.仅使用普通的Socket API很难做到这一点.

For example, a code which sometimes may use SSL and sometimes may not use it, can switch between SslStream and TcpStream with no changes to the calling code. This is something which is much harder to accomplish using only plain Socket API.

这篇关于TcpClient.GetStream().Read()与TcpClient.Client.Receive()的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆