Channel timeout related issue

[shivank1111]

Boost Version: 354

When opening two WebSocket channels, for example, ws:/../channel1/ and ws:/../channel2/, I have made changes to enable communication between the two channels.

I have set the timeout to 30 seconds using the following code:

beast::websocket::stream_base::timeout opt{
    std::chrono::seconds(30),
    std::chrono::seconds(30),
    false
};
ws_.set_option(opt);

However, the issue is that say both channels are opened at the same time. If, after 15 seconds, communication occurs between the two channels (e.g., from channel1 to channel2), the timeout for channel1 will restart and close the connection after 45 seconds(15+30 =45;from beginning). But for channel2, even though it is receiving messages, its timeout does not reset and will close exactly after 30 seconds, which I don't want.

One possible solution is to keep the alive_pings set to true so the channel remains open, but I prefer not to use this approach, as it could increase the server load.
Could you suggest another solution to handle this?

Additionally, I have another question: If we implement a ping-pong mechanism, where the server receives a ping and responds with a pong to the client, would this reset the timeout? And how can I test this?

[ashtum]

One possible solution is to keep the alive_pings set to true so the channel remains open, but I prefer not to use this approach, as it could increase the server load. Could you suggest another solution to handle this?

Currently, only pong responses reset the timeout timer, so setting alive_pings to true is the only available option. There’s an open PR for this issue (#2718), but I haven’t merged it yet because the unit tests rely on a few timers, which makes them unreliable. I’ll work on resolving this and aim to merge it for the next Boost 1.88 release.

[shivank1111]

My understanding with regard to pong responses is that if the client side sends a ping and we send a pong then the channel will remain open even if we set the alive_pings as false?

[ashtum]

My understanding with regard to pong responses is that if the client side sends a ping and we send a pong then the channel will remain open even if we set the alive_pings as false?

The internal inactivity timer is updated whenever the stream receives a message or a pong in response to a previously sent ping. keep_alive_pings controls whether the stream sends a ping message (when half of inactivity time is elapsed). It does not affect when the stream should be closed.

[shivank1111]

Hi @ashtum , could you please confirm when the ping response feature, which is planned to be added in the Boost 1.88 release, will be available?

[ashtum]

when the ping response feature, which is planned to be added in the Boost 1.88 release, will be available?

Boost 1.88 will be released in April: https://www.boost.io/calendar/
I'll try to fix the test problems in that PR and include it in the release.