When performing an async_write with a tcp socket,

问题:

This is just a simple question of how async_write behaves with tcp sockets. Basically, when working with a tcp socket, does the write handler get called when the data gets written to the socket, or when an ack is received from the destination?

回答1:

AFAIK, the handler gets called as soon as data are written into the socket's kernel buffer.

回答2:

Same behavior as the BSD socket's send() - it completes when the OS has a copy of the data. This will be before an ACK.

回答3:

The only guarantee provided by Boost.Asio is that the handler will be called when the operation completes. In the case of async_write, the operation is considered complete when any of the following are true:

• The entire buffer sequence has been written to the stream.
• The operation has been canceled. For example. socket_.cancel().
• An error occurs. For example, the remote endpoint closes their socket.

Once the operation completes, the handler is posted for deferred invocation. However, it is unspecified as to exactly when and the order in which handlers will be invoked. Consider the scenario where an async_write operation has been initiated for 2 different sockets. Any of the following sequences are possible:

1. async_write operation 1 completes.
2. operation 1's handler invoked.
3. async_write operation 2 completes.
4. operation 2's handler invoked.

1. async_write operation 1 completes.
2. async_write operation 2 completes.
3. operation 1's handler invoked.
4. operation 2's handler invoked.

1. async_write operation 1 completes.
2. async_write operation 2 completes.
3. operation 2's handler invoked.
4. operation 1's handler invoked.

回答4:

I think you need high layer protocals. if a remote peer program blows your request package, ACK is also does not fit your need.