920074 - There're no keep-alives in WebSockets connections

Status: RESOLVED WORKSFORME

(Core :: Networking: WebSockets, defect)

Description

[wgh]

I have a WebSockets server that periodically sends updates to connected clients. Clients never send anything. Connection can be left idle for many hours.

Firefox sometimes "loses" the connection without noticing it. No error or close event is fired. Server detects that connection is down some time after it tries to send something. If I try to send something _to_ the server in that time window (i.e. between sending data and timing out), connection will recover (I guess NAT restores masquerading table entry after seeing this miracolous ressurection of connection that's supposed to be dead).

Chromium never loses the connection in the same circumstances (both browsers were tested on the same machine).

Wireshark showed me that Chromium uses TCP keep-alives, while Firefox doesn't. Neither browser uses protocol level ping-pong frames.  

It's not really Firefox fault. I blame **** home router that probably silently drops idle TCP connections without trying to at least reset them. (/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established = 420, do those people even know what RFC is? I suppose they don't)

Anyway, using keep-alives is cheap and pretty reliable method to work-around faulty NATs for the time being. Keep-alives will also benefit server-sent events.

Comment 1

[Patrick McManus [:mcmanus]]

your application can generate websocket layer pings if it likes and firefox will pong in response. That won't have any visibility at the JS layer but it will keep the middlebox happy.

Comment 2

[wgh]

Of course it can. But if Firefox could just issue keep-alives itself it would spare developers of headaches. Even though I explained the problem in just a few lines, it took quite a long time to pinpoint it.

Comment 3

[Patrick McManus [:mcmanus]]

(In reply to wgh from comment #2)
> Of course it can. But if Firefox could just issue keep-alives itself it
> would spare developers of headaches. Even though I explained the problem in
> just a few lines, it took quite a long time to pinpoint it.

we're kind of on the fence about it to tell the truth.

the problem is that it can waste tremendous amounts of bandwidth and (sometimes worse) battery. Its common that >90% of bandwidth in applications with keep-alives is consumed by the keep-alives!

at least websockets has a mechanism for this (as does spdy). http/1 based things like server-events are kind of up a creek.

Comment 4

[Patrick McManus [:mcmanus]]

the tcp keep-alive bug tracker is bug 444328.. like I said, we're on the fence but I would merge something fairly conservative. At least to get some testing with. Would you be interested in working on it?

Comment 5

[u408661]

FWIW, I do have a patch in progress for but 444328, but my work on that is blocked on me finishing up bug 881804 first.

Comment 6

[wgh]

(In reply to Patrick McManus [:mcmanus] from comment #3)
> the problem is that it can waste tremendous amounts of bandwidth and
> (sometimes worse) battery. Its common that >90% of bandwidth in applications
> with keep-alives is consumed by the keep-alives!
Client-side keep-alives will be more efficient than server-side ones in theory. User can configure keep-alive timeout with NAT and batteries in mind (though I have yet to see a home router manual with instructions how to configure timeouts). Server obviously can't have this knowledge. 

(In reply to Patrick McManus [:mcmanus] from comment #4)
> the tcp keep-alive bug tracker is bug 444328.. like I said, we're on the
Looks like this bug is duplicate after all. I'm pretty sure I searched for "keep-alive". Damn hyphen. 

> fence but I would merge something fairly conservative. At least to get some
> testing with. Would you be interested in working on it?
Unfortunately, I have no experience of Firefox hacking.

Comment 7

[Patrick McManus [:mcmanus]]

we've added tcp KA since this was filed

Comment 8

[wanghb89]

(In reply to Patrick McManus [:mcmanus] PTO until Sep 6 from comment #7)
> we've added tcp KA since this was filed
Does firefox send ping to the server?