Question: Handling Websocket terminations

[paulbhart]

I am hoping this is a simple question(s), but takes a bit of explaining to arrive at the question.

We are looking at deploying a application built using this framework and deployed into our kubernetes environment running on top of GKE. I work on the team that builds/manages the k8s / networking environments, not the ones building the actual chat application. I did some work with a simple (hello world type) python chat room built using websockets and this is where we have discovered some potential challenges.

1. The Global Load Balances we use have a timeout that is basically a max session length (thus the ping_interval and ping_timout will not keep the session open past the timeout). Google also makes it clear that you can't assume that you will always reach the timeout before the connection could be terminated, due to say software upgrades or other uncontrollables.
2. We are also hearing from akamai (our traffic into our glb is from akamai) that you can't assume websockets will always work (upgrading the connection might fail or/and a http / websocket termination timeout like with google), thus you that you need to be able to fall back to using long lived http sessions. https://techdocs.akamai.com/property-mgr/docs/websockets-support#limitations. This is a recent discovery.

I did try to dig through the issues and documentation, but didn't find anything definitive, but hoping my assumptions are going to be true. As I type this our application team is working to get the application up and running so we can test things out, but hoping to get some guidance or basic answers from this community to ensure we aren't heading down a dead end path.

So the questions really get down to can we build a chat application using websockets and this framework to;

1. handle a websocket termination (i.e. something caused by network issues or a "session" timeout) so in most cases the session can be reestablished without visual impact to the customer
2. and also give us the ability to manage a customer that is no longer active (i.e. prompt them they need to continue to be active and eventually disconnect them from chat room)

Thanks for any pointers or help as we seek to design and architect our chat system.

-Paul

[benbrown]

The websocket functionality of Botkit is pretty simple.

The built in sample client does do reconnects if it loses the connection. Both the client and the server applications get events when the connections go up/down, so you can add custom handling.

There is nothing built into botkit to enable proactive prompting for inactivity. This would be something your developers would have to add by inspecting the internals of the websocket server for active connections.