|Summary:||configurable source ip|
|Product:||Tomcat Connectors||Reporter:||Aaron Ogburn <aogburn>|
|Component:||mod_jk||Assignee:||Tomcat Developers Mailing List <dev>|
Description Aaron Ogburn 2015-02-04 21:11:14 UTC
Could a feature be implemented to make the source ip configurable for mod_jk connections? For instance, if you have a secondary ip that httpd listens on, the connections that mod_jk makes still come from the default primary ip. It may be preferable if they could come from the secondaryip.
Comment 1 Christopher Schultz 2015-02-05 17:35:17 UTC
What interfaces do you have on an example server? What interface/IP does mod_jk currently choose? What interface/IP would you prefer mod_jk use?
Comment 2 Rainer Jung 2015-02-05 19:21:17 UTC
I think he wants an optional IP config attribute per worker. That IP would be a locally configured ip chosen by the admin. mod_jk would then bind() to that IP before doing the connect(). One choses port 0 and sets SO_REUSEADDR. bind() is typicaly used before accept() (server side) and not before connect() (client), but is is allowed for the client as well and for complex systems can do something useful. If there are multiple local IPs and/or multiple possible interfaces and routes form the web server to the backend, you can chose from which IP the connection from the point of view of the backend comes. Sometimes you can work around not being able to configure that IP by setting host routes on the web server but for that solution you need to have root access. I think it is a useful extension and not an exotic feature, though most people will not have a need to use it. The few who need it really need it :)
Comment 3 Rainer Jung 2015-02-06 14:00:56 UTC
Some technical details: https://idea.popcount.org/2014-04-03-bind-before-connect/ I haven't checked the validity of each statement, but there seems to be now much info around for using bind() on the client side. Must have a look at Stevens.
Comment 4 Aaron Ogburn 2015-02-06 14:08:38 UTC
Rainer's summation of the feature request is spot on. Thanks!
Comment 5 Rainer Jung 2015-02-08 14:31:20 UTC
I have committed the feature in r1658173. It is marked experimental in docs and changelog, because it needs more testing on various platforms. It should behave transparently if not configured. I did not set SO_REUSEADDR deliberately. Otherwise we ould have to handle EADDRINUSE during connect(). We'll see whether not setting SO_REUSEADDR is OK for most users (enough free ephemeral ports). It will be part of version 1.2.41.