[Dovecot] Dovecot IDLE bandwidth usage
Hi list,
I just recently discovered the IMAP IDLE command and tried it out with my Dovecot server. It seems to work fine and all, but it seems to be using quite a deal of bandwidth, because of the "* OK Still here" messages sent by the server at two minute intervals. I would argue that is a bit of a problem when using the IDLE command for "Push mail" on a mobile phone.
I don't know exactly what parts of the packets that mobile carriers collect payment for, but the Ethernet bandwidth consumed by one such message is 149 bytes (83 bytes for the message itself, and 66 bytes for the TCP ACK from the client). At two minute intervals, that becomes over 100 KB per day, and over 3 MB per month. At GRPS rates typical here in Sweden, that becomes about 5-7 USD per month.
That might not seem tremendously much, but seeing how it is what takes up the vast majority of the IMAP bandwidth, it is still quite annoying.
Are those messages really necessary? I mean, Dovecot still times out after half an hour if the client doesn't "finish" the IDLE command and re-issues it, right? (Coincidentally, I would like to argue that it would be better not to time out at all during an IDLE command and just turn on TCP keepalives instead, but that is the minor issue here)
I'll apologize in advance if this is already a tunable option, but I haven't found anything about it in the configuration file.
Cheers, Fredrik Tolf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 16 Aug 2007, Fredrik Tolf wrote:
using quite a deal of bandwidth, because of the "* OK Still here"
They are very essential for the COPY command, when I tested large mailboxes last. So I suggest to _not_ remove them lightheadedly. The problem was that after 15min (or so) the MUA decided that the server stopped responding and broke the connection.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBRsP1zS9SORjhbDpvAQKwIQgAqYEBi/SzuMyJExO7HNpEVhdmGjejJeaP fG8cqeIwkfvyYpCxFjAh1Yp8bE38CnrW0cT1Wg+AL/Sopyh9nDTmHhQaoSwgWHI3 cHbkUL6hOQA4vTO5nYCdrwmDVVQSMdaVVHh1meEaGzAC9N9MjagQ7uF42Tz+4+CH ID95VjDLGNY/gqDMkVMnUvhmJX9AQTdoEwxw58rRlXiMZqo7xbT67FMWkGpNxWjq 3qE3ORlb5lIpOMu+BChbT4kCBNIqPI4BA9edVy/UtJT/mzptw3AvnVT9yDY5setQ mkONypRbA+KmYkfcBK/fsaiCxR0igUladCI5y+cgAgVnCnCa6qSwqA== =9Asc -----END PGP SIGNATURE-----
On Thu, 2007-08-16 at 02:22 +0200, Fredrik Tolf wrote:
The point is mostly to keep connections alive when NATs and stateful firewalls are used.
I've actually changed it like that for v1.1. I'm not sure if I should change it for v1.0.
and just turn on TCP keepalives instead, but that is the minor issue here)
TCP keepalives get sent so rarely that they don't keep NATed connections alive. (Linux's tcp(7) says the first one is sent after 2h of idling)
I'll apologize in advance if this is already a tunable option, but I haven't found anything about it in the configuration file.
Perhaps there should be.. But since this is client connection-specific and not server-specific issue I'm not sure if that's a good idea either. Wonder if this could be figured out automatically in some way..
Timo Sirainen wrote:
TCP keepalives get sent so rarely that they don't keep NATed connections alive. (Linux's tcp(7) says the first one is sent after 2h of idling)
Its the same for windows systems, 2 hours.
All routers SHOULD keep the NAT connections open for at least that long. But its not always the case, a few years ago I had to get a FIX for an Alcatel Speedtouch Pro since its was originally programed to drop TCP connections after 15 minutes.
Gerald
Gerald Villemure wrote:
You may find that some GPRS implementations drop idle connections after as little as 2 mins also...
You need to test your own GPRS implementation, but they certainly drop idle connections after a period (probably 2 mins is unusually short though)
Ed W
participants (5)
-
Ed W
-
Fredrik Tolf
-
Gerald Villemure
-
Steffen Kaiser
-
Timo Sirainen