sysctl kern.ipc.somaxconn limit 65535 why?

Arnaud Lacombe lacombar at
Wed Jan 4 22:34:25 UTC 2012


On Wed, Jan 4, 2012 at 3:22 PM, Dan The Man <dan at> wrote:
> sunsaturn:~# sysctl -w kern.ipc.somaxconn=200000
> kern.ipc.somaxconn: 4096
> sysctl: kern.ipc.somaxconn: Invalid argument
> sunsaturn:~# sysctl -w kern.ipc.somaxconn=65536
> kern.ipc.somaxconn: 4096
> sysctl: kern.ipc.somaxconn: Invalid argument
> sunsaturn:~# sysctl -w kern.ipc.somaxconn=65535
> kern.ipc.somaxconn: 4096 -> 65535
> sunsaturn:~#
> Trying to stress test a framework here that tosses 100k of connections into
> a listen queue before doing anything, I realize I'll have to use multiple
> local IPs get get around port limitations, but why is this backlog using a
> limit?
This is an arbitrary implementation limitation. A bit of code
archaeology reveals that the explicit limitation was introduced in
1,226 of kern/uipc_socket.c[0]. Quoting the commit log:

- Convert so_qlen, so_incqlen, so_qlimit fields of struct socket from
  short to unsigned short.
- Add SYSCTL_PROC() around somaxconn, not accepting values < 1 or > U_SHRTMAX.

Before this change setting somaxconn to smth above 32767 and calling
listen(fd, -1) lead to a socket, which doesn't accept connections at all.

Reviewed by:	rwatson
Reported by:	Igor Sysoev

so the limited width of some `struct socket' fields enforces this
limitation. Now, the reason for `so_qlen', `so_incqlen', `so_qlimit'
to be so limited might be lost in the arcane of time. After all "640K
ought to be enough for anyone", doesn't it ?

 - Arnaud


> Dan.
> --
> Dan The Man
> CTO/ Senior System Administrator
> Websites, Domains and Everything else
> Email: Dan at
> _______________________________________________
> freebsd-current at mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at"

More information about the freebsd-current mailing list