https://svn.boost.org/trac10/ticket/6698 <p> After making a synchronous socket call (send(), write() or close()) that returns success, if the calling thread exits quickly, on connections with ~500 ms latency, the operation doesn't actually take place. (With little latency the problem does not occur.) </p> <p> With the following code snippet, send() returns the correct size for the buffer and ec.value() remains 0. However, using wireshark at the remote, the data never arrives. </p> <pre class="wiki">boost::system::error_code ec; size_t nWritten = m_sock-&gt;send( &lt;some data&gt;, ec ); assert( nWritten == &lt;data size&gt; ); assert( !ec.value() ); m_sock-&gt;close( ec ); assert( !ec.value() ); m_io_service-&gt;stop(); m_thread-&gt;join(); </pre><p> This occurs both with linger on and off. I was able to verify this on several different systems running 32 and 64 bit windows 7. By putting an assert in socket_ops.ipp immediately after its call to WSASend() I was able to verify that it returned success and WSAGetLastError() returned 0. </p> <p> If I add a brief ::Sleep(100) call immediately after the socket calls fixes the problem and the data is transmitted and received at the other end. </p> <p> My thought is that this is a Windows error - when a socket is created using WSASocket() with WSA_FLAG_OVERLAPPED set (as asio does), a call to WSASend() with the overlapped arguments set to 0 isn't truly performed synchronously. </p> <p> I couldn't find this bug previously reported anywhere, if it is I apologize. </p> <p> Thanks Hugh </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/6698 Trac 1.4.3 chris_kohlhoff Tue, 29 May 2012 00:29:57 GMT https://svn.boost.org/trac10/ticket/6698#comment:1 https://svn.boost.org/trac10/ticket/6698#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">invalid</span> </li> </ul> <p> On some versions of Windows, closing the socket while there is still buffered data may result in data loss. Try using a strategy for graceful close, e.g. half closing the socket (using shutdown) and then waiting for the peer to close once it has received all the data (which means a subsequent receive call in your program will fail with asio::error::eof). </p> Ticket