Thread (138 messages) 138 messages, 9 authors, 2015-11-06

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

From: <hidden>
Date: 2015-10-23 13:36:41

Yet another POSIX deficiency.

When a server deals with 10,000,000+ socks, we absolutely do not care of
this requirement.

O(log(n)) is still crazy if it involves O(log(n)) cache misses.
You miss the fire point of the algorithm; you *always* find an available 
file descriptor in O(log(N)) (where N is the size of the table).

Does your algorithm guarantee that?
quoted
Is it a problem that you can "hide" your listening socket with a thread in 
accept()?  I would think so (It would be visible in netstat but you can't 
easily find out why has it)
Again, netstat -p on a server with 10,000,000 sockets never completes.
This point was not about a 10M sockets server but in general...
Never try this unless you are desperate and want to avoid a reboot
maybe.

If you absolutely want to nuke a listener because of untrusted
applications, we better implement a proper syscall.

Android has such a facility.
Solaris has had such an option too, but that wasn't the point.  You really 
don't want to know which application is doing this?
Alternative would be to extend netlink (ss command from iproute2
package) to carry one pid per socket.

ss -atnp state listening
That would be an option too.

Casper
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help