On 2012-06-05 23:43, Timo Sirainen wrote:
On 5.6.2012, at 23.33, Michescu Andrei wrote:
I agree, in practice this is not an issue compared to the unavailability of the service, but on longer IMAP sessions (e.g. transferring a big file) the connection loss is noticeable.
It is noticeable for somebody that really waits for a large email.
And there is actually some (any!) way this could be avoided?... One server dies, another continues sending the mail?
Yes, there is. You have to replicate the entire state of the IMAP session (protocol states, buffers, TLS state etc.) and the TCP state of the connection. The state of the IMAP session is (in theory) easily replicable (although you probably have to rely on internals of the TLS implementation; OpenSSL can serialise TLS sessions from/into ASN.1 via i2d_SSL_SESSION, though this is meant to resume session via TLS) and for TCP there is RTCP [1]. RTCP intercepts the TCP session is able to recover the TCP state. It works without any modification of the operating system (at the moment limited to Linux).
If this would be implemented in Dovecot it would really set it apart from other IMAP servers and software that I've seen so far. Being able to transparently handle failover of a TCP connection is unique.
I have had some thoughts about transferring idling Dovecot connections between processes / servers so that clients wouldn't notice it, but I haven't even thought about moving active (long-running) connections.
Load rebalancing would probably be another feature that separates Dovecot from other IMAP servers.
Regards, Matthias-Christian