beast
beast copied to clipboard
Disconnect on Server Side
I am using version 1.76 as a client.
Ok, this is a hard one.
I am trying to work with an existing web socket (zellowork.io). But, I cannot stay connected to them. I put wireshark on the connection and I can clearly see that it is their side that is providing the disconnect [FIN, ACK]. Their product was designed so the web socket is always open and you send data when you need to. But I am finding that after some time they disconnect it can be as short as 10min and sometimes 6.5hrs.
Normally I would say the issue is on their side but they say they have had this product running for a few years and they have no problems with their Android, IOS apps on the mobile side; and no issues using JavaScript, Go or Qt on the desktop side.
I tried sending data every 5 minutes as a sort of keep alive, but it did not help. When it disconnects it does not appear to be a response to anything that I have sent them. Because it can disconnect well after my last data transfer.
I can see on wireshark the underlying websocket keep alives every 30 seconds.
That is really all the data I have. Are there any parameters that I should change to maybe resolve this issue. Right now I have timeouts set the Default::Client. Anything I should tell zello to look for?
Thanks,
timeout::suggested(client) will instruct your client to not initiate pings. However it will respond to them:
static
timeout
suggested(role_type role) noexcept
{
timeout opt{};
switch(role)
{
case role_type::client:
opt.handshake_timeout = std::chrono::seconds(30);
opt.idle_timeout = none();
opt.keep_alive_pings = false;
break;
However, if you want the client to initiate keepalive pings and disconnect if not answered, the easiest way to do this is to use timeout::suggested(server):
case role_type::server:
opt.handshake_timeout = std::chrono::seconds(30);
opt.idle_timeout = std::chrono::seconds(300);
opt.keep_alive_pings = true;
break;
So you might try setting the option before initiating your handshake, like this:
ws.set_option(
beast::websocket::stream_base::timeout::suggested(
beast::role_type::client));
where in this case ws is your instance of beast::websocket::stream
The ping-pong message pump is driven by your calls to async_read, so there is no need to take any further action beyond reading messages as you normally do.
Other than that I'm not sure what to suggest. If you are willing to post a test program that demonstrates the issue I'm happy to take a look my end. (please make it short - one self-contained cpp file)
Hi @treyweaver, were you able to make progress or still stuck?
Richard,
I am still suck, but that is because I have been home sick. I finally managed to make some changes to the code today and I am testing the results. Should know by tomorrow if the changes I made helped.
Trey
On Fri, Jun 25, 2021, at 3:49 AM, Richard Hodges wrote:
Hi @treyweaver https://github.com/treyweaver, were you able to make progress or still stuck?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/boostorg/beast/issues/2265#issuecomment-868297022, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJBASOY4FIBSDS4YAP5LPDTUQYG7ANCNFSM47CAC4LA.
This issue has been open for a while with no activity, has it been resolved?
@treyweaver did you make any progress?