Socket.EndSend vs. NetworkStream.EndWrite

  • Thread starter Thread starter Marc Sherman
  • Start date Start date
M

Marc Sherman

Hi,

According to the docs, Socket.EndSend may indicate a partial write whereas
NetworkStream.EndWrite returns only after *all* the data specified has been
written. In the face of heavy I/O, does this mean that
NetworkStream.EndWrite will fail if the system buffers are too full to
accomodate all the data?

IOW, are there any disadvantages to using NetworkStream for writing?

thanks,
Marc
 
According to the docs, Socket.EndSend may indicate a partial write
whereas
NetworkStream.EndWrite returns only after *all* the data specified has
been
written. In the face of heavy I/O, does this mean that
NetworkStream.EndWrite will fail if the system buffers are too full to
accomodate all the data?

IOW, are there any disadvantages to using NetworkStream for writing?
Click to expand...

I'll make a guess. :)

I don't know for sure that there are no disadvantages, but I doubt there
would be. System buffers should only affect how much data can be buffered
from the user process at a given time. Since your user buffer must not be
reused until you've received notification of the completion of the
BeginWrite() operation, .NET can rely on the data still being buffered
even if there's some congestion in the system.

I in particular am appreciative of the question, since until you asked it,
I hadn't noticed that NetworkStream.BeginWrite() operation will not
complete until all of the bytes are sent. I'd always just assumed it was
the same as the regular Socket.BeginSend() behavior.

Because of the difference, I suppose there's one theoretical disadvantage
to use NetworkStream.BeginWrite(): you get no feedback regarding the
progress of the buffering with respect to the system. Using
Socket.BeginSend(), you'd get a callback each time some of your data was
buffered by the system. But really, I don't see what the practical use
for this would be, and it imposes the additional requirement that you
resubmit unsent data if only a partial send succeeds. IMHO, simpler code
is better, so avoiding that requirement could be considered a good thing.
:)

Pete
 
Peter Duniho said:
I'll make a guess. :)

I don't know for sure that there are no disadvantages, but I doubt there
would be. System buffers should only affect how much data can be buffered
from the user process at a given time. Since your user buffer must not be
reused until you've received notification of the completion of the
BeginWrite() operation, .NET can rely on the data still being buffered
even if there's some congestion in the system.

I in particular am appreciative of the question, since until you asked it,
I hadn't noticed that NetworkStream.BeginWrite() operation will not
complete until all of the bytes are sent. I'd always just assumed it was
the same as the regular Socket.BeginSend() behavior.

Because of the difference, I suppose there's one theoretical disadvantage
to use NetworkStream.BeginWrite(): you get no feedback regarding the
progress of the buffering with respect to the system. Using
Socket.BeginSend(), you'd get a callback each time some of your data was
buffered by the system. But really, I don't see what the practical use
for this would be, and it imposes the additional requirement that you
resubmit unsent data if only a partial send succeeds. IMHO, simpler code
is better, so avoiding that requirement could be considered a good thing.
:)
Click to expand...

Pete, thanks for the quick reply. From what you've written, I'll stick with
NetworkStream.

Marc
 
Back
Top