[SOLVED] Is bufferevent_flush not necessary for a socket-based bufferevent in libevent?

Is bufferevent_flush not necessary for a socket-based bufferevent in libevent?

Currently (as of Libevent 2.0.5-beta), bufferevent_flush() is only implemented for some bufferevent types. In particular, socket-based bufferevents don’t have it.

I tested the following code:

auto output = ::bufferevent_get_output(bev);
::evbuffer_add(output, "hello", 5);
// ::bufferevent_flush(bev, EV_WRITE, BEV_FLUSH);

Note that I commented out the last line ::bufferevent_flush(bev, EV_WRITE, BEV_FLUSH);, but the data was still sent immediately.

Is bufferevent_flush not necessary for a socket-based bufferevent in libevent? If so, how libevent decides when to send the pending data in evbuffer?

Solution

Presumably, libevent is relying on the buffering services of the underlying socket implementation.

For TCP/IP, this involves sending any buffered data either when the send buffer is full or a short while after no new data has been added (Nagle's algorithm), whichever happens first. Since this delay is typically only a few hundred milliseconds, you may not have noticed it.

There is a call to setsockopt to disable this delay (TCP_NODELAY) and it's possible that libevent is using that, in which case any data passed to send is transmitted immediately. You'd probably have to inspect the source to see if that's what they're actually doing (it would be unusual).