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. Regards -- -Chuck _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
