Ya, that seems to be a valid case. Knox uses Jetty's Websocket implementation, I did a quick search to see whether we could add a keep-alive property but Jetty does not seem to support it [1]
I think the option that Johan pointed out Ping/Pong heartbeat protocol would be the best way to approach this and is the recommended substitute for keepalive [2] Best, Sandeep [1] https://dev.eclipse.org/mhonarc/lists/jetty-users/msg03573.html [2] https://tools.ietf.org/html/rfc6455#section-5.5.2 On Tue, Sep 12, 2017 at 1:07 AM, Johan Wärlander <[email protected]> wrote: > Well, the problem here seems to be more that some firewall in-between > decides the connection isn't doing anything useful, since there's no > traffic for a while, and thus drops it from its tracking tables. That's > certainly a case where TCP keep-alive can be helpful [1], and enabling it > on either the (Knox) server or the client end should avoid dropped > connections, unless there are more firewalls between Knox and the backend > service. > > Vin, if it's an option for you to enable this on the Knox server, do try > it out and see if you get any improvements. > > However, the websocket protocol does seem to support a "ping/pong" > functionality, which has the advantage of working across HTTP proxies etc > [2], and is probably the better long-term solution; of course, the backend > service must then be modified to make use of it, and send a ping with some > (hopefully configurable) interval. > > [1] http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html > [2] https://stackoverflow.com/questions/23238319/websockets- > ping-pong-why-not-tcp-keepalive > > mån 11 sep. 2017 kl 22:51 skrev Sandeep More <[email protected]>: > >> Should it ? to be honest I wasn't clear so I dug up some discussion on >> Jetty mailing list, they have interesting discussion about HTTP >> implementation of keep-alive [1], turns out they do not support this >> setting (over simplifying) but this is for http... >> >> Knox uses Jetty's implementation of Websockets, after successful >> handshake we create a new socket, it does not appear that it uses >> Keep-Alive setting at all. Instead it relies on the session close signal >> between the clients if either of them close the connection (or in case of >> failure) then connection is severed. IMO there is really no use of >> keep-alive here. >> >> Let me know what you think ! >> >> Best, >> Sandeep >> >> [1] http://dev.eclipse.org/mhonarc/lists/jetty-users/msg07976.html >> >> >> >> On Mon, Sep 11, 2017 at 4:11 PM, Johan Wärlander <[email protected]> >> wrote: >> >>> Hmm.. Shouldn't the websocket connections inherit the system wide >>> settings for keepalive, as long as the application doesn't specifically set >>> anything up? >>> >>> Regards, >>> Johan >>> >>> On mån 11 sep. 2017 21:55 Sandeep More <[email protected]> wrote: >>> >>>> Hello Vin, >>>> >>>> I am afraid we cannot configure TCP KeepAlive property for websockets. >>>> You could try to send a ping from the client to keep the connection active >>>> but I am guessing you have already tried that :) >>>> >>>> Best, >>>> Sandeep >>>> >>>> On Sat, Sep 9, 2017 at 3:40 AM, Vin J <[email protected]> wrote: >>>> >>>>> Hi Sandeep, >>>>> >>>>> The situation is like this: >>>>> >>>>> client <--> internet gateway/firewall <--> knox gateway <--> backend >>>>> service >>>>> >>>>> Setting websocket timeouts in knox doesn't help (it is already set to >>>>> a larger value) as it doesn't do anything to keep connection between >>>>> client >>>>> and knox gateway "active". If there is no client activity for a few mins, >>>>> the internet gateway/firewall in the middle times out the TCP connection. >>>>> So knox is not the one shutting down the connection here. >>>>> >>>>> One easy solution to prevent this is to turn on TCP keepalive on the >>>>> connection. That way the internet gateway/firewalls know the connection >>>>> is >>>>> active and should be kept alive. So I was looking to see if we could >>>>> potentially do that from the knox side. >>>>> >>>>> >>>>> On Fri, Sep 8, 2017 at 11:25 PM, Sandeep More <[email protected]> >>>>> wrote: >>>>> >>>>>> Hello Vin, >>>>>> >>>>>> If you specifically need to set the ability to control the timeouts >>>>>> for websocket Knox has couple of options >>>>>> >>>>>> 1. gateway..websocket.async.write.timeout - default value 60000 ms >>>>>> 2. gateway.websocket.idle.timeout - default value 300000 ms >>>>>> >>>>>> You can set these values in gateway-site.xml config. >>>>>> Let me know if that works. >>>>>> >>>>>> Best, >>>>>> Sandeep >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Sep 8, 2017 at 1:27 PM, Vin J <[email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Is there a way to control TCP/IP settings applied on connections >>>>>>> that Knox accepts? So Knox would ensure something like custom >>>>>>> socketOptions >>>>>>> <https://docs.oracle.com/javase/7/docs/api/java/nio/channels/SocketChannel.html#setOption(java.net.SocketOption,%20T)> >>>>>>> are applied by Jetty on an inbound connection. >>>>>>> >>>>>>> The specific need I have is to enable TCP keepAlive on WebSocket >>>>>>> connections that Knox is accepting for a backend service. We see >>>>>>> gateways/firewalls timing out TCP connections under these WebSockets if >>>>>>> they are idle for 2-3 mins unless there's TCP keepAlive probes flowing >>>>>>> during the idle period. And since there's usually a user interface on >>>>>>> the >>>>>>> other side of a WebSocket it is not unusual for it to be idle for a few >>>>>>> mins between user activity. Ability to enable TCP keepAlive on the Knox >>>>>>> side has the benefit of not requiring clients to manage the situation. >>>>>>> >>>>>>> Regards, >>>>>>> Vin. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>
