Hardcoded 128 backlog in TCPListener

[Fensteer]

In the TCPListener implementation, listen backlog is hardcoded to 128 (here).
It would be usefull to make it parametrized when binding the socket, for specific usages for example :

• Limit number of connection to the backlog
• Handle more than 128 or a specific number of connections.

What do you think about ?

[chernomor]

Tunable backlog available in https://crates.io/crates/net2

[joshtriplett]

It doesn't look like there's been any activity on this.

Concrete proposal: what if we added a new version of the bind constructor, which took a backlog parameter?

[algesten]

@joshtriplett I stumbled on this today. Was surprised it's not possible to configure using std::net. Additionally it seems net2 is deprecated and backlog parameter never found its way into the replacement socket2.

I actually need this in an async server, but it seems neither tokio nor async-std implements it. However if we agree on an API in std, the async version are likely to follow along.

Concrete proposal: what if we added a new version of the bind constructor, which took a backlog parameter?

Would it maybe make sense to mirror the work done in net2? The signature is:

TcpListener::listen(backlog: i32) -> Result<TcpListener>

This is also similar to the system call.

[joshtriplett]

On Thu, Jul 30, 2020 at 08:10:36AM -0700, Martin Algesten wrote: @joshtriplett I stumbled on this today. Was surprised it's not possible to configure using std::net. Additionally it seems `net2` is deprecated and `backlog` parameter never found its way into the replacement `socket2`. I actually need this in an async server, but it seems neither tokio nor async-std implements it. However if we agree on an API in std, the async version are likely to follow along. > Concrete proposal: what if we added a new version of the `bind` constructor, which took a `backlog` parameter? Would it maybe make sense to mirror the work done in net2? The signature is: [`TcpListener::listen(backlog: i32) -> Result<TcpListener>`](https://docs.rs/net2/0.2.34/net2/struct.TcpBuilder.html#method.listen) This is also similar to the system call.

Needs to call bind before calling listen. The current "bind" constructor does both, and I was suggesting a new constructor that still did both but had an additional parameter for the argument to listen. If you want to separate the two, you'd need some kind of type for a "bound but not yet listening" socket. That could be useful, for purposes such as "bind and then connect", but it'd be a much larger change.

[fujita]

How about using a system-wide configured value as default like Go instead of hardcoded before introducing a large change for detailed configuration? For example, net.core.somaxconn on Linux.

[njaard]

At least on linux, you could just set the backlog to infinitely high and let the kernel clamp it. I think that should be done to UnixListener and TcpListener.

[BartMassey]

There are situations where you would rather have clients get an error than be stuck in a long queue because service is slow, so being able to specify a small maximum backlog per application is important. The current default max backlog of 128 seems fine for most situations: if that number is too small it's pretty likely a larger number would be also. (That said, I opened #94406 because I needed to specify a larger backlog. Go figure.)

I just need to finish #94407 and get it pulled: I'll try to find time soon.

[smsilva98]

Any updates on this?

[BartMassey]

Sadly, no. I got stuck in the weeds trying to get the patch to pass tests on weird platforms, and then let it sit until substantial work would be needed to rebase it. Not great.

If someone wants to pick this up, I'd be happy to work with them on it. I can't see finding time on my own in the next month or two: too much going on.

[PureWhiteWu]

Is it acceptable to change the default backlog for linux to the SOMAXCONN in std as Go does?

This may change the default behaviour, though this may not cause problems and this is not documented either.

Ref: https://github.com/golang/go/blob/master/src/net/sock_linux.go

Ref implementation in rust: https://github.com/cloudwego/volo/blob/main/volo/src/net/incoming.rs#L117

[ghost]

Surprised to see Rust still doesn't allow setting TCP listening backlog 8 years after the 1.0 release. Isn't that just passing 1 numeric parameter to an existing C function, or is it somehow more complicated?

[BartMassey]

It is somehow more complicated. The listen() function is part of the cross-platform API and is expected to do something sensible everywhere. Some of the supported(ish) platforms don't have a backlog parameter, some have weird limits. Tests have to be written that compile and pass on all platforms.

It's not an insane amount of work or anything, just not quite trivial. Patches would be more than welcome! You could start with my old patches, although it is probably easier to re-implement them than rebase them at this point.

[Mark-Simulacrum]

We are broadly configuring this to the maximum possible on many platforms at this point, so I'm going to close. Remaining platforms can be increased via PR to the relevant std code.

Technically configuration is still not supported, but proposals for API shapes should generally go to the libs-api ACP process.