MBOX-Line: From mrc+imap at panda.com  Mon Oct  4 14:20:05 2010
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] Fwd: iOS IMAP IDLE (Standard "Push Email")
	Deficiency, Explanation?
In-Reply-To: <11166.1286226226.318772@puncture>
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>
	<11166.1286223088.054596@puncture>
	<alpine.OSX.2.00.1010041338040.392@hsinghsing.panda.com>
	<11166.1286226226.318772@puncture>
Message-ID: <alpine.OSX.2.00.1010041405460.392@hsinghsing.panda.com>

On Mon, 4 Oct 2010, Dave Cridland wrote:
> Yes, except that the near constant DCH-level, plus the additional
> cost of actually transmitting over that, could quite easily cost more
> than the 500mA USB will feed it. :-)

Hmm.  When I tether, the phone actually seems to charge albeit rather more
slowly than being idle.  On the other hand, I tether with EV-DO much more
than with UMTS, so maybe there is a different there?

> FWIW, I've had no
> problem with IDLE and no keepalive on all sorts of networks, but I'll
> be humble and bow to your experience if you insist that must be down
> to my excellent client progamming skills.

It's basically the Client That Shall Not Be Named that you must look out
for, crappy Linksys NAT boxes, and users who complain that the "server
isn't updating my email" and can't be bothered to click on that little
broken connection icon to reestablish it.  The latter tend to be admin
types who like to order that something be "fixed" to their liking
regardless of the consequences.

The crappy Linksys boxes were guilty for dropping the NAT mapping if the
session was idle too much.  This was ameliorated by having the server send
an untagged OK every 2 minutes.

The Client That Shall Not Be Named was guilty of a lot more.  First, it
used IDLE even though it had no particular reason to do so.  Second, it
was smart enough to notice that the connection got dropped, and update the
icon, but somehow it never occurred to its developers to reestablish the
connection automatically.  Last, and not least, it would not issue the
DONE after 29 minutes as described in the IDLE RFC, so even if the session
was still alive it would die in the 30th minute.

That last problem required a truly horrible and utterly disgusting kludge.
At the 28th minute, a fake untagged EXISTS would be sent announcing new
mail.  The Client That Shall Not Be Named would issue a DONE.  Then, at
once, the server would issue an untagged EXPUNGE for that fake message,
and The Client That Shall Not Be Named never noticed that nothing changed
in the UID regime as a result of that message being "added" then
"expunged"!

Nor, for that matter, did any other client.  The users of The Client That
Shall Not Be Named stopped complaining, so I called it good.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

