Thanks Mark.
When I look at the server logs for Thunderbird or Outlook, I never see more that one IMAP logon at a time. That also goes for all the users on our production server, although they are nearly all either Outlook or Thunderbird, with maybe an occasional Eudora thrown in for good measure. In my own case, on one account, I have maybe 30 or more mail folders, on another maybe 6 or 7. Yet I never see these IMAP clients logging on more than once simultaneously. Now, they don't use c-client as far as I can tell. Does this mean they are operating in a different way ? Something roughly equivalent to 1 connection, multiple mailstreams?
There are many clients that open several concurrent connections. Mozilla/Thunderbird allows limiting number of concurrent IMAP connections (Server Settings/Advanced) and often uses just one by chosing to SELECT mailboxes frequently and doing extensive client-side caching. I guess the reason for this kind of model was that mozilla was designed to work efficiently in offline imap mode which obviously is not able to take advantage of many concurrent connections anyway. As Mark wrote, it's a tradoff. If you have relatively short-lived connections or your server's has some database-based backend with very fast SELECT operation, opening one/very few connections may be a good idea. If you need to interactively watch several mailboxes for modifications, keeping separate connections open may be better. (BTW, some imap servers allegedly limit number of concurrent connections for the same user).
For the moment, I expect to use
just an inbox and a sent folder, so I only have two mailboxes to monitor/operate, and that may not even be simultaneously. But of course I'm just getting started. I 'd rather not be obliged to re-design my system later, so I need to at least consider the implications. If this becomes an issue, is it possible/useful/interesting to separate the connection from the mailstream?
IIRC, each c-client mailstream opens a separate connection.
Pawel
Or is uw-
imap effective in this environment? (BTW, I have no intention of changing my mail server under any circumstances) unless forced to, and that would be kicking and screaming.
Mark Crispin wrote:
On Sat, 16 Apr 2005, Mike Schmidt wrote:
Now I have an additional quick question, more a design question than anything else: if I understand correctly, I should have 1 mailstream open to an imap server, not one per mailbox. I should reuse this mailstream when switching mailboxes instead of making a new one, is that correct? What happens to the message cache in this case?
It's a bit more complicated than that.
You should have one MAILSTREAM open for each mailbox which you want to be open *simultaneously*.
If you want to "switch" from one open mailbox to another, it is better to reuse the mailstream than to close the existing mailstream and open a new mailstream on the new name.
With any of these operations, there are certain costs:
Opening a new connection has the cost of TCP/IP session initiation, encryption negotiation, and authentication negotiation.
Selecting a mailbox has the cost of server overhead to load/process the mailbox, and the protocol overload of loading the client cache.
Closing a mailstream has the cost of discarding the message cache for the old name and closing the TCP/IP session.
Opening a new mailstream has both the "opening a new connection" and the "selecting a mailbox" cost.
Recycling a mailstream has the cost of discarding the message cache for the old name and "selecting a mailbox", but avoids the costs of closing the TCP/IP session and "opening a new connection".
Keeping multiple sessions open allows you to monitor multiple mailboxes simultaneously, but there is a practical limit of how many mailboxes that you should have open at a time, no more than a handful. You want to do this if you want immediate real-time access to the mailbox and its messages, as opposed to passive monitoring.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
