We have a use case where we want to automatically terminate the connections from Pushpin after a specified time interval. Is there a way to specify this interval, could not find any configuration value for this.
Thoughts on any other way to handle this, if this is not configurable on the Pushpin side?
There isn’t a configuration option for this, but it might be achievable with either Grip-Link (for http) or Keep-Alive-Interval (for websockets). Why do you need this, and which transport are you using?
BTW if you are just wanting to clear away stale connections, you could use grip keep alives to send periodic packets to force connections to clear out, or crank up TCP keep alives.
We are currently using the keep-alive provided by Pushpin, which does clear away stale connections.
In our case, the session duration of a client is limited to Xmins. After which we disconnect from the client side. But we don’t want this control to be with the client completely as they can then have long-running connections.
So, we need a way for the server to initiate disconnect after Xmins if the client is still active.
Makes sense. In that case you could use either Grip-Link or Keep-Alive-Interval to cause Pushpin to periodically make requests to the backend, even in the absence of any client activity, and use that as an opportunity for the backend to close out the connection if the client should no longer have access to it for any reason. Think of it like a periodic re-auth.
For example, with WebSockets (using WebSocket-over-HTTP), you could respond with the header Keep-Alive-Interval: 120, to instruct Pushpin to make a request to the backend at least every 2 minutes. Whenever the backend receives a request, it can check if the user’s session has timed out and close the connection by responding with a CLOSE event.
You can do a similar thing with HTTP, by responding with Grip-Link: </somepath>; rel=next; timeout=120. Then whenever the backend receives a request and should close the connection it can omit Grip-Hold.
Note that Pushpin might make requests sooner than the timeout and reset its timer, for example in response to client activity or published messages, so you can’t simply set the timeout to the session duration limit and assume any subsequent request means the limit was reached. Instead you’ll want to use a shorter timeout and have the backend check the limit.