Re: IMAP check options

[Brian Stafford <brian stafford uklinux net>]

On Sun, 12 August 13:07 Peter Bloomfield wrote:
> On 2001.08.12 04:20 M . Thielker wrote:
> > Hi,
> 
> [snip]
>  
> > Thanks for that patch, it does just what it's supposed to do. But the
> > need
> > for this patch poses another question: Why is STATUS sent twice, anyway?
> 
> I've never seen redundant STATUS requests going out--how are you detecting
> them?
> 
> > This nicely matches up with complaints from other users about slow IMAP
> > checks and downloads, there seems to be some redundant code here. 
> 
> Slow IMAP *opens* I believe are caused by Balsa scanning the tree from
> scratch--I'm pretty sure that Netscape Messsenger (my other reader) saves a
> lot of information about the tree, to avoid a full scan--I don't how far we
> want to go down that road. Slow checks we're getting on top of. Slow
> downloads I know nothing of.

On lock-step protocols like IMAP much of the slow data transfer problem
arises from clients and/or servers that do not implement PIPELINING and
have inadequate buffering for socket i/o.  Ideally clients and servers should
buffer up to around the TCP window size (about 4Kb) before flushing to
avoid round trip time at the TCP level.  PIPELINING avoids round trip time
at the protocol level.  libmutt appears not to implement socket buffering
or PIPELINING so I doubt if it can ever perform well.

It is interesting to note that I've had a few reports of subjectively
improved performance for mail submission using libESMTP compared to other
mechansims.  I figure I have at least anecdotal evidence that socket buffering
and PIPELINING really is worthwhile.

A final point - although I'm back to not seeing the contents of my IMAP
mailboxes again - when it was working I got *much* better performance
with the Cyrus IMAP server than with Exchange.  There might be an element
of unfairness in putting the entire blame for lack of performance on the
client.

Brian Stafford