title: Is acknowledgment response necessary when using send()/recv() of Winsock?
body: <p>Using Winsock, C++, I send and receive the data with <strong>send()/recv()</strong>, TCP connection. I want to be sure that the data has been delivered to the other party, and wonder if it is recommended to send back some acknowledgment message after (if) receiving data with <strong>recv</strong>.</p>
  
  <p>Here are two possibilities, and please advice which way to go:</p>
  
  <ol>
  <li><p>If <strong>send</strong> returns the size of passed buffer, assume that the data has been delivered at least to <strong>recv</strong> function on the other side of wire. When I say "at least", I mean even if the <strong>recv</strong> fails there (e.g. due to insufficient buffer, etc.), I don't care, I just want to be sure I've done my server part of work properly - I've sent the data completely (i.e. the data reached the other machine).</p></li>
  <li><p>Use additional acknowledgment: after receiving the data with <strong>recv</strong>, send back some ID of received packet (part of header of each data sent) signaling the successful receive operation of that packet. If I don't receive such "acknowledgment message" after some interval, return failure code from the sender function.</p></li>
  </ol>
  
  <p>The second answer looks more safe, but I don't want to complicate the transfer protocol if it is redundant. Also please note that I'm talking about the TCP connection (which is more safe by itself than UDP).</p>
  
  <p>Is there any other mechanisms (maybe some other APIs? maybe <strong>WSARecv()/WSASend()</strong> work differently?) of ensuring that the data was delivered to the <strong>recv</strong> function on the other side?</p>
  
  <p>If you recommend the second way, could you please give me some code snippet that allows me to use <strong>recv</strong> with timeout to receive the acknowledgment? <strong>recv</strong> is a blocking operation so it will hang forever if the previous send attempt failed (the other party was not notified). Is there any simple way of using <strong>recv</strong> with timeout (without creating separate thread every time which would probably be the overkill for each and every <strong>send</strong> operation).</p>
  
  <p>Also the amount of data I pass to <strong>send</strong> function might be quite big (several megabytes), so how to choose the timeout for "acknowledgment message"? Maybe I should "split" large buffers and use several <strong>send</strong> calls? I think it will get quite complicated, please advice!</p>
  
  <p><em>EDIT: OK, you people are suggesting that TCP/IP stack will handle it (i.e. no manual acknowledgment required), but this is what I found on MSDN page: "The successful completion of a <strong>send</strong> function does not indicate that the data was successfully delivered and received to the recipient. This function only indicates the data was successfully sent." So even if the TCP mechanism has the ability to ensure data delivery, I can't get that status (success or not) via <strong>send()</strong> function, or any other Winsock function I know. Do you know any way of getting the status from the TCP layer? Again - return value of <strong>send()</strong> function seems to be not enough!</em></p>
  
  <p>========================================================</p>
  
  <p><em>EDIT 2: OK, I think we agree that even though TCP protocol considers the error handling when something goes wrong, the <strong>send()</strong> function of Winsock is not capable of reporting the errors (simply because it returns before actual transmitting of data starts by the network driver). So here is a million dollar question: Does the <strong>send()</strong> function of Winsock at least ensure that no other packets will be delivered to the other party until the current packet will be? In other words, if the sending fails for some network failure (but not reported by <strong>send()</strong> call), and then the network failure will be fixed before next call of <strong>send()</strong> function with next chunk of data, will it be ensured that the previous packet (which failed but not reported by <strong>send()</strong>) will be delivered before the next packet? In other words, is there a chance that the one particular send() function will fail "silently", so that subsequent send() calls will succeed but the first packet will be lost? AGAIN - I'm not talking at the TCP level, I'm talking at the Winsock API level!</em></p>