title: How to check the capacity of a TCP send buffer to ensure data delivery
body: <p>I would like to add delivery confirmation to my TCP interface.  A non-blocking write could populate the send buffer, but the data might never arrive if the connection fails - meanwhile write has reported that the data was received (by the local socket).</p>
  
  <p>If I added extra acks to the stack, I could verify each piece of data was received.  I think ftp does this.  But I can't borrow anyone's code and would rather not implement ack/resend, particularly since TCP does most of this already.</p>
  
  <p>I think it can be accomplished if I can verify that the socket send buffer is empty after each write().  If there's no more data, it should have all been delivered.  I don't mind the latency of emptying the buffer.</p>
  
  <p>Edit: I realize TCP/socket implementations differ by system, but if there's a Berkeley or Linux solution, it's probably available to me.</p>
  
  <p>Edit: To address some suggestions, I would like to implement three levels of TCP interface, where I don't know how to accomplish the *'d one.</p>
  
  <ul>
  <li>Normal TCP with no assurance of delivery, for applications that like to live dangerously.</li>
  <li>*TCP that verifies receipt by a remote host, even if the packet was never delivered to the remote app.  This reduces most of my connection risk (mobile client) and can be implemented completely on the client side.  I think this can be implemented if I can verify the socket outgoing buffer is empty.</li>
  <li>Application layer ACK and resend implemented on top of TCP or UDP so the endpoints are verified.</li>
  </ul>