Did you ever have this happen to you? You think you understand a piece of technology really well because it is so fundamental. But then someone comes and exposes how much you misunderstood something.

This happened to me today in a question regarding BSD sockets.

The debate was this - when a 'send()' call returns success, what does it *mean*? Does it mean

• That the application on the other end of the socket has got it
  
• That the network stack on the other end has got it (and may not have passed it on to the application below it)
  
• That the data has left your machine. It may be in the cloud somewhere or on the target machine.
  
• That the data has been successfully copied into your computer's network stack (into a buffer somewhere)

I'm willing to bet that a lot of you are confused now (or I hope so atleast for the sake of my ego). What did 'send()' actually succeed at?

The correct answer is the last one - that the message was successfully copied into some buffer into kernel space. In fact, one of the ways in which send() can fail is if the buffer doesn't have enough space to squeeze in your data.

You can see this specifically mentioned at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/send_2.asp

Why was I confused? Probably because my mental image of 'send()' has always been 'the network transmission call that blocks' and I associated blocking with the slow act of sending data over the network.

In case anyone is wondering, this debate didn't arise due to BSD sockets. We have an internal library that is supposed to 'mimic' BSD sockets semantics and I was sure I had found a bug when I found the 'send()' call succeeding before the other side had got the data.

You learn something new everyday. What's next? A bug in my hello world programs?