[Dovecot] v2.0.alpha1 released

[Ed W]

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