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