Mohammad Nejati

I couldn't find any indication in [RFC 6455](https://datatracker.ietf.org/doc/html/rfc6455) that either permits or prohibits the counting of control frames as a form of activity. Considering that this approach could potentially eliminate...

@xim It would be great if you could add the relevant test cases to the PR; This is the appropriate location for including them: https://github.com/boostorg/beast/blob/develop/test/beast/websocket/ping.cpp.

It seems this how is how timeout cases are tested in the entire code base (searching for `stream_base::timeout` or `test::run_for`). Please ensure that you allocate a sufficient margin to prevent...

The issue is associated with creating a work_guard from a `strand`. It attempts to utilize `on_work_started()` and `on_work_finished()` functions, which are not defined for `asio::any_io_executor`. This results in a compile...

> I'm not 100% sure but passing `strand.get_inner_executor()` to `make_work_guard` could solve the issue ? This will generate a work guard for `any_io_executor` instead of `strand`. Calling [get_executor](https://www.boost.org/doc/libs/1_84_0/doc/html/boost_asio/reference/executor_work_guard/get_executor.html) on this...

I've raised an issue in Asio for this; let's see what will be the response. https://github.com/chriskohlhoff/asio/issues/1394

Yeah, Chris usually doesn't respond to the issues, but he reads them. We should track the changes in the repository to see if it gets fixed or not.

No, unfortunately, this issue, along with many others, hasn't been addressed in the Asio for 1.85.0 release.

Thanks for reporting this. The root cause of the issue is creating a `work_guard` from a `strand` because Asio chose the wrong specialization. Yes, if we wrap that strand in...

Could you please provide your sample code? > I have also replaced the file of "message_generator.hpp" in all the available places. `advanced_server.cpp` is already using `message_generator` what did you replace...