10

Will NetworkStream.Write block only until it places the data to be sent into the TCP send buffer, or will it block until the data is actually ACK'd by the receiving host?

Note: The socket is configured for blocking I/O.

Edit: Whoops, there's no such thing as TcpClient.Write of course! We all understood we were talking about TcpClient.GetStream().Write, which is actually NetworkStream.Write!

David Pfeffer
  • 38,869
  • 30
  • 127
  • 202

3 Answers3

7

Unless .net is using something other than winsock, then according to the winsock reference:

The successful completion of a send function does not indicate that the data was successfully delivered and received to the recipient. This function only indicates the data was successfully sent.

If no buffer space is available within the transport system to hold the data to be transmitted, send will block unless the socket has been placed in nonblocking mode. On nonblocking stream oriented sockets, the number of bytes written can be between 1 and the requested length, depending on buffer availability on both the client and server computers.

Assuming that write is calling send underneath, then a strict interpretation of the winsock documentation would indicate that there is no gurantee that the data made it to the other end of the pipe when it returns.

Here is the link to the winsock docs I am quoting from: http://msdn.microsoft.com/en-us/library/windows/desktop/ms741416(v=VS.85).aspx

Community
  • 1
  • 1
user957902
  • 3,010
  • 14
  • 18
  • +1 for showing a reference. I have yet to find any other documentation on this topic, so I'm assuming what you're quoting from is probably correct. – David Pfeffer Oct 05 '11 at 20:48
  • 1
    +1 Good job on the refernce (it was surprisingly hard to find docos on something that I just took for granted) – tcarvin Oct 05 '11 at 20:51
  • (And yes, .NET is using the OS sockets which are Winsock on Windows.) – David Pfeffer Oct 05 '11 at 20:53
  • @user957902 so this means In windows, we never know if the data was received successfully in remote peer? I made some testing, even if I unplug the cable, the data still can be `Write(bytes)` without any exception(I've been waiting there for another 20minutes). – Shawn Feb 09 '15 at 07:49
  • @Shawn That is correct. That is why there are communication protocols that send back acknowledgment of data sent so that you know the data got there at the application level. At least with a TCP socket stream you know that the underling protocol stack enforces that data must arrive in the order it was sent. – user957902 Feb 11 '15 at 13:22
  • @user957902 so I'm confused why choose TCP compare to UDP, we always need add some application level ACK mechanism for both. – Shawn Feb 12 '15 at 01:21
  • @Shawn UDP does not guarantee that the data you send arrives in the order that it was sent, or if the data gets to the other end at all. Its a kind of a "send and pray" protocol. So not only do you have to be concerned about the data getting to the other end, but ordering correctly once it arrives and detecting if any pieces are missing. The TCP protocol takes care of all that for you. – user957902 Feb 12 '15 at 13:18
1

I disagree with both answers [that state it blocks]. Writing to TCP/IP socket does not block unless the underlying buffer is already full of unacknowledge data. Generally, it doesn't block but just gets handed off to the TCP implementation. But of course now I have to go track down some references to back this up :)

From SO

Community
  • 1
  • 1
tcarvin
  • 10,715
  • 3
  • 31
  • 52
  • I seem to be seeing your answer to be correct on Mono, whereas the other answers seem to be correct on Windows. I'm extremely confused. Hopefully you'll find references, because I can't find anything conclusive. – David Pfeffer Oct 05 '11 at 20:46
-1

TcpClient.Write will block until the packet buffer has been flushed to the network and the appropriate ACK(s) have been received. You'll notice that a dropped connection will usually end up throwing an exception on the Write operation, since it waits for the ACK but doesn't get one within the defined timeout period.

Polynomial
  • 27,674
  • 12
  • 80
  • 107