[Dovecot] v2.0.alpha1 released
Ed W
lists at wildgooses.com
Wed Oct 14 02:14:58 EEST 2009
Timo Sirainen wrote:
>
>> I can imagine that in the case of a typical cell phone with say 3
>> email accounts, there will be likely three idle connections (or more)
>> to dovecot and each will end up sending keepalive packets at slightly
>> different intervals for each connection. By synchronising this
>> network traffic you would potentially increase battery life by up to
>> a factor of 3 (ie turn on the radio to send the keepalive for all
>> connections in one go, rather than turning the radio on three times
>> as often)... (I think perhaps that's optimistic, but you can see that
>> quite large gains might be possible here)
>
> Oh. That does sound like a good idea. Hmm. I think there's an easy way
> to implement this:
>
> next_still_here_sending_timestamp = imap_idle_notify_interval -
> (time(NULL) + crc32(username)) % imap_idle_notify_interval;
>
> The username CRC32 is there to avoid network/load spikes when all the
> processes try to send the "Still here" at the same time.
Just to kick this around a bit - I guess it's possible for one username
to be logged in on three different computers (eg I have several laptops
with identical config and sometimes several of them are on at once). On
the other hand my original idea was to compromise on "hashing" by IP
address, this is obviously wrong in the sense that frequently multiple
users are behind large NAT ranges, especially if they are on some sort
of WAN connection
I don't think either situation is actually a "problem" because it would
appear that the only "failure" mode is to send too few keepalives,
sending a few too many now is unlikely to be a drain given we then send
fewer subsequently.
However, I guess for maximum polish it would be optimal to hash based on
both username and ip address? This would appear to be useful in your
algorithm above anyway though?
Thanks for listening!
Ed W
More information about the dovecot
mailing list