Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve ping for server-only usage #2652

Closed
johannesparty opened this issue Mar 15, 2023 · 6 comments
Closed

improve ping for server-only usage #2652

johannesparty opened this issue Mar 15, 2023 · 6 comments

Comments

@johannesparty
Copy link

johannesparty commented Mar 15, 2023

Version of Beast

All versions

Description of the problem

The current ping implementation lets you set a "inactivity timeout" which is triggered when no data is received in a set amount of time. You can also set a "send ping" flag, which will send a ping after 1/2 the timeout has occurred.

It is common that only the "server" side of a connection sends ping as Browser WebSockets typically don't have this ability. Unfortunately, the current implementation doesn't adequately handle this case. Here is an example:

Server = beast, with timeout and ping turned on.
Client = browser, can't send ping

Client sends message to server more often than the inactivity timeout.
Server doesn't send any pings as a result

Problem: Client never gets any messages or pings, so when the client receives no pings or messages in a long time, it assumes the connections is closed due to inactivity.

Proposal

When "send ping" is turned on, send the ping if you haven't received anything within 1/2 timeout OR you haven't sent anything within the 1/2 timeout. I sample code for ping on nodejs do it this way.

If you don't want to add the additional pings (which should be harmless), then a new separate flag could be added to enable this behavior.

@klemens-morgenstern
Copy link
Collaborator

I don't follow. You're supposed to set the send_ping on the server side and nothing on the client side. Where's the problem?

@johannesparty
Copy link
Author

I want the client side to know when data is no longer getting through. Typically this is done with the client side doing a timeout (no data received in ). This just requires the server to send a ping if it hasn't sent any data in /2. "Any data" could mean a regular message or a ping message.

The client side never sends a ping, it really just passively expects server ping (or other traffic) within timeout.

This should only involve pretty minor changes to existing code; currently ping is sent if enabled and nothing received in last /2. Make it so ping is sent if enabled and nothing received OR SENT in last /2. I don't think the API needs to change, but I would be ok if this behavior requires a separate setting.

Here is a typical sample from javascript world (kind of relevant; these are WEBsocket after all). https://github.com/websockets/ws#how-to-detect-and-close-broken-connections
In particular, see the "You might want to add a ping listener..." section.

Note their code sends pings every 30s regardless of other traffic and relies on ping exclusively to determine timeout. We can optimize by viewing any received traffic resetting the timeout.

Thanks!

@klemens-morgenstern
Copy link
Collaborator

You can do that now by just calling async_ping to manually check. (NOTE: I should write an example for that).

What do you want to happen if there's no activity?

@johannesparty
Copy link
Author

Yes, I could handle all the timeout stuff myself, but the current implementation of set_option's timeout does 80% of what I need, so IMO beast should either send a ping every 1/2 timeout if no other data has been sent and ping is turned on (at least as an option). I wouldn't ask for this if I thought this was an unusual usage of ping or if I thought this was a requirement other users won't share.

@klemens-morgenstern
Copy link
Collaborator

Fair point. Is there a convention or standard for this, or is this your customsolution?

@ashtum
Copy link
Collaborator

ashtum commented Jan 1, 2024

Duplicate of #2716

@ashtum ashtum marked this as a duplicate of #2716 Jan 1, 2024
@ashtum ashtum closed this as not planned Won't fix, can't repro, duplicate, stale Jan 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants