MBOX-Line: From dave at cridland.net  Mon Oct  4 13:11:28 2010
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] Fwd: iOS IMAP IDLE (Standard "Push Email")
	Deficiency, Explanation?
In-Reply-To: <7D32DBF6-2ECC-4854-85A8-84261D828ED2@sabahattin-gucukoglu.com>
References: <352410DE-19D8-4EE4-8741-AB82741D7A18@sabahattin-gucukoglu.com>
	<4CAA0F5C.7030009@lists.grepular.com>
	<alpine.OSX.2.00.1010041034520.392@hsinghsing.panda.com>
	<7D32DBF6-2ECC-4854-85A8-84261D828ED2@sabahattin-gucukoglu.com>
Message-ID: <11166.1286223088.054596@puncture>

On Mon Oct  4 19:32:53 2010, Sabahattin Gucukoglu wrote:
> On 4 Oct 2010, at 18:56, Mark Crispin wrote:
> > The real problem with IDLE is that it is NAT-unfriendly.  Most  
> NAT boxes
> > drop the mapping after a period of client inactivity, and send a  
> TCP RST
> > to the server if the server resumes activity before the client.   
> Most
> > users don't see this, since if the client resumes activity first  
> the same
> > mapping is created and no RST is sent.
> 
> Yes, indeed, this argument is the most convincing I've actually  
> seen against IDLE, and the compromise is to set a time interval  
> that gets around the NAT's braindead behaviour.  Since most clients  
> are happy to allow users to specify a polling frequency that  
> determines the maximum time between checks, it's not a stretch to  
> turn this into a between DONE-IDLE timer.  The solution is IPv6, of  
> course.

Mobile operators are catching up in this respect. I'm told than 5-10  
minutes is fine for keepalives, now. In fact, the pressure from  
"real" mobile developers on application protocol developers has been  
in reducing keepalives, and placing them under the control of clients  
(so they can be synchronized to reduce power requirements).

As more push protocols are developed - and with WebSockets on the  
horizon, that's a given - then it's likely that users will discover  
that applications give them longer battery life on networks with a  
longer NAT timeout, and this may turn into a marketable feature.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

