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

net: pass SO_REUSEADDR sockopt when establishing TCP connection if local IP address is set #9929

valyala opened this issue Feb 19, 2015 · 3 comments


Copy link

@valyala valyala commented Feb 19, 2015

Currently go apps are limited by 64K outgoing connections when running on hosts with multiple IP addresses if local IP address is passed to net.DialTCP(). This limit can be eliminated when setting SO_REUSEADDR sockopt to the socket before connection establishing according to . Below are the corresponding quotes from the article:

  • When using the bind before connect trick only a single connection can use a single outgoing source port. With SO_REUSEADDR flag, it's possible for many connections to reuse the same source port, given that they connect to different destination addresses.
  • If you need to select a source IP manually, for whatever reason, normally you'll be limited to one outgoing connection for one ephemeral port: destination address is not taken into account. This limits number of outgoing connections considerably.
  • Therefore if you need to specify a source IP consider setting SO_REUSEADDR flag to enable address reuse. This will increase number of possible connections, but you will need to handle possible connect() EADDRNOTAVAIL errors.
@adg adg changed the title Pass SO_REUSEADDR sockopt when establishing TCP connection if local IP address is set net: pass SO_REUSEADDR sockopt when establishing TCP connection if local IP address is set Feb 19, 2015
Copy link

@adg adg commented Feb 19, 2015

We do this for listening and multicast sockets, but not for regular outbound sockets.

I'm not sure what the drawbacks are to doing this always, if there are any.

cc @mikioh

Copy link

@mikioh mikioh commented Feb 20, 2015


Yup, TCP's simultaneous connections and derived techniques such as hole-punching are fun.

I have no concrete opinion on this stuff unless it harms, a) the top-half stuff of user IPC subsystem inside kernel, which handles bump-in-the-API mech for dual IP stack on some platform, b) the bottom-half stuff of user IPC subsystem inside kernel, which takes care of protocol integration including destination/source address selection by using IP routing/prefix lookup.

Perhaps, it may be fine on all the supported platforms, not sure. If you want to try a contribution (writing a patch and pushing it down to review process), please include a few test cases that satisfy the point of views above; both dual IP stack and IP routing behavior--from unspecified addresses ( or ::) to specified addresses for source and/or destination address selection with validating IP address reachability.

@rsc rsc added this to the Go1.5Maybe milestone Apr 10, 2015
@mikioh mikioh modified the milestones: Unplanned, Go1.5Maybe Jun 20, 2015
Copy link

@mikioh mikioh commented Jun 20, 2015

Merged into #9661.

@mikioh mikioh closed this Jun 20, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants