Hi there, 

It looks like for each write, Evolution just waits IO_TIMEOUT to decide
whether or not it succeeded. IO_TIMEOUT is (60*4) (camel-file-utils.c)
or specific per kind of CamelTcpStream (usually similar values seem to
be used).

Any transfer that takes more than four minutes seems to be treated as a
timeout. Or, that is the behaviour that we observed. Over slow bandwidth
connections like GPRS, that doesn't make a lot of sense. I don't think
an arbitrary amount of seconds is never a good estimate if you send
entire messages with this timeout:

  Let's take for example IMAP's APPEND.

  Evolution's default IMAP code's "do_append" sends the entire ba->data
  for the entire ba->len to the IMAP continuation, which results in one
  single camel_stream_write, which results in one single camel_write
  which results in one single write() of ba->len. This ba->len is the
  entire size of the entire E-mail (all its MIME parts, including its
  large attachments). 

  That write() is non-blocking and a select() guards over this arbitrary
  IO_TIMEOUT to decide whether or not the (large) write timed-out.

Or, I misunderstood something about the camel_write() function ;-)
(which is not unlikely, I frequently misunderstand code).

Anyway ... with this patch we write in chunks of maximum 64 bytes with a
timeout of 15 seconds per chunk. We decided that 64 bytes doesn't add
too much latency, that 64 bytes is more than the usual IMAP command's
size (so no splitting up in chunks occurs for typical IMAP commands) and
that if 64 bytes didn't succeed in 15 seconds ... something is wrong
anyway (even over GPRS, although it's not impossible that it's really
just that slow).

But I'm not sure ... whether this is the right thing to do.


So I'm adding Camel experts in CC, in the hopes that they will de or
un-obfuscate camel_write() for me ;-). Just waiting 4 minutes and then
making a blunt decision that a "write (fd, "data", 8MB)" is timed out,
if it's not finished yet, sounds strange to me.

Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 

Evolution-hackers mailing list

Reply via email to