89 lines
4.7 KiB
Plaintext
89 lines
4.7 KiB
Plaintext
MBOX-Line: From asuth at mozilla.com Wed Sep 4 14:33:20 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Andrew Sutherland <asuth@mozilla.com>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] Best way to support HTTP PUT based 'push'
|
|
notifications from IMAP?
|
|
In-Reply-To: <a519769d-6db9-4422-a557-1c9c0fdce9ad@flaska.net>
|
|
References: <5225BF8C.7060602@mozilla.com>
|
|
<a519769d-6db9-4422-a557-1c9c0fdce9ad@flaska.net>
|
|
Message-ID: <5227A720.6060001@mozilla.com>
|
|
|
|
On 09/04/2013 03:43 PM, Jan Kundr?t wrote:
|
|
> On Tuesday, 3 September 2013 12:53:00 CEST, Andrew Sutherland wrote:
|
|
>> On devices that either have difficulty maintaining persistent TCP
|
|
>> connections or have power concerns about doing so, maintaining an
|
|
>> IMAP connection for IDLE/NOTIFY purposes is undesirable and it would
|
|
>> be great if the IMAP server could generate a notification via other
|
|
>> means.
|
|
>
|
|
> I have heard this a couple of times, but there was never a pointer to
|
|
> an article quantifying these claims. I understand that something
|
|
> different than TCP (e.g. an incoming SMS) could have a very different
|
|
> impact on power consumption simply because it utilizes a different
|
|
> part of the radio, but this proposal is about replacing one TCP
|
|
> connection with another one. So, why do you expect that this change
|
|
> will reduce power consumption, and do you have any measurements or
|
|
> other data?
|
|
|
|
So there are 2 separate issues here.
|
|
|
|
1) Maintaining the connection.
|
|
|
|
1a) Wi-fi connections. Firefox OS shuts down the wi-fi when we turn off
|
|
the screen if we are on battery power unless some application has a
|
|
wi-fi wake-lock. It's my understanding that wi-fi is somewhat power
|
|
hungry, but either way, wi-fi off is going to take less power than wi-fi
|
|
on, no matter what. So all connections established via wi-fi will die.
|
|
We could re-establish them via cellular data, of course.
|
|
|
|
1b) Cellular data connections. I think this is a theory-versus-practice
|
|
thing, at least in the markets that Firefox OS devices have been
|
|
targeting. In theory, it should be possible for the device to roam
|
|
around without losing its TCP connection if the tower infrastructure
|
|
maintains the IP/NAT mapping and routes the packets to the right tower.
|
|
What I am told and my own limited experience bears out in the markets
|
|
that I have been to is that the connections end up dropping/hanging. As
|
|
you say, any TCP-based push notification would be subject to these same
|
|
problems.
|
|
|
|
|
|
2) Power levels. A presentation I saw quite some time ago made by
|
|
Telefonica Digital, but whose slides I am unable to find characterized
|
|
the cellular radio power usage as similar to a CPU and its varying sleep
|
|
levels. An idle TCP connection would actually let us get down to the
|
|
second lowest power level. Not the best, but not the end of the world.
|
|
As Timo says, using/maintaining one TCP connection is better than
|
|
maintaining N TCP connections. Also important issue is that keeping a
|
|
TCP connection alive means keeping the application that owns it alive
|
|
too and that is not without its costs. Our initial Firefox OS devices
|
|
have 256 MiB of memory, with about half of that available for
|
|
applications, so there's not a lot of spare capacity for one app to be
|
|
hanging around, and definitely not multiple apps.
|
|
|
|
In terms of replacing TCP with TCP, my understanding is that we actually
|
|
have 3 implementation approaches on the table for communication with the
|
|
push notification server. The most preferred implementation is
|
|
SMS-based or something similar using the control channel of the cellular
|
|
network which is both reliable and allows for the cellular radio to go
|
|
to its lowest power level. I believe this requires carrier
|
|
participation and so is not available for all devices. The next best
|
|
solution is UDP-based; the device still needs to maintain an IP address
|
|
but there is less overhead or risk of the connection hanging in a weird
|
|
way. I believe heartbeats/pings are used for the UDP approach to ensure
|
|
that we haven't lost touch with the server. The last approach is based
|
|
on polling. The push implementation wakes up and then talks to the
|
|
server to see if there's a new event. That might be what the UDP
|
|
solution degrades to when the heartbeats aren't getting through.
|
|
|
|
And of course having a single native C++ thread waking up to perform the
|
|
polling is generally better for resource usage than having N
|
|
uncoordinated HTML/JS-based apps either waking up or using alarms to go
|
|
through their entire startup process to perform their own polling. I
|
|
believe we are looking at supporting some type of coordinated polling
|
|
process for apps that do have to poll for resource usage reasons so we
|
|
take maximum advantage of having the CPU/radio/wi-fi all cranked up.
|
|
|
|
Andrew
|
|
|