On Wed, 1 Aug 2001, Mike Bethune wrote:
> > Re-read what I sent above. Rebuild your copy of Exim. Set
> > DELIVER_OUT_BUFFER_SIZE=1024 in your Local/Makefile.
>
> it sounds as if you're suggesting that somehow the application layer is
> responsible for forming a packet larger than the pix's mtu thus eliciting an
> icmp request for fragmentation (assuming DF=0 in the tcp packet), and that
> the same pix is blocking it's own icmp reply.
> i doubt the sending machine is sending packets larger than it's interface's
> mtu (probably 1500) and if it was it would be a driver or link layer framing
> problem
From what people report, it does seem that changing that Exim build-time
variable affects packet size on some operating systems. I think this is
probably a lucky accident. As you say, it is certainly not part of the
specification that the application layer can affect packet sizes. I
would not rely on this - but I understand why some people do it, because
they want to get something working ASAP.
> > DELIVER_OUT_BUFFER_SIZE as listed above.
>
> don't know what this setting is for but it sounds like something to do with
> memory rather than a packet size..
When Exim is writing out a message, it reads it from its file into
buffers of size DELIVER_IN_BUFFER_SIZE, and copies the data into buffers
of size DELIVER_OUT_BUFFER_SIZE, processing it as required for the
delivery mode (e.g. turning \n into \r\n and escaping dots for SMTP,
checking for "From " for mbox deliveries). It calls write() with a size
of DELIVER_OUT_BUFFER_SIZE whenever the buffer is full. The default
value for both macros is 8192.
This is all to do with efficiency in copying messages from Exim's point
of view. For outgoing SMTP, it is up to the TCP/IP stack to split up the
data stream into packets that are appropriate for the interface that it
is going out on.
I see absolutely no reason to change the default sizes in Exim.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
