c# - C#中是否可以替代System.IO.BufferedStream？

我收到以下异常：

System.NotSupportedException : This stream does not support seek operations.
   at System.Net.Sockets.NetworkStream.Seek(Int64 offset, SeekOrigin origin)
   at System.IO.BufferedStream.FlushRead()
   at System.IO.BufferedStream.WriteByte(Byte value)

以下链接显示这是Microsoft的已知问题。
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=273186

此stacktrace显示2件事：


System.IO.BufferedStream做一些荒谬的指针移动操作。 BufferedStream应该缓冲基础流，而不是更多。如果有这样的查找操作，缓冲区的质量将很差。
对于不支持Seek的流，它将永远无法稳定工作。


还有其他选择吗？
我是否需要一个缓冲区以及C＃中的NetworkStream还是已经被缓冲区了。

编辑：我只想减少对底层套接字流的读/写调用次数。

最佳答案

解决方案是使用两个独立的BufferedStream，一个用于接收，另一个用于发送。并且不要忘记适当地刷新发送的BufferedStream。



由于即使在2018年，对于这个问题似乎也很难获得令人满意的答案，为了人道，这是我的两分钱：

NetworkStream在OS端被缓冲。但是，这并不意味着没有理由在.net端进行缓冲。 TCP在Write-Read（repeat）上表现良好，但是由于延迟的ack等原因在Write-Write-Read上停顿了。

如果像我一样，如果有一堆低于标准的协议代码可以进入二十一世纪，那么您就想缓冲一下。

或者，如果您坚持上述操作，则还可以仅缓冲读取/ rcvs或仅缓冲写入/发送，并直接将NetworkStream用于另一侧，具体取决于代码的破损程度。您只需要保持一致！

BufferedStream文档无法明确说明的是，仅在流是可搜索的时才应切换读写。这是因为它在同一缓冲区中缓冲读取和写入操作。 BufferedStream根本不适用于NetworkStream。

正如Marc指出的，造成这种la行的原因是将两个流合并到一个NetworkStream中，这不是.net的最大设计决策之一。

关于c# - C#中是否可以替代System.IO.BufferedStream？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/551471/