Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Listen backlog size is decided from SOMAXCONN on Linux. #623

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
5 participants
@kubo39
Copy link

kubo39 commented Jun 24, 2017

No description provided.

@bluetech

This comment has been minimized.

Copy link

bluetech commented Jun 24, 2017

I feel that the backlog should be configurable and not hardcoded or set to the max.

But if you do want to set it to the max, you can avoid the extra work by using i32::MAX since it is truncated to max. This holds for linux and probably holds for other OSes as well. The POSIX man page says this:

The implementation may have an upper limit on the length of the listen queue—either global or per accepting socket. If backlog exceeds this limit, the length of the listen queue is set to the limit.

@kubo39

This comment has been minimized.

Copy link
Author

kubo39 commented Jun 24, 2017

@bluetech
We can customize the backlog size by sysctl -w net.core.somaxconn=XXX.

man listen(2) says:

If the backlog argument is greater than the value in /proc/sys/net/core/somaxconn, then it is silently truncated to that value; the default value in this file is 128. In kernels before 2.4.25, this limit was a hard coded value, SOMAXCONN, with the value 128.

mio's listen backlog size is min(SOMAXCONN, 1024). However, I want to tune the backlog size greater than 1024 for performance reason.

@bluetech

This comment has been minimized.

Copy link

bluetech commented Jun 24, 2017

Different applications on the same system may want different values. I agree it's niche.

I also agree that using the system max is better than hardcoding 1024, which may be too low or too high. Therefore I think your patch is an improvement. But you can achieve the same effect more simply (and more portably and without fallback code etc.) by just passing i32::MAX since as the passage you quoted says it will be truncated to net.core.somaxconn.

@kubo39

This comment has been minimized.

Copy link
Author

kubo39 commented Jun 24, 2017

@bluetech

Different applications on the same system may want different values. I agree it's niche.

Looks nice, but there's no means to set this. How about create an issue?

I also agree that using the system max is better than hardcoding 1024, which may be too low or too high. Therefore I think your patch is an improvement. But you can achieve the same effect more simply (and more portably and without fallback code etc.) by just passing i32::MAX since as the passage you quoted says it will be truncated to net.core.somaxconn.

Ah, but how about u16::MAX ? Linux stores the backlog in a ushort.

@alexcrichton

This comment has been minimized.

Copy link
Contributor

alexcrichton commented Jun 25, 2017

Thanks for the PR! This may not be best suited for mio, however, due to the surprising behavior it may have. This is why the methods exist, though, to construct streams from libstd streams/listeners. You can use crates like net2 and/or socket2 to configure sockets in a manual fashion, and then they can be converted into the respective mio types.

@carllerche

This comment has been minimized.

Copy link
Owner

carllerche commented Jul 25, 2017

I agree w/ @alexcrichton that the correct way to configure the backlog would be going via net2.

However, I think that the argument here is that a better default than hardcoding 1024 would be to use u16::MAX or whatever as the OS caps it to an internal limit?

How does this work on other platforms?

  • FreeBSD: ???
  • OS X: ???
  • Windows: ???
  • [other]BSD: ???
@raggi

This comment has been minimized.

Copy link
Contributor

raggi commented Jul 28, 2017

Posix specifies that the value given to listen is a hint only, and so large values should not cause errors.

@carllerche

This comment has been minimized.

Copy link
Owner

carllerche commented Aug 1, 2017

So, on posix platforms, pass u16::MAX. Does windows do the same?

@raggi

This comment has been minimized.

Copy link
Contributor

raggi commented Aug 2, 2017

I'd advise against always setting this unconditionally high. If you prevent push-back then you potentially expose your systems to high memory load in the network stack, leading to other, harder to diagnose problems. While most systems will apply other limits, the accept backlog really doesn't need to be super long most of the time. Having an option for making it long makes sense, but having it always be super long is a security issue by way of a DoS vector.

@raggi

This comment has been minimized.

Copy link
Contributor

raggi commented Aug 2, 2017

@carllerche re windows, i forget the exact details, but if I remember correctly winsock2 clamps to around 200 and might errors with values that are super large. More modern versions work with much higher values.

@carllerche

This comment has been minimized.

Copy link
Owner

carllerche commented Aug 12, 2017

@raggi so what's the conclusion?

@carllerche

This comment has been minimized.

Copy link
Owner

carllerche commented Jan 5, 2018

I'm going to close this due to inactivity.

It is currently possible to create a listener with a custom backlog setting, so changing the default isn't critical.

@carllerche carllerche closed this Jan 5, 2018

@kubo39 kubo39 deleted the kubo39:get-listen-backlog-from-SOMAXCONN-on-linux branch Jan 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.