Socket ReceiveTimeout on Linux - linux

Question

I am writing a synchronous client. Part of it is a Connection object which is responsible for the actual sending and receiving of the data. The entire library is written using the Boost ASIO ip::tcp::socket class.
I have a test in which the client calls a method on the server (which sleeps for 2 seconds) with a timeout of 1 second. My code has detected that execution took more than the requested time, but it didn't return in time. Instead, it returned after the 2 whole seconds.
I have narrowed down the problem to the receive method:
void Connection::receive(const mutable_buffers_1& buffers, const DurationType& timeout)
{
// to make sure it isn't 0 by mistake
auto actualTimeout = std::max(DurationType(milliseconds(1)), timeout);
SocketReceiveTimeoutOption timeoutOption(actualTimeout);
error_code ec;
_socket.set_option(timeoutOption, ec);
RPC_LOG(TRACE) << "Setting timeout " << actualTimeout << " returned: " << ec.message();
RPC_LOG(TRACE) << "Receiving...";
if (_socket.receive(buffers, MSG_WAITALL, ec) != buffer_size(buffers))
{
throw RpcCommunicationError("Did not receive the expected number of bytes from connection");
}
RPC_LOG(TRACE) << "Received! With error code: " << ec.message();
}
DurationType is just a convenience typedef:
typedef boost::chrono::system_clock ClockType;
typedef ClockType::time_point::duration DurationType;
SocketReceiveTimeoutOption is an option implemented for sockets:
template <int Name>
class SocketTimeoutOption
{
public:
#ifdef BSII_WINDOWS
SocketTimeoutOption(const DurationType& timeout) : _value(static_cast<DWORD>(boost::chrono::duration_cast<boost::chrono::milliseconds>(timeout).count())) {}
#else
SocketTimeoutOption(const DurationType& timeout) : _value(Utils::toTimeval(timeout)) {}
#endif
// Get the level of the socket option.
template <typename Protocol>
int level(const Protocol&) const
{
return SOL_SOCKET;
}
// Get the name of the socket option.
template <typename Protocol>
int name(const Protocol&) const
{
return Name;
}
// Get the address of the timeout data.
template <typename Protocol>
void* data(const Protocol&)
{
return &_value;
}
// Get the address of the timeout data.
template <typename Protocol>
const void* data(const Protocol&) const
{
return &_value;
}
// Get the size of the boolean data.
template <typename Protocol>
std::size_t size(const Protocol&) const
{
return sizeof(_value);
}
private:
#ifdef BSII_WINDOWS
DWORD _value;
#else
timeval _value;
#endif
};
typedef SocketTimeoutOption<SO_RCVTIMEO> SocketReceiveTimeoutOption;
typedef SocketTimeoutOption<SO_SNDTIMEO> SocketSendTimeoutOption;
And finally
namespace Utils
{
inline
timeval toTimeval(const DurationType& duration)
{
timeval val;
auto seconds = boost::chrono::duration_cast<boost::chrono::seconds>(duration); // TODO: make sure this is truncated down in case there's fractional seconds
val.tv_sec = static_cast<long>(seconds.count());
auto micro = boost::chrono::duration_cast<boost::chrono::microseconds>(duration - seconds);
val.tv_usec = static_cast<long>(micro.count());
return val;
}
}
The problem is that even though I specify a 1s timeout, the receive method still takes the entire 2 seconds. Here's the log:
2014-09-14 10:27:53.348383 | trace | 0x007f24e50ae7c0 | Setting timeout 999917107 nanoseconds returned: Success
2014-09-14 10:27:53.348422 | trace | 0x007f24e50ae7c0 | Receiving...
2014-09-14 10:27:55.349152 | trace | 0x007f24e50ae7c0 | Received! With error code: Success
As you can see, setting the timeout worked, but still the receive method took 2 seconds.
The same code works just fine on Windows.

Answer 1

socket::receive() will block until either:
One or more bytes of data has been received successfully
An error occurs that would prevent data from being received
For blocking synchronous operations, if the underlying OS operation returns with a non-critical error, such as one indicating that the operation would block or should be tried again, then Boost.Asio will block in poll() waiting for the file descriptor to become ready. The blocking call to poll() is not affected by the SO_RCVTIMEO socket option. Once the file descriptor is ready, Boost.Asio will reattempt the operation.
Thus, the scenario in the original question occurs as follows:
Time | Client | Server
-----+----------------------------------------+-------------------------------
| socket.connect(...); | acceptor.accept(...);
0.00 | socket.set_option(timeout(second(1))); | sleep(seconds(2));
0.01 | socket.receive(...); |
0.02 | |-- recv(...); |
1.02 | | // timeout, errno = EAGAIN |
1.03 | |-- poll(socket); |
2.00 | | // data available, poll unblocks | socket.write(...);
2.01 | `-- recv(...);// success |
To get the desired timeout behavior, either:
Use the pattern presented in the official Boost.Asio timeout examples.
Invoke the OS call directly. However, be cautious, as other operations may indirectly affect this approach. For example, if an asynchronous operation is initiated on the socket, then the socket will be set to non-blocking. This will cause the recv() function to return immediately on a non-blocking socket regardless of the SO_RCVTIMEO socket option.