sysctl kern.ipc.somaxconn limit 65535 why?

Xin Li delphij at
Thu Jan 5 02:06:19 UTC 2012

Hash: SHA1

On 01/04/12 17:49, Chuck Swiger wrote:
> Hi, Xin--
> On Jan 4, 2012, at 5:32 PM, Xin Li wrote:
>> I am personally quite convinced that FreeBSD should make such
>> change though -- having more than 64K of outstanding and
>> unhandled connections does not sound a great idea (i.e. it's not
>> a connection limit after all, but the pending handle connection.
>> If my math were right, 64K connections would require about 1Gbps
>> bandwidth in and out if they happen in the same second.)  But I
>> agree this would be a good stress test, which might expose some
>> bugs we don't know today.
> I think I agree with the change from a correctness standpoint--
> listen(2) accepts an int backlog argument.
> I'm not convinced that there are many scenarios where needing to
> exceed a listen queue backlog of 64K would be beneficial to a
> real-world system, and I am sure there are many scenarios where it
> would be counterproductive, but folks can adjust kern.ipc.somaxconn
> as they see fit and perhaps Dan or others would gain some value
> from it.

Ah sorry that should read something like "I'm not quite convinced" and
as you see I were explaining why in detail but apparently I missed to
check the spellings...

- -- 
Xin LI <delphij at>
FreeBSD - The Power to Serve!		Live free or die
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla -


More information about the freebsd-current mailing list