beast: websocket::read_some blocks after received a Pong message

Hello, websocket::read_some blocks after reading a Pong message (control message) and waiting for the next frame.

What I’am doing: I am using several client websockets. Before I do a read operation on a websocket I am using select to make sure that a read on a socket won’t block. I want to manage my control message like Ping and Pong on my own because the protocol I am using requires specific payload.

1. I’m sending a Ping to the server,
2. call select on the fd (there will be data because of the pong message from server)
3. call read_some, my callback is called and afterwards read_some is blocked because it waits for the next frame after the Pong.

Pseudo code

 ws = std::unique_ptr<websocket::stream<tcp::socket>>(new websocket::stream<tcp::socket>(*ioc));
 ws->control_callback([this](const websocket::frame_type kind, const beast::string_view payload) {}
ws->handshake(host, "/"); // connect
ws->ping(websocket::ping_data(payload)); // send ping
select(ws->next_layer().native_handle()) // to the select, there will be data, the pong
ws->read_some(flatBuffer, buffer.getRemainingBytes()); // will call callback and blocks afterwards and waiting for more data

In my opinion it’s not a good idea to handle the control messages like ping/pong within the read_some method. It would be better to return like we are reading a normal frame and let the user decide what to do. There is already a method is_message_done() (fin bit). Why not introduce methods like is_message_ping() or is_message_pong() so that the user can check the type of the frame?

I did a small workaround in my git repo: https://github.com/eliot-exdev/boost-beast.git branch ping_pong_fix.

If a ping/pong is received the callback will be called and afterwards return with 0 (nothing read). So the read_some won’t block anymore a I have the needed payload and the information about ping/pong in my callback.

To sum it up: think about if you really want to handle the ping/pong in a read request. If there is a any special payload needed for these messages the user cannot provide it at the moment. Perhaps the underlying protcol needs to consider special timings, … It would be much better to return the payload to the user and give him a hint what the type of frame was received (fin bit, ping bit, pong bit, close might be a special case).