[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #9716 [- Select a component]: Don't hardcode listen() backlog
#9716: Don't hardcode listen() backlog
--------------------------------------------+------------------------------
Reporter: philip | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: - Select a component | Version: Tor:
Keywords: limits, socket, freebsd, linux | 0.2.4.16-rc
Parent ID: | Actual Points:
| Points:
--------------------------------------------+------------------------------
While investigating Ticket #9708, I also found a lot of kernel messages
along the lines of:
- sonewconn: pcb 0xfffffe005b7af000: Listen queue overflow: 193 already
in queue awaiting acceptance
This despite the fact that "kern.somaxconn", which controls the length of
the listen queue, was set to 4096.
Reading through the code, I found two instances of "listen(s,SOMAXCONN)"
in src/or/connection.c. I think using SOMAXCONN as backlog is wrong. I
think the correct backlog parameter is -1 -- which tells the kernel to
accept as many connections as it's configured to accept, rather than a
hardcoded constant (which happens to be the default the kernel will accept
-- if not configured diferently).
SOMAXCONN is defined to 128 in <sys/socket.h> and is the default for
kern.somaxconn. I'm not sure why it's exposed to userland. Possibly
hysterical raisins?
Setting the backlog to -1 will allow tor to accept more connections faster
if kern.somaxconn > SOMAXCONN (ie > 128).
This is true for FreeBSD (viz solisten_proto() in sys/kern/uipc_socket.)
I've not tested Linux, but looking at the code (SYSCALL_DEFINE2(listen,
int, fd, int, backlog) in net/socket.c) it should behave the same if I'm
reading that cast correctly. On Linux, the moral equivalent of
kern.somaxconn is configured with /proc/sys/net/core/somaxconn. It's also
set to 128 by default. If raised to something huge, and listen() given a
backlog of -1, it will also accept more connections.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9716>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs