rstudio / httpuv

HTTP and WebSocket server package for R
Other
229 stars 86 forks source link

Expose a way to send websocket Ping frames #291

Closed atheriel closed 8 months ago

atheriel commented 3 years ago

I have some Shiny applications where I can't totally control the intermediate proxies, and as a result the websocket connections are closed after a few minutes of inactivity. It's obviously possible to circumvent this by having some reactive trigger every once in a while, but I was looking for a more general solution.

I've read that forced-closing of idle connections can be ameliorated by having the server send Ping frames at regular intervals as a keepalive mechanism, and several popular websocket servers do this by default every 20s or so:

From a cursory look around the source, it seems that all of the machinery to send Ping frames is already in place, but there's currently no way to actually do so. I'm wondering if it makes sense to expose a way to do this, or even better, to turn it on by default.

I'm also curious if this came up long ago but had some sort of drawback I don't know about. It looks like all browsers have supported Ping frames since at least 2015, but maybe that was once a reason not to send them.

Edit: I realize that existing proxies (like Shiny Server) can send Ping frames already, I'm interested in doing this from the server itself instead (or in addition to).

tom-puckett commented 2 years ago

+1 for this request. If a Shiny application can initialize itself to optionally send a periodic websocket ping frame (either from the client or server) it would help a lot. Socket timeout is an increasing problem for applications sitting in the cloud where every inactive connection is killed after 90 seconds, and proxy applications also kill idle connections.

Has anyone read this issue? https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers search for Pings and Pongs

jcheng5 commented 2 years ago

Good request, I think we've just been blind to this because Shiny Server does this by default. I'm a bit tied up at the moment but I'll add this to my list of things to look at.

atheriel commented 2 years ago

I remain interested in this problem and can potentially find time to look at it in the future, too.

HugoGit39 commented 8 months ago

@jcheng5 already some news about this? Currently i try to keep my dockerized Shiny app alive...tried it on Digital Ocean, Heroke, Azure with various heartbeat methods.....unfortunately they all failed:

https://github.com/rstudio/shiny/issues/2110

jcheng5 commented 8 months ago

@HugoGit39 I implemented this last year in v1.6.10, just forgot to close this issue… is it not working for you? https://github.com/rstudio/httpuv/pull/359

HugoGit39 commented 8 months ago

hmmm ok...than I am confused why my Shiny app turns grey either on DO, Heroku or Azure...also cause when I even add a heartbeat method like:

keep_alive <- shiny::reactiveTimer(intervalMs = 10000, session = shiny::getDefaultReactiveDomain())
shiny::observe({keep_alive()})

https://tickets.dominodatalab.com/hc/en-us/articles/14794822159124-Shiny-App-shows-a-gray-screen-after-sometime-or-timeouts

and I see every 10 sec an idle/busy message flow in chrome, it disconnects

jcheng5 commented 8 months ago

Then it’s for sure not this problem. I want to help you get to the bottom of this but I’ll close this particular issue now, we can discuss in the shiny issue tracker.