+1 to everything Patrick said.
Note that our TCP keepalive strategy on B2G at the moment is (in the
absence of other network activity) to ping every 10 seconds for the 1st
minute a connection is alive, and then we drop off sharply to pinging every
10 minutes. Keepalive pings are disabled for long-lived XHRs (and IIRC
websockets too? Steve, do you remember?) and also IIRC HTTP/2 (since Http/2
has it's own ping).
There's an inherent latency/power-use tradeoff here. I've long wondered
what the right tradeoff is for B2G (I've leaned towards stopping keepalive
pings after the 1st minute, to save battery). If someone has thoughts here
I'm interested to hear them. Perhaps it'll be moot if we teach apps to
close connections that have been idle.
Jason
On Tue, Feb 3, 2015 at 7:26 AM, Patrick McManus <
mcm...@ducksong.com>
wrote:
> cc: steve who did the firefox work around this.
>
> one of the issues you will run into is OS portability - you might very well
> standardize something that's isn't portably implementable on standard
> kernels.
>
> Using sessions on the order of 2 or 3 minutes with a tiny bit of keep-alive
> seems to work pretty well, and closing them after that point. That's the
> HTTP/2 strategy right now. We've looked at the distribution of timeouts in
> the past - there is a notable spike around 60 seconds, but it still only
> made up a small fraction of the total distribution.
>
> If you have some kind of nop like application layer method (such as smtp
> nop :)) you can pipeline that just before your real operation and put a
> timer on that response, creating a new session if it fails. This doesn't
> add any latency due to the pipeline when everything is fine. That's a bit
> better than open ended K-A in my opinion, particularly if you really hold
> that connection open for a long duration. but some protocols (HTTP/1 e.g.)
> aren't well suited to that.
>
> There are of course severe tradeoffs in terms of battery and network
> overhead in using tcp keep-alives. Most KA transmissions are going to be
> full radio wakeups. I would think that those trades would be especially
> painful for Firefox OS. Legacy protocols using that api might be better off
> just taking the performance hit of establishing new connections.
>
>
> On Tue, Feb 3, 2015 at 9:15 AM, Andrew Sutherland <
somb...@gmail.com>
> wrote:
>
--
Jason