Re: Process imap not running

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 16 Jan 2008 23:50:44 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Tue, Jan 15 2008, Ted Zlatanov wrote:
>> On Tue, 15 Jan 2008 00:27:48 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 
>> 
RS> On Mon, Jan 14 2008, Simon Josefsson wrote:
>> 
>>>> It adds some unnecessary round-trips, but I guess we can live with
>>>> those.  Maybe there could be a variable to turn them off, but we can
>>>> always add that later if people want it.
>> 
RS> I added the variable `imap-ping-server', defaulting to t.  Please
RS> adjust if necessary.
>> 
>> I think it should be an integer, representing the minimum number of
>> seconds before it's triggered (or nil to turn it off).

RS> Is this feasible?  Would someone like to implement this?

I could do it eventually, but it's really not too hard.  Just make a
buffer-local timer in the imap buffer and check it every time if the
variable is not t.

>> The default should be nil.  When the IMAP server is far away, pinging
>> the server introduces a painful delay because of the TCP round trip.

RS> Could you explain how much delay it cause (and when)?  As it seems to
RS> fix a problem for several users, it would be nice to set it to t.

Remote TCP connections require an acknowledgment for every packet.  This
is alleviated by some optimizations to TCP itself (for example, you're
allowed to send more packets before you get an acknowledgment to the
first one), but it's a session-based reliable protocol so eventually you
have to wait for a confirmation back to know your packet made it.  If I
understand it correctly, the connection to the IMAP server is
synchronous, so any new commands in the queue will have to wait for the
ping to complete (since we don't start sending new IMAP commands until
the current one completes).  Thus a server 80ms away will introduce a
80ms delay twice per ping.  When you're on a slow link, or the network
is congested/miconfigured, or the server is far away, the delay will be
noticeable.

Of course, if the ping can happen in the background, that would not
block.  But we'd need parallel IMAP sessions or support for multiple
queued commands in one IMAP session, and imap.el doesn't support either
AFAIK.

Ted