tcp_keepalive=yes has an effect on the underlying TCP connection. However,
simply keeping the TCP connection alive will not stop the client or server
WebSocket implementation explicitly closing the connection if no WebSocket
frames are received.
If you are using WebSockets, and you are unsure as to the behaviour of the
WebSocket client (some clients will send pings themselves and some won't -
it's an implementation choice) the WebSocket server should send pings on
idle connections that need to be kept open. If you want to make sure the
underlying TCP connection doesn't go on you then you need to set the TCP
connection parameters accordingly (the way I do it is to set the TCP
connection timeout to a few seconds more than the WebSocket ping interval)
- and do so for all LAN equipment in the path.
A good example is that if you are using Amazon Elastic Load-Balancer to
distribute WebSocket connections, idle connections will be timed-out (by
the Load-Balancer) after 60 seconds - so make sure the server sends
WebSocket pings more frequently than that.
Regards,
Peter
On 26 September 2013 14:21, Juha Heinanen <jh(a)tutpro.com> wrote:
Peter Dunkley writes:
There is no TCP level stuff here, this is all at
the WebSocket layer.
Take
a look at the "keepalive_.*" modparams
for the websocket module.
are you saying that websocket transport is not implemented on top of
tcp?
if it is then tcp_keepalive=yes core param affects also websocket
transport.
-- juha
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd