Re: [exim] [exim-dev] Exim 4.88 RC3 uploaded

Top Page
Delete this message
Reply to this message
Author: Jeremy Harris
Date:  
To: exim-users
Subject: Re: [exim] [exim-dev] Exim 4.88 RC3 uploaded
On 24/10/16 04:05, Phil Pennock wrote:
> On 2016-10-24 at 02:34 +0100, Jeremy Harris wrote:
>> Of course, secondary thoughts, we don't know that the same sequences
>> of library calls on FreeBSD as on Linux will do what's wanted.


> https://people.freebsd.org/~pkelsey/tfo-tools/


server:
        rc = setsockopt(listen_fd, IPPROTO_TCP, TCP_FASTOPEN,
                &on, sizeof(on));


> * Need to guard against flag being undef


Done for TCP_FASTOPEN, probably need to do for MSG_FASTOPEN.

> * Need to gracefully handle the setsockopt() call failing




OK, so

- The library call sequence is identical

- Use IPPROTO_TCP where Linux has SOL_TCP

- The current coding for failures on the server side is
ok (just ignore the setsockopt failure; we get a
non-fastopen socket as before) for non-supporting kernels

- The current coding for failures on the client side
needs thought. I made it log-noisy but functional
on the grounds that you do an extra syscall
[the sendto(..., MSG_FASTOPEN, ...)] getting a fail
every time on non-supporting kernels. There is
a transport control, defaulting to enabled.

Adding probe code in process startup might help, though
the re-execs we do defeat that. Queue-runners would be
ok but most deliveries are probably foreground.

Should I change the default to not-enabled, for the
medium-term?
--
Cheers,
jeremy