views:

951

answers:

2

I receive the follow exception:

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)

The follow link show that this is a known problem for microsoft. http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=273186

This stacktrace show 2 things:

  1. The System.IO.BufferedStream do some absurd pointer move operation. A BufferedStream should buffer the underlying stream and not more. The quality of buffer will be bad if there are such seek operation.
  2. It will never work stable with a stream that not support Seek.

Are there any alternatives? Does I need a buffer together with a NetworkStream in C# or is this already buffered.

Edit: I want simply reduce the number of read/write calls to the underlying socket stream.

+1  A: 

A BufferedStream simply acts to reduce the number of read/write calls to the underlying stream (which may be IO/hardware bound). It cannot provide seek capability (and indeed, buffering and seeking are in many ways contrary to eachother).

Why do you need to seek? Perhaps copy the stream to something seekable first - a MemoryStream or a FileStream - then do your actual work from that second, seekable stream.

Do you have a specific purpose in mind? I may be able to suggest more appropriate options with more details...

In particular: note that NetworkStream is a curiosity - with most streams, read/write relate to the same physical stream; however, a NetworkStream actually represents two completely independent pipes; read and write are completely unrelated. Likewise, you can't seek in bytes that have already zipped past you... you can skip data, but that is better done by doing a few Read opdrations and discarding the data.

Marc Gravell
First you should do a look on the trace. I want reduce the number of read/write calls to the underlying stream. .NET is calling seek() and not I.
Horcrux7
You are right and I apologise. Very, very odd!
Marc Gravell
+2  A: 

The NetworkStream is already buffered. All data that is received is kept in a buffer waiting for you to read it. Calls to read will either be very fast, or will block waiting for data to be received from the other peer on the network, a BufferedStream will not help in either case.

If you are concerned about the blocking then you can look at switching the underlying socket to non-blocking mode.

pipTheGeek