Martin Blapp wrote: > Can you commit this ? The fix looks appropriate, but the manpage should > also be changed to reflect the change. > > ERRORS > Listen() will fail if: > > [EBADF] The argument s is not a valid descriptor. > [ENOTSOCK] The argument s is not a socket. > [EOPNOTSUPP] The socket is not of a type that > supports the operation listen(). > [EINVAL] Listen() has been already called on the socket. > > Any objections from others ?
It seems to me that calling listen() on a socket to change the listen queue depth is a reasonable thing to do; this is true before it's bound, after it's bound, before listen() has been called on it, and after listen() has been called on it once (or more). Am I missing something here? Is there a good technical reason to not permit an application to change the listen queue depth? Or is there some way that an application can do this, using a call other than listen()? That it causes a panic when the SYN cache is enabled isn't really a technical reason, it's a circumstantial reason. I can think of a lot of programs that might be based on FreeBSD, which would have a CLI that would let you change the wait queue (e.g. a Layer 7 load balancer, or an application proxy), where closing and reopening it -- and losing the pending connections which have performed the SYN/SYN-ACK/ACK, but have not had accept called on them yt), where it would not just be a legitimate use, it would be a required feature. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
