On Wed, Apr 21, 2010 at 11:05:45AM +0100, Laurie Young wrote: > The websocket has to be kept open when there is no data-transfer for some > time. So that the connection is still open the server attempts to send data, > even if there has been a period of inactivity. This does expose us to dirty > connections, but is required for the functionality we need from websockets, > and we we have no choice but to accept this - or find a different solution.
I'm perfectly aware of this requirement, I understand it. > Normal HTTP connections on the other hand can be re-established by the > client when it wants to pull some more data from the server, so we can close > it after a period of inactivity. Meaning we can set a lower timeout to kill > off dirty connections. What I'd like to be clear is that a dirty connection from a given client to your unique frontend might as well be for the websockets or the http part. There's no difference. You don't decide about the probability of a client to get disconnected depending on the URL it asks. Also, in case of random network outage, you'll get a *lot* more dirty websocket connections than HTTP connections because the former last longer while the later are short-lived (a few tens of milliseconds to a few seconds at most). So trying to optimise your config to correctly handle 0.1% of your dirty connections while 99.9% of them will be on websockets makes no sense. > Unfortunately I am still no closer to knowing if HAProxy can do this :-( No, you can't change the client-side timeout on the backend. However, the server timeout still applies in case of inactivity. Regards, Willy
